导读：本文主要详细测试online DDL中的删除，添加主键操作。关于MySQL5.6在线DDL的全文信息，请参照：MySQL5.6版本InnoDB存储引擎在线DDL变更的官方信息中文翻译版，

文章地址：http://www.mysqlops.com/2013/03/26/mysql56-innodb-ddl.html

测试目的主要有以下几点：

阅读全文——共19198字

5.5 InnoDB存储引擎表在线DDL

5.5.1．在线DDL概述

以前，InnoDB存储引擎表的许多DDL操作代价是非常昂贵的。许多ALTER TABLE操作的原理是通过创建新的空表，定义被要求的表选项和索引，然后逐行拷贝已存在记录到新表，在插入行时更新索引。在旧表所有行被拷贝完，旧表被删除和那新表被重命名为旧的表名。    MySQL5.5,和MySQL5.1 有了InnoDB Plugin,优化了CREATE INDEX和DROP INDEX 避免表的拷贝行为。这个特性被称为Fast index Creation。MySQL 5.6 加强ALTER TABLE操作许多方式来避免拷贝表。另外加强的允许SELECT查询和INSERT, UPDATE,和DELETE(DML)语句被处理当该表正被修改时。这些功能的组合现在被称为online DDL。

阅读全文——共12788字

mysql5.6 alter table 与 Waiting for table metadata lock

上周在搞INSERT INTO … SELECT测试的时候，偶然发现一个奇怪的情况：
在insert into t select * from share 运行时， 同时执行alter table t add index(play_count)，
alter table语句会Waiting for table metadata lock， 直到insert into … select 语句结束。

      mysql [localhost] {msandbox} (spc) > SHOW processlist;
+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+
| Id | USER     | Host      | db   | Command | TIME | State                           | Info                                |
+----+----------+-----------+------+---------+------+---------------------------------+-------------------------------------+
|  5 | msandbox | localhost | spc  | Query   |    8 | Waiting FOR TABLE metadata LOCK | ALTER TABLE t ADD INDEX(play_count) |
|  8 | …

mysql5.6如何修改innodb_log_file_size

mysql5.6以前的版本， 如果修改了innodb_log_file_size，然后重启mysqld，会报错：

      InnoDB: Error: log file ./ib_logfile0 IS OF different SIZE 0 5242880 bytes
InnoDB: than specified IN the .cnf file 0 10485760 bytes!

因为mysqld检测到ib_logfile0的大小，与配置文件中指定的大小不一致。

正确的做法：
1 关闭mysql数据库 ，观察 错误日记的信息,确保正常关闭
2 修改innodb_log_file_size = 新的值。
3 使用mv 命令将ib_logfile0 ib_logfileN 做备份
4 重新启动数据库，并观察 错误日记的信息
5 如果启动成功，则删除之前备份的旧日志文件

5.6开始就没这么麻烦，修改完innodb_log_file_size，直接重启就行了。

      2013-02-26 14:33:47 29891 …

mysql5.6主从复制第四部分[一些被忽视的操作细节]

1. STOP SLAVE

从服务器上负责同步的有二类线程:
1) IO thread
2) SQL thread

IO thread负责获取master上的binary log, 然后多个sql threads负责执行。

IO thread 决定了Retrieved_Gtid_Set
SQL thread 决定了Executed_Gtid_Set

由于IO thread先于SQL thread，Retrieved_Gtid_Set可能会略多于Executed_Gtid_Set。
比如:

      mysql [localhost] {msandbox} (test) > SHOW slave STATUS \G
.......
.......
           Retrieved_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-9
            Executed_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-7
                Auto_Position: 1

所以，在stop slave的时候，正确的操作是：
1) stop slave io_thread;
2) show slave status …

mysql5.6主从复制第三部分

第三部分测试主服务器挂掉，提升某个从服务器的情况。

继续用mysql::sandbox来测试。
主服务器(别名black)(server-id:1)安装在 /home/modify/sandboxes/msb_5_6_10/ 使用5610端口。
从服务器(别名blue)(server-id:2)安装在 /home/modify/sandboxes/msb_5_6_10_a/ 使用5611端口。
从服务器(别名green)(server-id:3)安装在 /home/modify/sandboxes/msb_5_6_10_b/ 使用5612端口。
从服务器(别名red)(server-id:4)安装在 /home/modify/sandboxes/msb_5_6_10_c/ 使用5613端口。

