京东：三季度归属母公司净亏损28亿元，去年同期净利润76亿元
06-18
你好，我是悟空。本文主要内容如下： 一、背景 为了保证高可用性，之前在测试环境中部署了一套MySQL双主模式。
当一个主库的服务出现异常时，可以将流量切至另一主库。两个主数据库之间相互同步数据。
双主模式 双主模式示意图如下： 添加描述，但经常出现数据冲突，所以我们将双主模式改为主从读写分离模式。主库用作读写库，从库用于执行I/O密集型任务（如大量数据统计操作）。
如下图所示： 另外，从库复制模式采用的是定位方式：指定binlog文件和binlog位置，以便从库知道复制的起始位置。 （下面会讲解这个方法）虽然改成了主从模式，但是还是遇到了一些问题： 问题一：从B库复制数据时，出现主键冲突，导致同步失败，从库停止复制。
猜测是因为主库配置的binlog格式混杂，导致从库同步时出现不一致的情况。问题二：从库B停止复制后，大量数据没有同步到从库，导致主从之间大量数据不一致。
问题3：如果slave B想要恢复复制，必须先解决同步失败的问题，然后才能恢复。故障排除既困难又耗时。
问题4：从B库恢复时，必须知道同步点，即副本是从哪个binlog文件和binlog位置断开的，即使找到了该点也是不准确的。问题5：从库B因同步异常停止复制到恢复复制期间，主库A自动清除了前几天的binlog日志，但这些日志尚未被从库B同步，导致同步再次失败。
问题六：主从之间存在同步延迟。本文我们将讨论问题4和问题6。
问题4是一个比较麻烦的问题。我们通常通过检查从库B当前的同步状态来获取同步点，然后设置同步点。
但重新启动同步时会出现同步异常。例如从库B可能出现Duplicate entry ‘id_of_R’ for key ‘PRIMARY’错误，提示主键冲突，然后停止同步。
为了减少站点同步带来的复杂性，我们切换到 GTID 模式。关于问题6，本文仅限于讨论如何观察延迟，如何减少延迟超出了本文的范围。
接下来我们来展开一下站点同步的痛点。2、站点同步的痛点 2.1 站点同步示意图 为了更清楚地理解主从站点同步的原理，这里给出一个示意图： 1、主库会生成多个binlog日志文件。
2、向库的I/O线程请求指定位置的指定文件和binlog日志文件（位置）。 3、主库dump线程获取指定位置的binlog日志。
4、主库根据从库发送过来的位置信息读取binlog，然后将binlog推送到从库。 5、从库将获取到的binlog写入本地relay log（中继日志）文件中。
6、从库的SQL线程读取并解析中继日志文件。 7、从库的SQL线程重放中继日志中的命令。
当我们使用站点同步时，两种场景下的操作步骤都比较复杂。 2.2 痛点 痛点一：首次开启主从复制步骤比较复杂。
第一次启用主从同步时，要求从库和主库保持一致。找到主库的binlog位置。
设置从库的binlog位置。启动从库的复制线程。
痛点二：恢复主从复制步骤复杂。找到从复制线程停止的点。
解决复制异常。当无法解决时，需要手动跳过指定类型的错误，例如通过设置slave_skip_errors=,。
当然，这个前提是跳过此类错误是无损的。 （错误是插入数据时唯一键冲突；错误是删除数据时找不到一行。
） 第一次启动同步时，或者恢复master时是否需要查找并设置位点-从机复制、设置位点和忽略错误，这些步骤都显得过于复杂且容易出错。因此，MySQL 5.6版本引入了GTID，彻底解决了这个困难。
3. GTID方案 3.1 什么是GTID？ GTID的全称是Global Transaction Identifier，全局事务ID。当一笔交易被提交时，会生成一个GTID，相当于该笔交易的唯一标识符。
GTID 如下所示： 代码语言：javascript copy c5d6-d7ec-11ec-bf8f-ac02:1 结构： 代码语言：javascript copy GTID=server_uuid:gnoserver_uuid 是实例第一次启动时自动生成的，是全局的唯一值；gno是一个整数，初始值为1。它被分配给该事务，并且每次提交事务时加1。
每个 MySQL 实例都维护一个 GTID 集合，该集合对应于“该实例执行的所有事务”。3.2 GTID 的优点 1. 更容易实现故障转移，而不必像以前一样查找位置（log_file 和 log_pos）。
2.更容易构建主从复制。 3.比传统复制更安全。
4、GTID连续无空洞，保证数据一致性、零丢失。 3.3 如何让 GTID 修改主库和从库的配置文件： 代码语言：javascript copy #GTID:gtid_mode=onenforce_gtid_consistency=on 从库配置同步参数： 代码语言：javascript copy CHANGE MASTER TO MASTER_HOST=$ host_name MASTER_PORT=$port MASTER_USER=$user_name MASTER_PASSWORD=$password master_auto_position=1 其中master_auto_position标识主从关系使用的GTID协议。
与之前的配置相比，不再需要MASTER_LOG_FILE和MASTER_LOG_POS参数。 3.4 GTID同步方案 GTID同步示意图。
GTID方案：主库计算主库的GTID集合和从库的GTID集合的差异，主库将差异binlog推送到从库。从库设置好同步参数后，主库A的GTID集合记为集合x，从库B的GTID集合记为y。
从库同步逻辑如下：从库B指定主库A，并根据主备协议恢复连接。从库B将集合y发送给主库A，主库A计算集合x和集合y的差值，即集合x中存在但集合y中不存在的GTID集合。
例如，如果集合x为1~，集合y为1~90，则差集为91~。这里会判断集合x是否包含集合y的所有GTID。
如果没有，则说明主库A已经删除了从库B所需的binlog，主库A将直接返回错误。主库A从自己的binlog文件中找到第一个不在集合y中的事务GTID，即找到91。
主库A从GTID = 91的事务开始，稍后读取binlog文件，按顺序取binlog ，然后发送给B。从B库的I/O线程读取binlog文件，生成relay log。
SQL线程解析中继日志，然后执行SQL语句。 GTID同步方案与站点同步方案的区别在于，站点同步方案手动指定从库上的哪个站点，主库将发送该站点，而不判断日志的完整性。
GTID解决方案通过主数据库自动计算位置，无需手动设置位置，对运维人员友好。 4、如何判断主从库是否有延迟。
上面提到的问题6是主从读写分离后，从库复制存在延迟。接下来我们讨论一下如何观察主从延迟。
方案一：判断从库同步状态参数seconds_behind_master是否为0。（不准确）方案二：对比站点，确保主备设备之间没有延迟。
方案三：比较GTID设置，保证主备无延时。选项 1：检查 secondary_behind_master。
可以在从库上执行slow Slave status命令，查看执行结果中的seconds_behind_master参数的值。如下图，Seconds_Behind_Master等于0。
Seconds_Behind_Master的单位是秒，所以精度不准确。因此，为了保证查询到的数据与主库一致，需要先判断seconds_behind_master是否等于0，如果不等于0，则必须等到该参数变为0后才能执行查询请求。
方案二：比对站点可以通过检查从库当前同步站点来确认从库同步是否存在延迟。下图是从库执行show Slave status\G命令后的结果：Master_Log_File和Read_Master_Log_Pos。
这两个参数共同代表了主库读取的最新位置。第一个参数表示读取的是哪个文件。
，第二个是读取文件的位置。 Relay_Master_Log_File 和 Exec_Master_Log_Pos，这两个参数一起代表了库的最新执行点。
如果红框中的两个参数：Master_Log_File和Relay_Master_Log_File相等，则说明从库读取到的最新文件与主库上生成的文件相同，这里都是mysql-bin.34。如果蓝色框中的Read_Master_Log_Pos和Exec_Master_Log_Pos两个参数相等，则说明从库读取的日志文件的位置与从库执行的日志文件的位置相同，这里都是。
当以上两组参数相等时，表示没有延迟。选项 3：比较 GTID 集合 选项 3 是比较 GTID 集合。
首先，我们在从库上执行show Slave status \G，查看GTID集合。如下图所示：Master_UUID代表当前连接的主库的ID。
Auto_Position：1表示主备设备使用GTID协议。 Retrieved_Gtid_Set 表示从库接收到的所有日志的 GTID 集。
Executed_Gtid_Set表示从库已经执行过的GTID集。如果Executed_Gtid_Set集合中包含Retrieved_Gtid_Set，则表示从库接收到的日志已经同步。
例如上图中，Retrieved_Gtid_Set的值为代码语言：javascript copy c5d6-d7ec-11ec-bf8f-ac02:1-3。第一段是主库id，后面的1-3段是GTID范围。
Executed_Gtid_Set 的值有两种设置代码语言： javascript copy ae1f-d7ef-11ec-aac02:1-2,c5d6-d7ec-11ec-bf8f-ac02:1-3 第二组 Executed_Gtid_Set 与第一组完全相同，第一个集合id和集合范围是另一个主库上次同步的记录。这说明从库已经和当前主库同步了。
选项2的比较站点和选项3的GTID比较都比选项1的seconds_behind_master更准确。但是仍然不准确，需要半同步复制才能实现。
总结：本文利用GTID更好的实现主从节点的同步以及如何观察主从同步的延迟。参考资料： MySQL第四版黄金食谱：MySQL性能优化金字塔法则 我正在参加腾讯云开发者社区数据库专题有奖征文比赛。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
06-18
06-17
06-17
06-21
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用