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://bjjierui.cn/article/gieiop.html
