写的小旋风
业界很多的兄弟都对mysql趋之若鹜,甚是喜欢,因为它的可爱(安装包小小巧玲珑),单纯(安装简单,使用简单易上手),真诚(开源),善解人意(功能强劲,持续改进)。
你却因为不理解误以为她“不专一”(主从不一致,其实是可以主从一致的),逐渐对她若离若弃只她在灯火阑珊处翘首以盼你的蓦然回首,你却冷冷的一笑而过,她只能黯然
伤神念叨着:“你不懂我,我不怪你”。其实不怪你才怪。
下面小编就带你去认知mysql carsh_safe复制的内心世界
crash-safe复制定义
,当主/药膏任何一个节点发生宕机等意外情况,服务器重启后主/药膏数据仍然保持一致性。
,
包含
,主crash-safe replication ,,,,
,奴隶crash-safe复制
<强>主crash-safe replication
,需要配置3个参数。
innodb-flush-log-at-trx-commit才能=1
sync_binlog才能=1
innodb-xa-support才能=1
详解:
,主crash-safe只要保证事务和其二进制的持久性就好。
,为了保证持久性,必须要保证每提交一个事务都要持久化重做日志到重做日志文件,和本日志到二进制日志文件(保证主从库数据一致性)。
,并且要确保每提交一个事务时保存2个文件的原子性,由于是不同的文件需要开启分布式事务。
innodb-flush-log-at-trx-commit=1,
,,,每提交一个事务都要调用fsync把其产生的重做日志信息保存到磁盘上的重做日志文件上。
,,从而保证事务的持久性。发生故障重启mysql服务器通过重做日志进行恢复。
sync_binlog=1,,,
,,每提交一个事务保存其二进制日志到二进制文件,保证主从数据一致性
innodb-xa-support=1,
开才能启分布式事务,
<强> <>强奴隶crash-safe复制
,需要配置3个参数
,relay_log_info_repository=表
,relay_log_recovery=
奴隶非正常关闭经常会出现的问题:
,1062年不断的主键冲突错误
,,,为什么?
,skip-slave-error=1062才能? ? ?
,主从数据不一致
是不是经常碰到奴隶宕掉后,复制报1062主键冲突。可能你会直接执行,集全球SQL_SLAVE_SKIP_COUNTER=1,跳过一个错误。为什么想过没有呢?
小编一向认为为什么要比是什么来的重要,我们要知其然知其所以然,这样才可以避免错误。下面就随俺理理吧
SQL, thrend,主要做2件事
,1:回放中继日志中事务信息
,2:更新relay_log.info文件里的信息。确保下次重启服务,让继续开始回放
原因:
问题就出现在步骤2上,跟新是缓存写,其中由参数,sync_relay_log_info控制写到就算是把
药膏报,
,假设奴隶上现在SQL线程,已经回放了95000个事务,,然后又重新执行90000 - 95000的事务,又因为
,有主键约束自然就报主键冲突了。
为什么
,同样是上面的问题,如果没有主键约束,插入数据就会重复执行,从库就会多出重新执行的插入数据。
,一般本日志都是基的于行,插入,不是幂等的,更新,是幂等的,幂等:f (x)=f (f (x)),也就是此时导致主/药膏不一致的都是插入语句且表中没有主键
<>强解决方案:
MySQL 5.6事故安全:
,relay-info。日志的信息保存在InnoDB的事务表
,开始,
,,应用日志事件;
,,应用日志事件;
,更新mysql。slave_relay_log_info
设置才能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;
,提交
这样就使得执行日志中继电器的事务日志事件与更新relay_log.info的原子性。
<强> <>强,IO线程
,,接收二进制日志事件
,,更新master-info。日志
缓存写
sync_master_info才能
解决方案
,relay_log_recovery=
,确保二进制日志还在主服务器上
这与SQL thread 同理,会重复接受配合之前的,
即每次重启服务会读取,,即,IO线程,会重新到
业界很多的兄弟都对mysql趋之若鹜,甚是喜欢,因为它的可爱(安装包小小巧玲珑),单纯(安装简单,使用简单易上手),真诚(开源),善解人意(功能强劲,持续改进)。
你却因为不理解误以为她“不专一”(主从不一致,其实是可以主从一致的),逐渐对她若离若弃只她在灯火阑珊处翘首以盼你的蓦然回首,你却冷冷的一笑而过,她只能黯然
伤神念叨着:“你不懂我,我不怪你”。其实不怪你才怪。
下面小编就带你去认知mysql carsh_safe复制的内心世界
crash-safe复制定义
,当主/药膏任何一个节点发生宕机等意外情况,服务器重启后主/药膏数据仍然保持一致性。
,
包含
,主crash-safe replication ,,,,
,奴隶crash-safe复制
<强>主crash-safe replication
,需要配置3个参数。
innodb-flush-log-at-trx-commit才能=1
sync_binlog才能=1
innodb-xa-support才能=1
详解:
,主crash-safe只要保证事务和其二进制的持久性就好。
,为了保证持久性,必须要保证每提交一个事务都要持久化重做日志到重做日志文件,和本日志到二进制日志文件(保证主从库数据一致性)。
,并且要确保每提交一个事务时保存2个文件的原子性,由于是不同的文件需要开启分布式事务。
innodb-flush-log-at-trx-commit=1,
,,,每提交一个事务都要调用fsync把其产生的重做日志信息保存到磁盘上的重做日志文件上。
,,从而保证事务的持久性。发生故障重启mysql服务器通过重做日志进行恢复。
sync_binlog=1,,,
,,每提交一个事务保存其二进制日志到二进制文件,保证主从数据一致性
innodb-xa-support=1,
开才能启分布式事务,
<强> <>强奴隶crash-safe复制
,需要配置3个参数
,relay_log_info_repository=表
,relay_log_recovery=
奴隶非正常关闭经常会出现的问题:
,1062年不断的主键冲突错误
,,,为什么?
,skip-slave-error=1062才能? ? ?
,主从数据不一致
是不是经常碰到奴隶宕掉后,复制报1062主键冲突。可能你会直接执行,集全球SQL_SLAVE_SKIP_COUNTER=1,跳过一个错误。为什么想过没有呢?
小编一向认为为什么要比是什么来的重要,我们要知其然知其所以然,这样才可以避免错误。下面就随俺理理吧
SQL, thrend,主要做2件事
,1:回放中继日志中事务信息
,2:更新relay_log.info文件里的信息。确保下次重启服务,让继续开始回放
原因:
问题就出现在步骤2上,跟新是缓存写,其中由参数,sync_relay_log_info控制写到就算是把
药膏报,
,假设奴隶上现在SQL线程,已经回放了95000个事务,,然后又重新执行90000 - 95000的事务,又因为
,有主键约束自然就报主键冲突了。
为什么
,同样是上面的问题,如果没有主键约束,插入数据就会重复执行,从库就会多出重新执行的插入数据。
,一般本日志都是基的于行,插入,不是幂等的,更新,是幂等的,幂等:f (x)=f (f (x)),也就是此时导致主/药膏不一致的都是插入语句且表中没有主键
<>强解决方案:
MySQL 5.6事故安全:
,relay-info。日志的信息保存在InnoDB的事务表
,开始,
,,应用日志事件;
,,应用日志事件;
,更新mysql。slave_relay_log_info
设置才能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;
,提交
这样就使得执行日志中继电器的事务日志事件与更新relay_log.info的原子性。
<强> <>强,IO线程
,,接收二进制日志事件
,,更新master-info。日志
缓存写
sync_master_info才能
解决方案
,relay_log_recovery=
,确保二进制日志还在主服务器上
这与SQL thread 同理,会重复接受配合之前的,
即每次重启服务会读取,,即,IO线程,会重新到
