GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID,它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器器上唯一,在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单,以及数据库一致性更可靠。本文主要描述了快速配置一个基于GTID的主从复制架构,供大家参考。
一、GTID的概念
1、全局事务标识:global transaction identifiers。
2、GTID是一个事务一一对应,并且全局唯一ID。
3、一个GTID在一个服务器上只执行一次,避免重复执行导致数据混乱或者主从不一致。
4、GTID用来代替传统复制方法,不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
5、MySQL-5.6.5开始支持的,MySQL-5.6.10后开始完善。
6、在传统的slave端,binlog是不用开启的,但是在GTID中slave端的binlog是必须开启的,目的是记录执行过的GTID(强制)。
二、GTID的组成
GTID = source_id:transaction_id
source_id,用于鉴别原服务器,即mysql服务器唯一的的server_uuid,由于GTID会传递到slave,所以也可以理解为源ID。
transaction_id,为当前服务器上已提交事务的一个序列号,通常从1开始自增长的序列,一个数值对应一个事务。
示例:
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
前面的一串为服务器的server_uuid,即3E11FA47-71CA-11E1-9E33-C80AA9429562,后面的23为transaction_id
三、GTID的优势
1、更简单的实现failover,不用以前那样在需要找log_file和log_pos。
2、更简单的搭建主从复制。
3、比传统的复制更加安全。
4、GTID是连续的没有空洞的,保证数据的一致性,零丢失。
四、GTID的工作原理
1、当一个事务在主库端执行并提交时,产生GTID,一同记录到binlog日志中。
2、binlog传输到slave,并存储到slave的relaylog后,读取这个GTID的这个值设置gtid_next变量,即告诉Slave,下一个要执行的GTID值。
3、sql线程从relay log中获取GTID,然后对比slave端的binlog是否有该GTID。
4、如果有记录,说明该GTID的事务已经执行,slave会忽略。
5、如果没有记录,slave就会执行该GTID事务,并记录该GTID到自身的binlog,
在读取执行事务前会先检查其他session持有该GTID,确保不被重复执行。
6、在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描。
五、选择两台已安装好的相同版本mysql(本文为5.7).
A > 172.16.100.66
B > 172.16.100.67
六、以root用户登陆主节点mysql.
GRANT REPLICATION SLAVE,REPLICATION CLIENT on *.* to repl@'172.16.100.%' identified by 'password';
- 增加复制用户并授权(主备都在172.16.100.*网段,为了方便主备切换,两边都建立).
七、主备分别配置/etc/my.cnf
* 主节点*
[mysqld]
#GTID:
server_id=135 #服务器id
gtid_mode=on #开启gtid模式
enforce_gtid_consistency=on #强制gtid一致性,开启后对于特定create table不被支持
#binlog
log_bin=master-binlog
binlog_format=row #强烈建议,其他格式可能造成数据不一致
#relay log
skip_slave_start=1
备节点
[mysqld]
#GTID:
gtid_mode=on
enforce_gtid_consistency=on
server_id=143
#binlog
log-bin=slave-binlog
binlog_format=row #强烈建议,其他格式可能造成数据不一致
#relay log
skip_slave_start=1
- 重启两个mysql服务器 systemctl restart mysqld
八、登陆主(root)执行
show master status\G;
显示
File: mysql-bin.000001
Position: 106
九、登陆备(root) 执行
- 测试 mysql -urepl -h172.16.100.66 -p3306 是否能连接到主库,不能需要检查防火墙或者/etc/my.cnf是否有访问限制,修改配置
slave端配置
CHANGE MASTER TO
MASTER_HOST='172.16.100.66',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=106;
start slave;
show slave status\G;
十、验证
slave端
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.65
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-bin.000007
Read_Master_Log_Pos: 290
Relay_Log_File: slave-relay-bin.000002
Relay_Log_Pos: 502
Relay_Master_Log_File: master-bin.000007
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: mysql.%
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 290
Relay_Log_Space: 706
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: 1
Master_UUID: c8bb22a1-024e-11e6-a1e8-000c29225fa0
Master_Info_File: mysql.slave_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:
Executed_Gtid_Set:
Auto_Position: 1
1 row in set (0.00 sec)
ERROR:
No query specified
- 查看如下两个参数为YES,说明从库运行正常。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes