mysql5.6利用GTIDs构建主从数据库

【概念】什么事GTIDS（Global Transactions Identifier）是MySQL5.6.5新加入的一项新特性。

• 当使用GTIDS时，无论是在Master上提交事物还是在Slave上应用，每一个事物都可以被识别并跟踪；
• 添加新的Slave或者当发生故障需要将Master身份迁移到Slave上时，都无需考虑哪一个二进制日志以及哪个position，极大的简化了操作步骤；
• GTIDs是完全基于事务的。因此，不支持MYISAM存储引擎；

 

【关于GTID】GTID由source_id和transaction_id两部门组成。

• source_id来自于server_uuid，可以在auto.cnf文件中查看；
• tranction_id是一个序列数字，从小到达自动生成；

[root@t-db01 mysql]# cat auto.cnf [auto] server-uuid=268e23d1-2216-11e5-abcc-000c296ecd05   mysql> show global variables like 'gtid_executed'; +---------------+-----------------------------------------------------+ | Variable_name | Value                                                                   | +---------------+-----------------------------------------------------+ | gtid_executed  | 268e23d1-2216-11e5-abcc-000c296ecd05:1-28     | +---------------+-----------------------------------------------------+

 

【构建主从数据库】

环境说明：

	主库信息	从库信息
数据库版本	5.6.23	5.6.23
IP地址	192.168.47.169	192.168.47.186
同步数据库	JOHN_DB
同步用户	repl

 

 

1、主库参数的设置

server_id = 1 binlog-format=ROW  #建议使用ROW格式 log-bin=mysql-bin      #打开binlog report-port=3306 gtid-mode=on enforce-gtid-consistency=true log-slave-updates=true replicate_do_db=JOHN_DB

 

2、从库参数的设置

server_id = 2 log-bin=mysql-bin report-port=3306 gtid-mode=on enforce-gtid-consistency=true log-slave-updates=true replicate_do_db=JOHN_DB skip-slave-start    #启动的时候自动打开复制

 

检查gtid是否启用：show global variables like ‘%gtid%’;

 

3、在主库上面用户的创建

grant replication slave on JOHN_DB.* to 'repl'@'192.168.47.186' identified by 'repl';

 

4、进行从库数据的初始化

操作的步骤跟5.5的步骤一样，这边就偷懒不再重复了；

 

5、配置从库连接主库

从库连接主库： change master to master_host='192.168.47.169', master_user='repl',master_password='repl',master_auto_position=1; 启动从库： start slave； 检查状态： show slave status\G； mysql> show slave status\G; *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 192.168.47.169                   Master_User: repl                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: mysql-bin.000009           Read_Master_Log_Pos: 485                Relay_Log_File: t-db02-relay-bin.000012                 Relay_Log_Pos: 695         Relay_Master_Log_File: mysql-bin.000009              Slave_IO_Running: Yes             Slave_SQL_Running: Yes               Replicate_Do_DB: JOHN_DB           Replicate_Ignore_DB:            Replicate_Do_Table:        Replicate_Ignore_Table:       Replicate_Wild_Do_Table:   Replicate_Wild_Ignore_Table:                    Last_Errno: 0                    Last_Error:                  Skip_Counter: 0           Exec_Master_Log_Pos: 485               Relay_Log_Space: 1150               Until_Condition: None                Until_Log_File:                 Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                Last_SQL_Errno: 0                Last_SQL_Error:   Replicate_Ignore_Server_Ids:              Master_Server_Id: 31                   Master_UUID: 268e23d1-2216-11e5-abcc-000c296ecd05              Master_Info_File: /data/mysql/master.info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it            Master_Retry_Count: 86400                   Master_Bind:       Last_IO_Error_Timestamp:      Last_SQL_Error_Timestamp:                Master_SSL_Crl:            Master_SSL_Crlpath:           Retrieved_Gtid_Set: 268e23d1-2216-11e5-abcc-000c296ecd05:1-29             Executed_Gtid_Set: 268e23d1-2216-11e5-abcc-000c296ecd05:1-29                 Auto_Position: 1 1 row in set (0.02 sec) ERROR: No query specified 自动找到binlog位置，并进行同步；

经过以上操作便完成了mysql主从架构的搭建；

 

【常见问题的处理方法】

1、场景的模拟

步骤一：主库上面创建表john，并插入3行数据。（这个时候从库和主库的数据是一致的） mysql> select * from john; +------+ | id   | +------+ | 1    | | 2    | | 3    | +------+ 3 rows in set (0.19 sec)   步骤二：从库关闭slave状态 mysql> stop slave；   步骤三：主库关闭写binlog mysql>  set sql_log_bin=off;   关闭 Query OK, 0 rows affected (0.03 sec)   步骤四：主库插入值4 mysql> insert into john values(4); Query OK, 1 row affected (0.04 sec)   步骤五：主库启动binlog mysql> set sql_log_bin=on; Query OK, 0 rows affected (0.00 sec)   步骤六：主库插入值 5 mysql> insert into john values(5); Query OK, 1 row affected (0.00 sec)   经过以上步骤，主库和从库中john的值已经不一致了； 主库如下：   从库如下:     步骤六：修改主库id为4的行，这个时候从库就会报错了

Retrieved_Gtid_Set: a989adc2-2a8e-11e5-a308-000c296ecd05:1-30  主库的Gtid序号
Executed_Gtid_Set: a989adc2-2a8e-11e5-a308-000c296ecd05:1-29  从库执行Gtid序号

 

2、问题原因：由于id=4是没有写日志的，所以id=4并没有同步到从库，当主库删除id=4这条记录的时候，从库找不到这条记录所以报错了；

 

3、解决方法：GTIDs模式下的主从问题，操作如下：

mysql> stop slave; mysql> set GTID_NEXT=’268e23d1-2216-11e5-abcc-000c296ecd05:1-30’;    #跳过当前从库的该序号 mysql> BEGIN; mysql> COMMIT; mysql> SET GTID_NEXT=’AUTOMATIC’; mysql> START SLAVE;

 

经过以上操作完成了基于GTIDs的主从数据库的配置和常见问题的处理，单从便捷的角度上确实提高了主从搭建的速度；

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12679300/viewspace-1733655/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12679300/viewspace-1733655/