系列文章目录
文章目录
一、mysql-5.7.42RPM包构建
yaml
1、首先请查看顶部的系列文章目录,通过这篇文章构建出mysql的rpm安装包
2、接着将构建好的rpm包上传到服务器,至此安装包准备完毕,接下来搭建GTID同步模式的主从复制二、同步模式分类介绍
1.异步同步模式
yaml
异步同步模式是 MySQL 默认的同步策略模式。
客户端在向服务端发送请求后，master处理完之后,直接返回客户端结果,接着在将对应的log信息发送给 slave节点。异步同步模式缺点
yaml
主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否已经接收并处理，
这样就会有一个问题，主库如果crash掉了，此时主库上已经提交的事务可能并没有传到从库上，
如果此时，强行将从提升为主，可能导致新的主库上数据不完整2.半同步模式
半同步模式与异步同步的模式最大的区别
yaml
1、主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay_log中才返回给客户端
2、半同步模式也是基于异步复制的基础上进行的，无非是半同步模式需要安装异步插件完成2.1.实现半同步操作流程
sql
1、检测是否支持动态安装插件模式
mysql > select @@have_dynamic_loading; #返回YES为支持,反之不支持
sql
2、在 master 上安装 master 对应的插件.slave节点也可以安装,此处不做示例
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; #执行安装
mysql >show global variables like 'rpl_semi%'; #查看安装插件后的参数配置
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | OFF |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
+-------------------------------------------+------------+
sql
3、master 服务器和 slave 服务器都开启主从复制插件功能
mysql > set global rpl_semi_sync_master_enabled=ON; #调整半同步插件参数值
mysql > show global variables like 'rpl_semi%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
| rpl_semi_sync_slave_enabled | ON |
| rpl_semi_sync_slave_trace_level | 32 |
+-------------------------------------------+------------+
sql
4、salve 节点半同步复制模式
mysql >stop slave io_thread;
mysql >start slave io_thread;
sql
5、在 master 上查看 slave 信息。
这里我们看到 Rpl_semi_sync_master_clients=1，则表示有一个 salve 节点连接上了
mysql > show global status like '%semi%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | ON |
+--------------------------------------------+-------+
15 rows in set
Time: 0.011s2.2.半同步问题总结
| 问题 | 解答 |
|---|---|
| slave 节点响应 master 延迟 | 当 master 发送给 slave 节点 binary log 之后，需要等待 slave 的响应。有时可能 slave 节点响应很慢，master 不能一直等待，这样会导致客户端请求超时情况，可以通过下面的参数进行设置。该参数的单位是毫秒，默认是 10 秒，推荐设置大一点。因为超时之后，master 会自动切换为异步复制。rpl_semi_sync_master_timeout |
| 半同步模式自动转为异步同步模式 | 上方提到了，如果超时之后，半同步模式会自动切换为异步复制模式。 |
| master 接收 slave 节点数量，响应客户端。 | 当 master 需要将 binary log 发送给多个 slave 节点时，如果 slave 节点存在多个，master 都要等待 slave 一一响应之后才回复客户端，这也是一个特别耗时的过程，可以通过下面的参数进行设置。rpl_semi_sync_master_wait_for_slave_count #默认是1 |
| 当半同步模式自动切换为异步之后，如何切换为半同步模式。 | 这时候需要手动切换模式。就是关闭 io_thread，再开启 io_thread |
2.3.半同步一致性
yaml
半同步复制模式极大程度上提高了主从复制的一致性。同时在 MySQL5.7+的版本增加了另外一个参数，
让复制的一致性更加可靠。这个参数就是rpl_semi_sync_master_wait_point，需要在 master 上执行。
sql
mysql > set global rpl_semi_sync_master_wait_point = 'x';
该参数有两个值。一个值是 AFTER_SYNC，一个值是 AFTER_COMMIT。默认是 AFTER_SYNC。区别如下表格所示| AFTER_COMMIT | master 在将事务写入 binary log 之后，然后发送给 slave。同时也会自动提交 master 的事务。等 slave 响应之后，master 接着响应给客户端信息。 |
|---|---|
| AFTER_SYNC | master 在将事务写入 binary log 之后，然后发送给 slave。等待 slave 响应之后，才会提交 master 的事务，接着响应给客户端信息。 |
2.4.异步与半同步对比
| 异步同步模式 | 是直接返回给客户端在处理 slave 的问题，如果 master 响应给客户端成功信息，在处理 slave 问题时，服务挂掉了，此时就会出现数据不一致。 |
|---|---|
| 半同步模式 | 需要等待 slave 节点做出响应，master 才会响应客户端，如果 salve 响应较慢就会造成客户端等待时间较长 |
| 半同步模式 | master 等待 slave 响应之后才会响应给客户端，此方式极大程度的保证了数据的一致性，为主从复制的数据一致性提供了更可靠的保证。也推荐使用该方式进行主从复制操作。 |
3.GTID同步
如下方所示
三、GTID同步介绍
1.gtid介绍
yaml
GTID是一种全局事务ID,它是在master上已经提交的事务,slave直接根据该ID进行复制操作。
该操作替代了binary log + postion的方式。使得主从复制的配置操作更加简单。2.gtid组成
server-id不是MySQL配置文件中id，而是每一个MySQL服务在启动时，都会生成一个全局随机唯一的ID。transaction-id则是事务的ID，创建事务是会自动生成一个ID。
yaml
GTID = server-id + transaction-id组成3.gtid工作原理
yaml
1、当一个事务在主库端执行并提交时,会产生GITD,一同记录到binlog日志中
2、binlog传输到slave,并存储到slave的relay-log(中继日志)中,，读取GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID
4、如果有记录，说明该GTID的事务已经执行，slave会忽略
5、如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog。在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描4.gtid优缺点
| 优点 | 缺点 |
|---|---|
| 根据 GTID 可以快速的确定事务最初是在哪个实例上提交的。 | 必须确保主从库的引擎一致 |
| 简单的实现 failover，不用以前那样在需要找 log_file 和 log_pos。 | 不允许一个SQL同时更新一个事务引擎和非事务引擎的表 |
| 更简单的搭建主从复制，确保每个事务只会被执行一次。 | / |
| 比传统的复制更加安全，一个 GTID 在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。 | / |
| GTID是连续的没有空洞的，保证数据的一致性，零丢失 | / |
| GTID 用来代替classic的复制方法，不再使用 binlog+pos 开启复制。而是使用 master_auto_postion=1 的方式自动匹配 GTID 断点进行复制。 | / |
| GTID 的引入，让每一个事务在集群事务的海洋中有了秩序，使得 DBA 在运维中做集群变迁时更加方便 | / |
四、搭建主从复制
环境准备
| ip | 分类 |
|---|---|
| 192.168.56.130 | master |
| 192.168.56.131 | slave |
1.两台机器分别安装mysql-rpm包
这个rpm包就是第一步已构建好的rpm包
yaml
[root@mysql1 ~]# rpm -ivh city-mysql5.7.42-1-1.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:city-mysql5.7.42-1-1 ################################# [100%]
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
Creating mailbox file: File exists
Datadir /export/servers/data/my3306 will been created,instance install will continue
Starting MySQL..... SUCCESS!
Install successful!!!
The Password of mysql user root is : 0gvzJr66iNs5
1. mysql进程可以使用systemctl启停；
2. mysql未设置开机自启;
3. mysql登陆方式：mysql -uroot -p -S /export/servers/data/my3306/run/mysqld.sock
4. 建议修改root密码
5. 参数文件中设置为只读（read_only=1 super_read_only=1），如需要请将参数值该为零。2.检查两台机器my.cnf配置文件
因为在安装了构建好的rpm包后,my.cnf文件已经封装进去了，因此在安装后,只需要略微调试相关参数,即可使用。下方只列出了几个需要修改的重要参数，其余参数再次不展示
master节点
yaml
检查my.cnf文件中是否包含了开启gtid的相关参数
server_id = 1 #自定义
log_bin = ON
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
innodb_buffer_pool_size= 1G #根据服务器配置调整slave节点
yaml
server_id = 2 #自定义 与master不同即可
log_bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON
read_only = ON #从库开启只读
super_read_only = ON #从库开启只读
innodb_buffer_pool_size= 1G #根据服务器配置调整参数调整完成后,需要重启master-slave两个节点的MySQL,重启完成后,下一步就开始搭建主从关系
3.创建主从复制用户
登录主库执行
sql
mysql > grant replication slave on *.* to 'repl'@'%' identified by '123456';
mysql > flush privileges;4.搭建主从
登录从库操作
sql
mysql > reset master;
mysql > change master to master_host='主库IP', master_port=主库端口,master_user='repl' ,master_password='xx' ,master_auto_position=1;
mysql > start slave; #开启主从复制
mysql > show slave status\G; #查看主从状态当IO thread和SQL thrad 都为YES 说明主从搭建完毕
5.验证
登录主库操作
sql
mysql> show master status;
+------------------+-----------+--------------+------------------+---------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+-----------+--------------+------------------+---------------------------------------------------+
| mysql-bin.010602 | 590048831 | | | 52cf1b46-f308-11ec-a372-fa163e258462:1-1404783188 |
+------------------+-----------+--------------+------------------+---------------------------------------------------+
1 row in set (0.00 sec)如上所示,主库已产生了binlog日志及记录了当前gtid执行的位置。至此基于GTID同步模式的主从复制搭建完成
五、主从复制原理
yaml
1、服务器开启二进制日志，主服务器会把sql操作记录通过多dump线程写入到主服务器的二进制日志中
2、从服务器的io 线程向主服务器二进制日志发送请求，master 服务器在接收到请求之后，根据偏移量将新的 binary log 发送给 slave 服务器。
3、slave 服务器收到新的 binary log 之后，写入到自身的 relay log 中，这就是所谓的中继日志
4、slave 服务器，单独开启一个 sql thread 读取 relay log 之后，写入到自身数据中总结
本篇文章主要针对mysql5.7版本的同步模式分类、基于gtid同步模式搭建主从写的文章，对于mysql的构建安装过程可参考顶部的链接文章。希望这几篇文章可以帮助到大家