文章目录
如何实现binlog复制
实验背景:
server1 主数据库 172.25.2.10
server2 备数据库 172.25.2.11
关闭两台主机的防火墙和selinux
在server1 主数据库上
1.解压mysql安装包，注意是5.6版本以上的。
tar xf mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar
2.安装需要的包
yum install -y mysql-community-client-5.7.24-1.el7.x86_64.rpm
mysql-community-common-5.7.24-1.el7.x86_64.rpm
mysql-community-libs-5.7.24-1.el7.x86_64.rpm
mysql-community-libs-compat-5.7.24-1.el7.x86_64.rpm
mysql-community-server-5.7.24-1.el7.x86_64.rpm
#安装后会替换 mariadb 相关的库文件
3.修改配置文件
vim /etc/my.cnf
负责在主、从服务器传输各种修改动作的媒介是主服务器的二进制变更日志，记载着需要传输给从服务器的各种修改动作。因此，主服务器必须激活二进制日志功能。
从服务器必须具备足以让它连接主服务器并请求主服务器把二进制变更日志传输给它的权限
如果要使用复制功能，则必须开启二进制日志，如果要开启二进制日志，需要设置server-id参数，启动二进制日志需要重启数据库实例
如果未设置 server_id（或将其显式设置为其默认值0），则主服务器将拒绝从属服务器的任何连接上述是最简单的设置，在实际应用中需要设置参数，优化设置
==4.启动 mysql==
```cpp
systemctl start mysqld
5.查看生成的临时密码
cat /var/log/mysqld.log | grep password
6.用临时的密码尝试连接发现不能查看数据库
mysql -uroot -p'xxxxx'
7.安全初始化
mysql_secure_installation
密码要求有大小写，数字，特殊字符，其他全选 y 完成后可以登录数据库
8.创建并授权用来做复制的用户
在 Master 的数据库中建立一个备份帐户。
每个从服务器都需要使用MySQL的用户和密码连接到主服务器上，因此需要在主服务器上创建MySQL的用户，用于进行复制操作。可以为每个从库单独创建一个账号，也可以使用同一个账号。
账号需具有“replication slave”权限。用户名的密码都会存储在文本文件 master.info 中
(REPLICATION英文含义是复制)
9.获取master二进制日志文件和位置
show master status;很重要!
这里的截图遗失了
在server2从数据库上
1.在 server2 上同样安装、初始化 mysql ，具体步骤和server1类似。
2.修改配置文件
vim /etc/my.cnf
server-id=2 ##文件最后加
不必在从属服务器上启用二进制日志记录即可设置复制。
但是，如果在从属服务器上启用二进制日志记录，则可以使用从属服务器的二进制日志进行数据备份和崩溃恢复，也可以将从属服务器用作更复杂的复制拓扑的一部分(级联)。
3.启动 mysql
systemctl start mysqld
4.server2 上配置 master 信息
change master to
master_host='172.25.2.10',
master_user='repl',
master_password='westosYX-01',
master_log_file='mysql-bin.000002',
master_log_pos=1004; #它是日志的开始位置
master_log_file 和master_log_pos 的值为 0，因为它是日志的开始位置 ster_log_pos ,它们两个是在主库执行master status时，复制的主库的表里的内容
这里的截图丢失了。
5.start slave
6.
测试
7.创建新数据测试主从同步是否生效
注意：写操作只能在 master 节点上做，因为 master 节点不会去同步 slave 节点的内容，可以一主多从
在主数据库上创建新的数据库
2.在从数据库上发现
为什么需要进行基于GTID的主从复制
在传统的复制里面，当发生故障，需要主从切换，需要找到 binlog 和 pos 点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL 5.6 里面不用再找 binlog 和 pos 点，我们只需要知道主节点的 ip，端口，以及账号密码就行，因为复制是自动的，MySQL 会通过内部机制 GTID 自动找点同步。
从服务器连接到主服务器之后，把自己执行过的 GTID(Executed_Gtid_Set)<SQL 线程> 、
获取到的 GTID(Retrieved_Gtid_Set）<IO 线程>发给主服务器，主服务器把从服务器缺少的 GTID 及对应的 transactions 发过去补全即可。
当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主，先 change 到同步最成功的那台从服务器，等把 GTID 全部补全了，就可以把它提升为主了。
每个mysql数据库上都有一个唯一uuid
每个事务生成一个id
gtid等于uuid+事务id
GTID举例：
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
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，确保不被重复执行。
⑥在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。
Binlog是用来记录Mysql内部对数据库的改动（只记录对数据的修改操作），主要用于数据库的主从复制以及增量恢复。
实验步骤
实验背景:
server1 主数据库 172.25.2.10
server2 备数据库 172.25.2.11
关闭两台主机的防火墙和selinux
在上述两台机器做好mysql的初始化配置后。
在serevr1主数据库上
1.修改配置文件
vim /etc/my.cnf ##在文件最后添加
log-bin=mysql-bin
gtid_mode=ON
enforce-gtid-consistency=true
2. cat auto.cnf ##看到 server1 的 uuid
3.systemctl restart mysqld
4.设置授权信息
5.查看主库状态
master status
在serevr2备数据库里
1.vim /etc/my.cnf,并且重新启动mysqld
mysql5.6 slave 必须开启 binlog 日志但是5.7 中不是必须的
log_bin=ON（可选）--高可用切换，最好设置 ON
log-slave-updates=ON（可选）--高可用切换，最好设置 ON
2.修改 master 信息
这里是与“使用二进制日志文件复制”差别最大的地方，在使用二进制方法时，我们需要指定二进制日志文件的位置(master_log_file,master_log_pos)，但是在使用GTID时，MySQL会自动查找位置
3.show slave status\G##查看状态，可以看到下面两个参数是空的
Retrieved_Gtid_Set:
Executed_Gtid_Set:
测试
1.在 server1 上建立数据库并且插入数据
2.在从库查看数据
3.在从库上查看状态
4.在从库上查看 gtid 模式复制的起始和结束位置
在没有配置好时，查看这个表是空的
一些操作命令:
5.停止复制时，在slave上执行stop slave;
6.在 server2从库上查看主从复制状态是否正常
cat /var/lib/mysql/relay-log.info#查看 relay-log
7.查看某个库的uuid
show global variables like ‘server_uuid’; #查看uuid(在数据库里）
或者在数据目录的auto.cnf
cat auto.cnf
8.show variables like ‘log_%’; #查看二进制日志
9.主库查看二进制日志
show master logs;
10.reset slave; #重置slave
11.reset master; #重置master,
12.检查gtid模式状态
show variables like ‘%gtid%’;
