MySql教程

MySQL 主备同步技术演化

本文主要是介绍MySQL 主备同步技术演化,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

主库出问题了,从库怎么办?

备库:同步主库的binlog,当主库出问题时,备库切换为主库。一般不提供读服务。
从库:同步主库的binlog,只对外提供读服务。

一主多从基本结构

一主多从主备切换 方法

基于位点的主备切换

首先我们知道,设置从库时的命令

CHANGE MASTER TO 
MASTER_HOST=$host_name 
MASTER_PORT=$port 
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
MASTER_LOG_FILE=$master_log_name 
MASTER_LOG_POS=$master_log_pos  

master_log_file和master_log_pos 表示从主库的这个文件的pos位置开始同步,

那如何获取这个pos位置呢?

一种取同步位点的方法是这样的:

  1. 等待新主库 A’把中转日志(relay log)全部同步完成;
  2. 在 A’上执行 show master status 命令,得到当前 A’上最新的 File 和 Position;
  3. 取原主库 A 故障的时刻 T;
  4. 用 mysqlbinlog 工具解析 A’的 File,得到 T 时刻的位点。

通过命令show master status 可以得到file和pos。这里的pos是最新的,从库同步的话,是需要找故障时刻T的位点,执行 mysqlbinlog File --stop-datetime=T --start-datetime=T 获取到end_log_pos 作为通步的位点。

这种取同步位点的方法是不精确的,往往在执行的时候,需要执行一些辅助命令来跳过某些错误。

  1. 主动跳过一个事务
set global sql_slave_skip_counter=1;
start slave;

缺点是没遇到一个错误,就需要手动执行一次。

  1. 指定错误码跳过
set slave_skip_errors = "1032,1062";
start slave;

在执行主备切换时,有这么两类错误,是经常会遇到的:

  1. 1062 错误是插入数据时唯一键冲突;
  2. 1032 错误是删除数据时找不到行。

千万注意,主备切换后,要将这个参数设置为空

GTID

MySQL 5.6版本引入了GTID,将自动找位点的这一步骤完全自动化了。

那什么是GTID?

GTID 的全称是 Global Transaction Identifier,也就是全局事务 ID,是一个事务在提交的时候生成的,是这个事务的唯一标识。
GTID=server_uuid:gno

1, server_uuid 是一个实例第一次启动时自动生成的,是一个全局唯一的值
2. gno 是一个整数,初始值是 1,每次提交事务的时候分配给这个事务,并加 1。

gtid_next=automatic 代表使用默认值。
如果设置gtid_next=current_gtid, 如果current_gtid已经在实例的gtid集合中,接下来这个事务会被直接跳过,否则分配current_gtid给接下来的事务执行。注意:每个MySQL实例都维护了一个GTID集合,用来对应执行过的所有事务

基于GTID的主备切换

命令差不多

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协议。

模拟以下GTID的主备切换。实例A的gtid集合为set_a, 实例B的gtid集合为set_b.

  1. 实例B使用change master 设置主库,使用master_auto_position参数。
  2. 实例B将set_b 发送给主库A
  3. 实例A算出set_a 与 set_b 之间的差集,即只在set_a的gtid,然后判断A的binlog是否有这个差集的所有事务,如果少了一些,则会返回错误给B,拒绝实例B建立主从同步,否则找出差集中的第一个gtid给实例B,完成主动找pos的过程
  4. 之后就从binlog这个位置将事务发给B取执行。

最后一个问题:基于gtid的主备切换,怎么解决主库因为binlog缺少某些事务而拒绝建立主从同步呢?

  1. 如果业务允许主从不一致的情况,那么可以在主库上先执行 show global variables like ‘gtid_purged’,得到主库已经删除的 GTID 集合,假设是 gtid_purged1;然后先在从库上执行 reset master,再执行 set global gtid_purged =‘gtid_purged1’;最后执行 start slave,就会从主库现存的 binlog 开始同步。binlog 缺失的那一部分,数据在从库上就可能会有丢失,造成主从不一致。
  2. 如果需要主从数据一致的话,最好还是通过重新搭建从库来做。
  3. 如果有其他的从库保留有全量的 binlog 的话,可以把新的从库先接到这个保留了全量 binlog 的从库,追上日志以后,如果有需要,再接回主库。
  4. 如果 binlog 有备份的情况,可以先在从库上应用缺失的 binlog,然后再执行 start slave。
这篇关于MySQL 主备同步技术演化的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!