本文转载自“爱可生开源社区”公众号
mysql> select * from mysql.slave_relay_log_info\G
*************************** 1. row ***************************
Number_of_lines: 7
Relay_log_name: ./mysql-relay.000015
Relay_log_pos: 621
Master_log_name: mysql-bin.000001
Master_log_pos: 2407
Sql_delay: 0
Number_of_workers: 16
Id: 1
Channel_name:
slave_relay_log_info 表存储 slave sql thread 的工作位置。
slave_relay_log_info 表存储的是持久化的状态、show slave status 输出的是内存中的状态:
两者输出的位置可能不一样
stop slave 或者正常关闭 mysqld,都会将内存中的状态持久化到磁盘上(slave_relay_log_info表中)
启动 mysqld 时会读取磁盘状态,初始化给内存状态
start slave 时生效的是内存状态
slave io thread 按照 Master_Log_File、Read_Master_Log_Pos 位置读取主库的 binlog,并写入到本地 relay log(注意这两个位点信息保存在 slave_master_info 表中);slave sql thread 按照 Relay_Log_Name、Relay_Log_Pos 位置进行 realy log 的回放。
更新机制
sync_relay_log_info = 0
If relay_log_info_repository is set to FILE, the MySQL server performs no synchronization of the relay- log.info file to disk; instead, the server relies on the operating system to flush its contents periodically as with any other file.
If relay_log_info_repository is set to TABLE, and the storage engine for that table is transactional, the table is updated after each transaction. (Thesync_relay_log_info setting is effectively ignored in this case.)
If relay_log_info_repository is set to TABLE, and the storage engine for that table is not transactional, the table is never updated.
sync_relay_log_info = N > 0
If relay_log_info_repository is set to FILE, the slave synchronizes its relay-log.info file to disk (using fdatasync()) after every N transactions.
If relay_log_info_repository is set to TABLE, and the storage engine for that table is transactional, the table is updated after each transaction. (Thesync_relay_log_info setting is effectively ignored in this case.)
If relay_log_info_repository is set to TABLE, and the storage engine for that table is not transactional, the table is updated after every N events.
一般的运维规范都会要求 relay_log_info_repository=TABLE,默认值 sync_relay_log_info=10000 此时会失效,变成每回放一个事务都会在这个事务里同时更新 mysql.slave_relay_log_info 表,保证持久性,以最终保证复制的数据一致。当然 InooDB 的持久性需要 innodb_flush_log_at_trx_commit=1 来保证。
前面有一句话“也就是说从库的数据是否正确,io thread 的位置是否正确也非常重要”。简单来说 io thread 位置保存在 slave_master_info 表中,其实设置和 relay_log_info_repository 类似,不同的是它的持久化保障通常与性能冲突很大:
-
必须设置 master_info_repository = TABLE 和 sync_master_info=1,刷盘的单位是 binlog event 而不是事务,写放大很严重,性能损耗大
master_auto_position
master_auto_position 的作用是根据从库的 Executed_Gtid_Set 自动寻找主库上对应 binlog 位置,这是在 GTID 出现后的一个功能。
这里思考一个问题:开启 master_auto_position 后,slave io thread 能直接根据从库的 Executed_Gtid_Set 定位主库上 binlog 的位置吗?还需要 slave_relay_log_info、slave_master_info 表中记录的位点信息吗?
其实 slave_relay_log_info、slave_master_info 表依然发挥作用:
-
当第一次或者 reset slave 后,执行 start slave,io thread 将从库的 Executed_Gtid_Set 发往主库,获取到对应的 File、Position,之后更新到从库的 slave_relay_log_info、slave_master_info 表中
-
当 slave_relay_log_info、slave_master_info 表中存在位置信息后,此后无论是重启复制还是重启 mysqld,都是直接从这两个地方获取 File、Position,并从这里开始读取 binlog 和回放 relay log
relay_log_recovery
当启用 relay_log_recovery,mysqld 启动时,recovery 过程会生成一个新的 relay log,并初始化 slave sql thread 的位置,表现为:
-
slave_relay_log_info 表的 Relay_Log_Name 值更新为最新的日志名, Relay_Log_Pos 值更新为一个固定值 4(应该是头部固定信息占 4个偏移量)
-
内存状态即 show slave status 输出中的 Relay_Log_File、Relay_Log_Pos,也更新成上面一样的
-
slave_master_info 表中的 Master_log_name、Master_log_pos 不会改变
-
内存状态即 show slave status 输出中的 Master_Log_File、Read_Master_Log_Pos,会更新为 slave_relay_log_info 表中 Master_Log_Name、Master_Log_Pos
-
slave_relay_log_info 表中的 Relay_log_name 与 Master_log_name,Relay_Log_Pos 与 Master_Log_Pos 始终一一对应,代表同一个事务的位置。
一些结论
-
当开启 GTID 和 master_auto_position,并设置 relay_log_recovery=1,即使 relay_log_info_repository 设置为 file,操作系统或者 mysqld crash 后,mysqld 下次重启启动复制都能保证数据与主库一致。即使 slave_relay_log_info 表中记录的位置不是最新的,sql thread 可能会重复回放一部分事务,但是从库已经存在这些事务的 GTID,这部分重复的事务会被跳过。
-
当未开启 GTID 和 master_auto_position,必须要设置 relay_log_info_repository=table、relay_log_recovery=1,操作系统或者 mysqld crash 后,mysqld 下次重启启动复制才能保证数据与主库一致。
扫码加入QQ技术交流群