mysql master/slave crash_safe replication ：你不懂我 我不怪你

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 对应的二进制的文件还在。