mysql基于gtid主从辅助复制

mysql基于gtid主从辅助复制

Gtid是我们现在大部分的实际生产中使用的主从复制方式

关键点：二进制文件，复制点

Mysql主从辅助复制gtid原理

Mysql主库完成mysql的二进制日志的写入的时候，会标记一个标志点，
然后从库复制的时候，直接去找主库中的标记点(不会管主库的二进制日志里面有什么)
找到标记点的话就自动器复制
GTID复制不像传统的复制方式（异步复制、半同步复制）需要找到binlog（MASTER_LOG_FILE）和POS点（MASTER_LOG_POS）
只需要知道master的IP、端口、账号、密码即可
因为复制是自动的，MySQL会通过内部机制GTID自动找点同步
和基于position的主从复制的不同之处在于：它是以一整个事件为单位进行复制的
server-id：服务器身份id，在初始化MySQL时，会自动生成一个server-id并写到数据目录的auto.cnf文件中，
官方不建议修改，并且server-id跟GTID有密切关系，并且对于任意一个数据库节点，server-id是唯一的
GTID：全局事务标识符，使用这个功能时，内次事务提交都会在binlog里生成一个唯一的标识符，
它由UUID和事务ID组成，首次提交的事务为1，第二次为2，第三次为3，以此类推
开启GTID，无需找到binlog和POS点，直接change master to master_auto_postion=1即可，它会自动寻找同步

mysql gtid原理步骤：

在master上一个事务提交，并写入binlog里
binlog日志发送到slave，slave接收并写入中继日志里，slave读取到这个GTID，并设置gtid_next的值。
例如set @@session。gtid_next=’=fbd841f9-5590-11e8-b819-000c29e6461e’;
然后告诉slave接下来的事务必须使用GTID，并写入它自己的binlog里
slave检查并确认这个GTID没有被使用，如果没有被使用，那么开始执行这个事务并写入自己的binlog里
由于gtid_next的值不为空，slave不会尝试去生成一个新的gtid而是通过主从同步来获取GTID

Mysql中的binlog的查看方法:

我们可以查看编号是000001的操作的日志(只有主服务器有binlog)

Server2:

从库可以看到自己的relay_log

可以看到从库从主库里复制了哪些东西

从库需要去标记复制的主库日志的而进制编号和我们的复制点是什么，
手动的进行主从的复制不太现实

实验步骤

配置master节点(server1上)

配置主库打开gtid模式

vim /etc/my.cnf #编辑文件
编辑内容为（在最后加入）：
gtid_mode=ON #打开gtid模式
enforce-gtid-consistency=true

重启数据库

systemctl restart mysqld #重启数据库

配置从库gtid复制

配置从库打开gtid模式

配置slave节点(number2上)

vim /etc/my.cnf #编辑文件

编辑内容为（在最后加入）：

gtid_mode=ON #打开gtid模式
enforce-gtid-consistency=true

重启从库

systemctl restart mysqld #重启数据库

登陆从库暂时关闭slave

mysql -uroot -pWestos.123 #登录数据库

stop slave; #关闭slave

在从库上配置主库复制信息

配置主库信息：
在从库上配置主库的复制点
change master to master_host =‘172.25.21.1’, #指定主库的ip地址
master_user=‘huige’, #从库复制的主库的用户
master_password=‘Westos.456’, #主库的密码
master_auto_position=1; #设定为自动

开启从库的slave功能

start slave; #开启slave

查看从库gtid是否配置成功

show slave status\G; #查看从库状态

可以看到的当前两个进程都是yes，表示主库和从库的数据一致

然后我们发现底下多两个Gitd相关的配置

主库添加数据进行主从复制测试

在主库上添加数据
Mysql -uroot -pWestos.123

use westos;
insert into usertb values ('user2','147');
insert into usertb values ('user3','852');

Server2:

在从库上查看

show slave status\G

发现从库的gtid自动识别到更改

我们可以看到主库的操作被从库复制了过来
主库进行操作后，会将操作写进到binary log中，主库在写完的时候会放一个标志位gtid，
然后从库去找这个gtid标志位就好了

我们在从库中将数据库切换成mysql库
然后我们可以在gtid_executed表中看到id号和我们上面识别到的id一样
然后我们可以在主库server1上的主库状态中看到有了标记位gtid