基于GTID的 Mysql 主从数据库的复制
一、主从复制存在的问题以及解决办法
问题:
主库宕机之后,数据可能会丢失
从库只有一个sql Thread,主库写压力大,复制很可能延时
解决方法:
半同步复制--解决数据丢失的问题
并行复制--解决从库复制延时的问题
1.数据库同步是怎样进行的?
master用户写入数据,生成event记到binary log中.
slave接收master上传来的binlog,然后按顺序应用,重现master上的用户操作。
2.数据库是靠什么同步的?
主从复制,默认是通过pos复制(postion),就是说在日志文档里,将用户进行的每一项操作都进行编号(pos),每一个event都有一个起始编号,一个终止编号,我们在配置主从复制时从节点时,要输入master的log_pos值就是这个原因,要求它从哪个pos开始同步数据库里的数据,这也是传统复制技术, MySQL5.6增加了GTID复制,GTID就是类似于pos的一个作用,不过它是整个mysql复制架构全局通用的,就是说在这整个mysql冗余架构中,它们的日志文件里事件的GTID值是一致的.
3.从节点怎么知道要从哪块进行同步?
上面也说了,一开始是自己设置的从节点从主节点的日志文件里的pos开始复制,以后就自己去读取上一次同步到哪一块,接着同步.
4:pos与GTID有什么区别?
两者都是日志文件里事件的一个标志,如果将整个mysql集群看作一个整体,pos就是局部的,GTID就是全局的。
二、GTID的概念
- 全局事务标识:
global transaction identifiers
。 - GTID是一个事务一一对应,并且全局唯一ID。
- 一个GTID在一个服务器上只执行一次,避免重复执行导致数据混乱或者主从不一致。
- GTID用来代替传统复制方法,不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启。
- 而是使用MASTER_AUTO_POSTION=1的方式开始复制。
- MySQL-5.6.5开始支持的,MySQL-5.6.10后开始完善。
三、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的优势
- 更简单的实现failover,不用以前那样在需要找log_file和log_pos。
- 更简单的搭建主从复制。
- 比传统的复制更加安全。
- GTID是连续的没有空洞的,保证数据的一致性,零丢失
- 借助GTID,在发生主备切换的情况下,MySQL的其它Slave可以自动在新主上找到正确的复制位置,这大大简化了复杂复制拓扑下集群的维护,也减少了人为设置复制位置发生误操作的风险。另外,基于GTID的复制可以忽略已经执行过的事务,减少了数据发生不一致的风险。
五、GTID的工作原理
- 当一个事务在主库端执行并提交时,产生GTID,一同记录到binlog日志中。
- binlog传输到slave,并存储到slave的relaylog后,读取这个GTID的这个值设置gtid_next变量,即告诉Slave,下一个要执行的GTID值。
- sql线程从relay log中获取GTID,然后对比slave端的binlog是否有该GTID。
- 如果有记录,说明该GTID的事务已经执行,slave会忽略。
- 如果没有记录,slave就会执行该GTID事务,并记录该GTID到自身的binlog,在读取执行事务前会先检查其他session持有该GTID,确保不被重复执行。在解析过程中会判断是否有主键,如果有就用二级索引,如果没有就用全部扫描。
六、配置基于GTID的 Mysql 主从数据库的复制
配置server1(主库)
1.修改配置文件(/etc/my.cnf)并重启mysql
[root@server1 mysql]# vim /etc/my.cnf
在最后写入:
log-bin=mysql-bin #启动mysql二进制日志,即数据同步语句,从数据库会一条一条的执行这些语句
server-id=1 #服务器唯一标识
gtid_mode=ON #开启gtid模式
enforce-gtid-consistency=true #强制gtid一致性,开启后对于特定create table不被支持
修改完配置文件之后,重启mysqld服务
[root@server1 mysql]# systemctl restart mysqld
2.查看主库状态
[root@server1 mysql]# mysql -uroot -pWestos+001
mysql> show master status;
配置server2(从库)
1.修改配置文件(/etc/my.cnf)并重启mysql
[root@server2 mysql]# vim /etc/my.cnf
在最后写入:
gtid_mode=ON #开启gtid模块
enforce-gtid-consistency=true #强制gtid一致性,开启后对于特定create table不被支持
server-id=2 #服务器唯一标识
修改完配置文件之后,重启mysqld服务
[root@server2 mysql]# systemctl restart mysqld
2.设定从库,将主库与从库连接起来,并开启从库
登录server2(从库)自己的数据库进行设置
[root@server2 mysql]# mysql -uroot -pWestos+001
mysql> stop slave; #先关闭slave(在change之前要关闭slave)
Query OK, 0 rows affected (0.03 sec)
mysql> change master to
-> master_host='172.25.63.1',
-> master_user='repl',
-> master_password='Westos+001',
-> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.17 sec)
mysql> start slave;
Query OK, 0 rows affected (0.06 sec)
查看从库状态:
如果Slave_IO_Running和Slave_SQL_Running都为yes,则表示正常
下图记录了gtid的变化
测试:
1.在主库端的数据库westos下的表usertb中,插入信息
mysql> insert into usertb values ('user2','456');
Query OK, 1 row affected (0.04 sec)
mysql> insert into usertb values ('user3','789');
Query OK, 1 row affected (0.08 sec)
在主库上查看gtid号的改变
mysql> show master status;
2.从库端查看是否存在在主库中添加的内容
此时可以在从库上查看gtid号码的改变。
结论:
从库看到的数据和主库看到的数据是一致的,代表基于gtid的主从复制搭建成功