written by 小旋風(fēng)
業(yè)界很多的兄弟都對MySQL 趨之若鶩，甚是喜歡，因?yàn)樗?可愛（安裝包小 小巧玲瓏），單純（安裝簡單、使用簡單 易上手），真誠（開源），善解人意（功能強(qiáng)勁、持續(xù)改進(jìn)）。
你卻因?yàn)椴焕斫庹`以為她 “不專一”（主從不一致，其實(shí)是可以主從一致的），逐漸對她若離若棄。 她在燈火闌珊處翹首以盼你的驀然回首，你卻冷冷的一笑而過，她只能黯然
傷神念叨著：“你不懂我，我不怪你”。其實(shí)不怪你才怪。

下面小編就帶你去認(rèn)知mysql carsh_safe replication 的內(nèi)心世界

crash-safe replication 定義
  當(dāng)master/salve 任何一個節(jié)點(diǎn)發(fā)生宕機(jī)等意外情況，服務(wù)器重啟后master/salve數(shù)據(jù) 仍然保持一致性。
 
包含
 master crash-safe replication     
 slave  crash-safe replication

master crash-safe replication 
  需要配置3個參數(shù)。
  innodb-flush-log-at-trx-commit=1
  sync_binlog=1
  innodb-xa-support=1

詳解：
 master crash-safe  replication  只要保證事務(wù)和其二進(jìn)制的持久性就 ok。
 為了保證持久性，必須要保證 每提交一個事務(wù) 都要 持久化 redo log 到 重做日志文件  和 bin log 到 二進(jìn)制日志文件(保證主從庫數(shù)據(jù)一致性)。
 并且要確保 每commit 一個事務(wù)時 保存2個文件的原子性，由于是不同的文件需要開啟分布式事務(wù)。

innodb-flush-log-at-trx-commit=1 
    每commit 一個事務(wù) 都要調(diào)用fsync 把其產(chǎn)生的redo log 信息保存到 磁盤上的 重做日志文件上。
    從而保證事務(wù)的持久性。發(fā)生故障重啟mysql server 通過redo log進(jìn)行恢復(fù)。

sync_binlog=1      
  每commit 一個事務(wù) 保存其二進(jìn)制日志到二進(jìn)制文件,保證主從數(shù)據(jù)一致性

innodb-xa-support=1  
  開啟分布式事務(wù) 


slave crash-safe replication
  需要配置3個參數(shù)
  innodb-flush-log-at-trx-commit=1
  relay_log_info_repository=table
  relay_log_recovery=on

slave 非正常關(guān)閉 經(jīng)常會出現(xiàn)的問題：
  不斷的1062 主鍵沖突錯誤
    why？
    skip-slave-error=1062 ？？？
  主從數(shù)據(jù)不一致

是不是經(jīng)常碰到slave 宕掉后，復(fù)制報1062 主鍵沖突。可能你會直接執(zhí)行 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1   跳過一個錯誤。為什么想過沒有呢 ？
小編一向認(rèn)為 為什么 要比 是什么來的重要，我們要知其然知其所以然，這樣才可以避免錯誤。下面就隨俺理理吧

SQL  thrend  主要做2件事
  1： 回放 relay log 中事務(wù)信息
  2： 更新 relay_log.info文件里的信息。確保下次重啟服務(wù)，讓SQL  thrend  曉得從那個relay log 文件 的那個位置繼續(xù)開始回放

why：
問題就出現(xiàn)在步驟2上，跟新 relay_log.info 文件是緩存寫，其中 由 參數(shù) sync_relay_log_info 控制寫到 relay_log.info文件的時機(jī)。
其默認(rèn)值是1000，意思是 每執(zhí)行10000個 relay log 中的事務(wù)才寫一次盤。就算是把sync_relay_log_info=1 也是有可能重復(fù)執(zhí)行1個事物的。
并且這樣頻繁的刷盤，會導(dǎo)致系統(tǒng)性能嚴(yán)重下降不可取。

salve 報 1062 場景實(shí)例解析：
 假設(shè) slave 上現(xiàn)在SQL thread  已經(jīng)回放了95000 個事務(wù)，此時的 relay_log.info文件 記錄的位置是30500【第90000 個事務(wù)位置】那么此時salve 宕機(jī)了，
 重啟后 SQL thread 讀取 relay_log.info 得到已經(jīng)執(zhí)行到 某個 relay log 文件 的30500 位置 即 第90000 個事務(wù)位置，然后又重新執(zhí)行90000-95000 的事務(wù)，又因?yàn)?br /> 有主鍵約束自然就報 主鍵沖突了。

主從數(shù)據(jù)不一致 why
 同樣是上面的問題，如果沒有主鍵約束，insert 數(shù)據(jù)就會重復(fù)執(zhí)行，從庫就會多出重新執(zhí)行的 insert 數(shù)據(jù)。
 一般 bin log 都是基于row 的， insert  不是冪等的 ,update  是冪等的。冪等：f(x)=f(f(x))  也就是此時 導(dǎo)致master/salve 不一致的都是insert 語句且表中沒有主鍵

解決方案：
MySQL 5.6 crash safe ：   relay_log_info_repository=table
  relay-info.log的信息保存在InnoDB的事務(wù)表
  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

這樣就使得 執(zhí)行 relay log 中的 事務(wù) log event 與 更新 relay_log.info 的原子性。

 IO thread
   接收binary log event
   更新master-info.log
緩存寫
  sync_master_info
解決方案
  relay_log_recovery=on
  確保binary log還在master服務(wù)器上

這與SQL thread 同理 ,會重復(fù)接受binary log event，解決的方案是relay_log_recovery=on 配合 之前的 relay_log_info_repository=table
即每次重啟服務(wù)IO thread  會讀取mysql.slave_relay_log_info表 中的 Master_log_name   Master_log_pos  即 IO thread  會重新到
 master 上從指定 二進(jìn)制文件 Master_log_name   的指定位置Master_log_pos  繼續(xù)拉數(shù)據(jù)，前提是master 對應(yīng)的二進(jìn)制的文件還在。

網(wǎng)站題目：mysqlmaster/slavecrash_safereplication：你不懂我我不怪你
當(dāng)前地址：http://www.js-pz168.com/article8/gieiop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、品牌網(wǎng)站建設(shè)、、手機(jī)網(wǎng)站建設(shè)、動態(tài)網(wǎng)站、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)