然后再构造一种最特殊的情况：
当主服务器挂掉的时候，blue获取到的gtid及transaction比green要少， green比red要少，然后要求把green提升为主服务器。

主black 写入一条数据:
mysql [localhost] …

mysql5.6主从复制第二部分

本来第二部分是想测试主服务器挂掉，提升从服务器的情况，
可是出了点点意外，改为测试某一台从服务器挂掉的时候，如何恢复。
主服务器挂掉的情况放到第三部分吧。

继续用mysql::sandbox来测试。
主服务器(别名black)(server-id:1)安装在 /home/modify/sandboxes/msb_5_6_10/ 使用5610端口。
从服务器(别名blue)(server-id:2)安装在 /home/modify/sandboxes/msb_5_6_10_a/ 使用5611端口。
从服务器(别名green)(server-id:3)安装在 /home/modify/sandboxes/msb_5_6_10_b/ 使用5612端口。

按照前一篇文章介绍的方法设置好一主二从的复制。

…

mysql5.6主从复制第一部分

很久之前写过《mysql5.1的主从配置》，
如今mysql已经发布了5.6.10，在主从复制功能上做了很多优化，特别是GTID(Global Transaction ID)的引入，
值得再重新写一篇文章介绍如何配置mysql 5.6.10的主从复制。

还是用mysql::sandbox来测试吧。
主服务器(别名black)安装在 /home/modify/sandboxes/msb_5_6_10/ 使用5610端口。
从服务器(别名blue)安装在 /home/modify/sandboxes/msb_5_6_10_a/ 使用5611端口。

第一步，修改配置文件

修改主服务器配置文件my.sandbox.cnf，添加下面的几行：

binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only …

mysql5.6.9rc 子查询优化之后带来的问题

测试数据如下：
表t1和t2通过t1_id关联在一起；
t1中只有一条记录的type为0，另外三条记录的type为1；
对于t1中的每个t1_id, t2中都有6条记录与其关联。

CREATE TABLE `t1` (
  `t1_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `type` INT(10) UNSIGNED NOT NULL DEFAULT '0',
  PRIMARY KEY (`t1_id`),
  KEY `type` (`type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE `t2` (
  `t2_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `t1_id` INT(10) UNSIGNED NOT NULL DEFAULT '0',
  PRIMARY KEY (`t2_id`),
  KEY `t1_id` (`t1_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
 
INSERT INTO t1 SET TYPE=0;
INSERT INTO t1 SET TYPE=1;
INSERT INTO t1 SET TYPE=1;
INSERT INTO t1 SET TYPE=1;
 
INSERT INTO t2 SET t1_id=1;
INSERT INTO t2 SET t1_id=1;
INSERT INTO t2 SET t1_id=1;
INSERT INTO t2 SET t1_id=1;
INSERT INTO t2 SET t1_id=1; …

mysql5.6 将不会在binary log中记录明文密码

在使用create user, grant和set password语句时，mysql5.6.3之前的版本都会把明文的密码记录到binary log中。

mysql> SELECT version();
+------------+
| version()  |
+------------+
| 5.5.22-log |
+------------+
1 ROW IN SET (0.04 sec)
 
 
mysql> GRANT ALL ON test.* TO 'huarong'@'localhost' IDENTIFIED BY 'ddddddd';
Query OK, 0 ROWS affected (0.09 sec)
 
 
[root@www DATA]# ../bin/mysqlbinlog mysql-bin.000075 | grep -i GRANT
GRANT ALL ON test.* TO 'huarong'@'localhost' IDENTIFIED BY 'ddddddd'

从5.6.3开始，将不再保存明文的密码。

mysql> SELECT version();
+--------------+
| version()    |
+--------------+
| 5.6.9-rc-log |
+--------------+
1 ROW IN SET (0.00 sec)
 
 
mysql> GRANT ALL ON test.* TO 'huarong'@'localhost' IDENTIFIED BY 'ddddddd';
Query OK, 0 ROWS …