mysqlmaster/slavecrash_safereplication：你不懂我我不怪你

written by 小旋风
业界很多的兄弟都对MySQL 趋之若鹜，甚是喜欢，因为它的可爱（安装包小小巧玲珑），单纯（安装简单、使用简单易上手），真诚（开源），善解人意（功能强劲、持续改进）。
你却因为不理解误以为她 “不专一”（主从不一致，其实是可以主从一致的），逐渐对她若离若弃。她在灯火阑珊处翘首以盼你的蓦然回首，你却冷冷的一笑而过，她只能黯然
伤神念叨着：“你不懂我，我不怪你”。其实不怪你才怪。

下面小编就带你去认知mysql carsh_safe replication 的内心世界

crash-safe replication 定义
当master/salve 任何一个节点发生宕机等意外情况，服务器重启后master/salve数据仍然保持一致性。

包含
master crash-safe replication
slave crash-safe replication

master crash-safe replication
需要配置3个参数。
  innodb-flush-log-at-trx-commit=1
  sync_binlog=1
  innodb-xa-support=1

详解：
master crash-safe replication  只要保证事务和其二进制的持久性就 ok。
为了保证持久性，必须要保证每提交一个事务都要持久化 redo log 到重做日志文件和 bin log 到二进制日志文件(保证主从库数据一致性)。
并且要确保每commit 一个事务时保存2个文件的原子性，由于是不同的文件需要开启分布式事务。

innodb-flush-log-at-trx-commit=1
  每commit 一个事务都要调用fsync 把其产生的redo log 信息保存到磁盘上的重做日志文件上。
从而保证事务的持久性。发生故障重启mysql server 通过redo log进行恢复。

sync_binlog=1
  每commit 一个事务保存其二进制日志到二进制文件,保证主从数据一致性

innodb-xa-support=1
  开启分布式事务

slave crash-safe replication
需要配置3个参数
innodb-flush-log-at-trx-commit=1
relay_log_info_repository=table
relay_log_recovery=on

slave 非正常关闭经常会出现的问题：
不断的1062 主键冲突错误
  why？
  skip-slave-error=1062 ？？？
主从数据不一致

是不是经常碰到slave 宕掉后，复制报1062 主键冲突。可能你会直接执行 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 跳过一个错误。为什么想过没有呢？
小编一向认为为什么要比是什么来的重要，我们要知其然知其所以然，这样才可以避免错误。下面就随俺理理吧

SQL thrend 主要做2件事
1：回放 relay log 中事务信息
2：更新 relay_log.info文件里的信息。确保下次重启服务，让SQL  thrend 晓得从那个relay log 文件的那个位置继续开始回放

why：
问题就出现在步骤2上，跟新 relay_log.info 文件是缓存写，其中由参数 sync_relay_log_info 控制写到 relay_log.info文件的时机。
其默认值是1000，意思是每执行10000个 relay log 中的事务才写一次盘。就算是把sync_relay_log_info=1 也是有可能重复执行1个事物的。
并且这样频繁的刷盘，会导致系统性能严重下降不可取。

salve 报 1062 场景实例解析：
假设 slave 上现在SQL thread 已经回放了95000 个事务，此时的 relay_log.info文件记录的位置是30500【第90000 个事务位置】那么此时salve 宕机了，
重启后 SQL thread 读取 relay_log.info 得到已经执行到某个 relay log 文件的30500 位置即第90000 个事务位置，然后又重新执行90000-95000 的事务，又因为
有主键约束自然就报主键冲突了。

主从数据不一致 why
同样是上面的问题，如果没有主键约束，insert 数据就会重复执行，从库就会多出重新执行的 insert 数据。
一般 bin log 都是基于row 的， insert 不是幂等的 ,update 是幂等的。幂等：f(x)=f(f(x)) 也就是此时导致master/salve 不一致的都是insert 语句且表中没有主键

解决方案：
MySQL 5.6 crash safe ：   relay_log_info_repository=table
relay-info.log的信息保存在InnoDB的事务表
BEGIN;
apply log event;
apply log event;
UPDATE mysql.slave_relay_log_info
  SET Master_log_pos = Exec_Master_Log_Pos,
  Master_log_name = Relay_Master_Log_File,
  Relay_log_name = Relay_Log_File,
  Relay_log_pos = Relay_Log_Pos;
COMMIT

这样就使得执行 relay log 中的事务 log event 与更新 relay_log.info 的原子性。

IO thread
   接收binary log event
更新master-info.log
缓存写
  sync_master_info
解决方案
relay_log_recovery=on
确保binary log还在master服务器上

这与SQL thread 同理 ,会重复接受binary log event，解决的方案是relay_log_recovery=on 配合之前的 relay_log_info_repository=table
即每次重启服务IO thread 会读取mysql.slave_relay_log_info表中的 Master_log_name   Master_log_pos 即 IO thread 会重新到
master 上从指定二进制文件 Master_log_name   的指定位置Master_log_pos 继续拉数据，前提是master 对应的二进制的文件还在。

本文标题：mysqlmaster/slavecrash_safereplication：你不懂我我不怪你
网页网址：http://jkwzsj.com/article/gieiop.html

mysqlmaster/slavecrash_safereplication：你不懂我我不怪你

其他资讯