专注,勤学,慎思。戒骄戒躁,谦虚谨慎

just do it

导航

MySQL 复制 crash safe salve参数配置

 

 

在基于binlog文件位置的复制下,要保证crash safe slave,配置下面的参数即可。
relay_log_info_repository = TABLE
relay_log_recovery = ON
这样可行的原因是,relay_log_info_repository = TABLE时,apply event和更新relay_log_info表的操作被包含在同一个事务里,
innodb要么让它们同时生效,要么同时不生效,保证位点信息和已经应用的事务精确匹配。同时relay_log_recovery = ON时,
会抛弃master_log_info中记录的复制位点,根据relay_log_info的执行位置重新从Master获取binlog,
这就回避了由于未同步刷盘导致的binlog文件接受位置和实际不一致以及relay log文件被截断的问题。
在同时使用MTS(multi-threaded slave)时,为保证crash safe slave基于binlog文件位置的复制还需要设置sync_relay_log=1,
因为MySQL在Crash恢复时必须先通过读取relay log补齐MTS导致的事务空洞。


上面的设置并不适用于基于GTID的复制。在基于GTID的复制下,crash的Slave重启后,
从binlog中解析的gtid_executed决定了要apply哪些binlog记录,所以binlog必须和innodb存储引擎的数据保持一致。
要做到这一点,需要把sync_binlog和innodb_flush_log_at_trx_commit都设置为1,即所谓的"双1"。
另外MySQL启动时,会从relay log文件中获取已接收的GTIDs并更新Retrieved_Gtid_Set。由于relay log文件可能不完整,
所以需要抛弃已接收的relay log文件。因此relay_log_recovery = ON也是必须的。
这样,对于基于GTID的复制,保证crash safe slave的设置就是下面这样。
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
relay_log_recovery = ON

 

如果是MySQL 5.7可以关闭log_slave_updates,这样MySQL会将已执行的GTIDs实时记录到系统表mysql.gtid_executed中,
mysql.gtid_executed是和用户事务一起提交的,因此可以保证和实际的数据一致。
log_slave_updates = OFF
relay_log_recovery = ON

 

如果是MySQL 5.6可以采用如下变通的方式。
按照基于binlog文件复制时crash safe slave的要求设置relay_log_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON


在Slave crash后,根据relay_log_info_repository设置相应的gitd_purged再开启复制,步骤如下。

1.启动MySQL,但不开启复制
mysqld --skip-slave-start

2.在Slave上修改为基于binlog文件位置的复制
change master to MASTER_AUTO_POSITION = 0

3.启动slave IO线程
start slave io_thread
这里不能启动SQL线程,如果接受到的GTID已经在Slave的gtid_executed里了,会被Slave skip掉。

4.检查binlog传输的开始位置(即Retrieved_Gtid_Set的值)
show slave status\G
假设输出的Retrieved_Gtid_Set值为e10c75be-5c1b-11e6-ab7c-000c296078ae:7-10

5.在Master上检查gtid_executed
show master status
假设输出的Executed_Gtid_Set值为e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10

6.在Slave上设置gitd_purged为binlog传输位置的前面的GTID的集合
reset master;
set global gitd_purged='e10c75be-5c1b-11e6-ab7c-000c296078ae:1-6';

7.修改回auto position的复制
change master to MASTER_AUTO_POSITION = 1

8.启动slave SQL线程
start slave sql_thread

但是,这种变通的方法不适合多线程复制。因为多线程复制可能产生gtid gap和Gap-free low-watermark position,
这会导致Salve上重复apply已经apply过的event。后果就是数据不一致或者复制中断,
除非设置binlog格式为row模式并且slave_exec_mode=IDEMPOTENT,
slave_exec_mode=IDEMPOTENT允许Slave回放binlog时忽略重复键和找不到键的错误,使得binlog回放具有幂等性,
但这也意味着如果真的出现了主备数据不一致也会被它忽略。

到这里,我们可以看出master_info_repository 和relay_log_info_repository默认值被设置为TABLE(默认innodb),
主要还是从安全的方面考虑,依赖数据库的事务,可以保证relay_log_info_repository存储的点和数据库真正执行的点一致,
这一点FILE方式是无法做到的。同时在性能上,和文件系统的直接交互会增加io,而写table是直接写内存中的buffer pool,
在性能上也能有一定的提升。

首先都设置为TABLE是必要的,对性能有提升作用。
如果开启了gtid,就不需要太care了,因为不会重复执行同一个事务。
如果没有开启gtid,那就应该slave_relay_log_info的存储引擎支持事务,然后开启relay_log_recover即可。

 

https://mp.weixin.qq.com/s/7ZMj1LdD4MGttsLglcjD4g
https://mp.weixin.qq.com/s/IF1Pld-wGW0q2NiBjMXwfg?
http://www.ywnds.com/?p=12800

posted on 2019-01-14 16:48  MSSQL123  阅读(155)  评论(0编辑  收藏  举报