摘要：?jiǎn)栴}原因非正常關(guān)機(jī)導(dǎo)致沒有把數(shù)據(jù)及時(shí)的寫入硬盤。丟失的臨時(shí)表臨時(shí)表和基于語句的復(fù)制方式不相容。如果備庫(kù)崩潰或者正常關(guān)閉，任何復(fù)制線程擁有的臨時(shí)表都會(huì)丟失。臨時(shí)表的特性只對(duì)創(chuàng)建臨時(shí)表的連接可見。

主備復(fù)制過程中有很大可能會(huì)出現(xiàn)各種問題，接下來我們就討論一些比較普遍的問題，以及當(dāng)遇到這些問題時(shí)，如何解決或者預(yù)防問題發(fā)生。

問題描述：服務(wù)器崩潰、斷電、磁盤損壞、內(nèi)存或網(wǎng)絡(luò)錯(cuò)誤等問題，導(dǎo)致數(shù)據(jù)損壞或丟失。
問題原因：非正常關(guān)機(jī)導(dǎo)致沒有把數(shù)據(jù)及時(shí)的寫入硬盤。

這種問題，一般可以分為幾種情況導(dǎo)致：

問題未發(fā)生，避免方案：設(shè)置主庫(kù)的 sync_binlog 選項(xiàng)為 1。此選項(xiàng)表示 MySQL 是否控制 binlog 的刷新。當(dāng)設(shè)置為 1 時(shí)，表示每次事務(wù)提交，MySQL 都會(huì)把 binlog 刷下去，是最安全，性能損耗也最大的設(shè)置。
問題已發(fā)生，解決方案：指定備庫(kù)從下一個(gè)二進(jìn)制日志的開頭重新讀日志。但是一些日志事件將永久性丟失。可以使用 Percona Toolkit 中的 pt-table-checksum 工具來檢查主備一致性，以便于修復(fù)。

備庫(kù)意外關(guān)閉重啟時(shí)，會(huì)去讀 master.info 文件以找到上次停止復(fù)制的位置。但是在意外關(guān)閉的情況下，這個(gè)文件存儲(chǔ)的信息可能是錯(cuò)誤的。此外，備庫(kù)也可能會(huì)嘗試重新執(zhí)行一些二進(jìn)制文件，這可能會(huì)導(dǎo)致唯一索引錯(cuò)誤。我們可以通過 Percona Toolkit 中的 pt-slave-restart 工具，幫助備庫(kù)重新執(zhí)行日志文件。

如果使用的是 InnoDB 表，可以在重啟后觀察 MySQL 的錯(cuò)誤日志。InnoDB 在恢復(fù)過程中會(huì)打印出恢復(fù)點(diǎn)的二進(jìn)制日志坐標(biāo)，可以使用這個(gè)值來決定備庫(kù)指向主庫(kù)的偏移量。

如果主庫(kù)上的二進(jìn)制日志損壞，除了忽略損壞的位置外，別無選擇。在忽略存貨位置后，我們可以通過 FLUSH LOGS 命令在主庫(kù)開始一個(gè)新的日志文件，然后將備庫(kù)指向該文件的開始位置。

如果主庫(kù)上的日志是完好的，有兩種解決方案：
1) 手工處理。找到 master binlog 日志的 pos 點(diǎn)，然后重新同步。

2) 自動(dòng)處理。mysql5.5 考慮到 slave 宕機(jī)中繼日志損壞這一問題，只要在 slave 的的配置文件 my.cnf 里增加一個(gè)參數(shù) relay_log_recovery=1 即可。

由于各種各樣的原因，MySQL 的復(fù)制碰到服務(wù)器崩潰、斷電、磁盤損壞、內(nèi)存或網(wǎng)絡(luò)錯(cuò)誤時(shí)，很難恢復(fù)當(dāng)時(shí)丟失的數(shù)據(jù)。幾乎都需要從某個(gè)點(diǎn)開始重啟復(fù)制。

如果沒有再 my.cnf 里定義服務(wù)器 ID，雖然可以通過 CHANGE MASTER TO 來設(shè)置備庫(kù)，但在啟動(dòng)復(fù)制時(shí)會(huì)遇到：

mysql> START SLAVE;
ERROR 1200 (HY000): The server us bit configured as slave; fix in config file or with CHANGE MASTER TO

這個(gè)報(bào)錯(cuò)可能會(huì)讓人困惑。因?yàn)槲覀兛赡芤呀?jīng)通過 CHANGE MASTER TO 設(shè)置了備庫(kù)，并且通過 SHOW MASTER STATUS 也確認(rèn)了，為什么還會(huì)有這樣的報(bào)錯(cuò)呢？我們通過 SELECT @@server_id 可以獲得一個(gè)值，要注意的是，這個(gè)值只是默認(rèn)值，我們必須為備庫(kù)顯式地設(shè)置服務(wù)器 ID。也就是在 my.cnf 里顯示的設(shè)置服務(wù)器 ID。

如果在主庫(kù)上有備庫(kù)上不存在的數(shù)據(jù)庫(kù)或數(shù)據(jù)表，復(fù)制就很容易中斷，反之亦然。
對(duì)于前者，假設(shè)在主庫(kù)上有一個(gè) single_master 表，備庫(kù)沒有。在主庫(kù)上對(duì)此表進(jìn)行操作后，備庫(kù)在嘗試回放這些操作時(shí)就會(huì)出現(xiàn)問題，導(dǎo)致復(fù)制中斷。

對(duì)于后者，假設(shè)備庫(kù)上有一個(gè) single_slave 表，主庫(kù)沒有。在主庫(kù)上執(zhí)行創(chuàng)建 single_slave 表的語句時(shí)，備庫(kù)在回放該建表語句時(shí)就會(huì)出現(xiàn)問題。

對(duì)于此問題，我們能做的就是做好預(yù)防：

主備切換時(shí)，盡量在切換后對(duì)比數(shù)據(jù)，查清楚是否有不一致的表或庫(kù)。

一定不要在備庫(kù)執(zhí)行寫操作。

臨時(shí)表和基于語句的復(fù)制方式不相容。如果備庫(kù)崩潰或者正常關(guān)閉，任何復(fù)制線程擁有的臨時(shí)表都會(huì)丟失。重啟備庫(kù)后，所有依賴于該臨時(shí)表的語句都會(huì)失敗。

復(fù)制時(shí)出現(xiàn)找不到臨時(shí)表的異常時(shí)，可以做：

直接跳過錯(cuò)誤，或者手動(dòng)地創(chuàng)建一個(gè)名字和結(jié)構(gòu)相同的表來代替消失的的臨時(shí)表。

臨時(shí)表的特性：

只對(duì)創(chuàng)建臨時(shí)表的連接可見。不會(huì)和其他擁有相同名字的臨時(shí)表的連接起沖突；

隨著連接關(guān)閉而消失，無須顯式的移除它們。

保留一個(gè)專用的數(shù)據(jù)庫(kù)，在其中創(chuàng)建持久表，把它們作為偽臨時(shí)表，以模擬臨時(shí)表特性。只需要通過 CONNETCTION_ID() 的返回值，給臨時(shí)表創(chuàng)建唯一的名字。

偽臨時(shí)表的優(yōu)劣勢(shì)
優(yōu)勢(shì)：

更容易調(diào)試應(yīng)用程序。可以通過別的連接來查看應(yīng)用正在維護(hù)的數(shù)據(jù)；

劣勢(shì)：

比臨時(shí)表多一些開銷。創(chuàng)建較慢偽臨時(shí)表會(huì)較慢，因?yàn)楸淼?.frm 文件需要刷新到磁盤。

使用共享鎖，串行化更新，保證備庫(kù)復(fù)制時(shí)數(shù)據(jù)一致。

某些情況下，加鎖讀可以防止混亂。假設(shè)有兩張表：tab1 沒有數(shù)據(jù)，tab2 只有一行數(shù)據(jù)，值為 99。此時(shí)，有兩個(gè)事務(wù)更新數(shù)據(jù)。事務(wù) 1 將 tab2 的數(shù)據(jù)插入到 tab1，事務(wù) 2 更新 tab2。

事務(wù) 1 使用獲取 tab2 數(shù)據(jù)時(shí)，加入共享鎖，并插入 tab1；

同時(shí)，事務(wù) 2 更新 tab2 數(shù)據(jù)時(shí)，由于寫操作的排它鎖機(jī)制，無法獲取 tab2 的鎖，等待；

事務(wù) 1 插入數(shù)據(jù)后，刪除共享鎖，提交事務(wù)，寫入 binlog（此時(shí) tab1 和 tab2 的記錄值 都是 99）；

事務(wù) 2 獲取到鎖，更新數(shù)據(jù)，提交事務(wù)，寫入 binlog（此時(shí) tab1 的記錄值為 99，tab2 的記錄值為 100）。

上述過程中，第二步非常重要。事務(wù) 2 嘗試去更新 tab2 表，這需要在更新的行上加排他鎖（寫鎖）。排他鎖與其他鎖不相容，包括事務(wù) 1 在行記錄上加的共享鎖。因此事務(wù) 2 需要等待事務(wù) 1 完成。備庫(kù)在根據(jù) binlog 進(jìn)行復(fù)制時(shí)，會(huì)按同樣的順序先執(zhí)行事務(wù) 1，再執(zhí)行事務(wù) 2。主備數(shù)據(jù)一致。

同樣的過程，如果事務(wù) 1 在第一步時(shí)沒有加共享鎖，流程就變成：

事務(wù) 1 無鎖讀取 tab2 數(shù)據(jù)，并插入 tab1（此時(shí) tab1 和 tab2 的記錄值 都是 99）；

同時(shí)，事務(wù) 2 更新 tab2 數(shù)據(jù)，先與事務(wù) 1 提交事務(wù)，寫入 binlog（此時(shí) tab1 的記錄值為 99，tab2 的記錄值為 100）；

事務(wù) 1 提交事務(wù)，寫入 binlog（此時(shí)記錄值無變化）；

mysqldump --single-transaction --all-databases --master-data=1 --host=server1 | mysql --host=server2
要注意的是，上述過程中，事務(wù) 2 先提交，先寫入 binlog。在備庫(kù)復(fù)制時(shí)，同樣先執(zhí)行事務(wù) 2，將 tab2 的記錄值更新為 100。然后執(zhí)行事務(wù) 1，讀取 tab2 數(shù)據(jù)，插入 tab1，所以最終的結(jié)果是，tab1 的記錄值和 tab2 的記錄值都是 100。很明顯，數(shù)據(jù)和主庫(kù)有差異。

建議在大多數(shù)情況下將 innodb_unsafe_for_binlog 的值設(shè)置為 0。基于行的復(fù)制由于記錄了數(shù)據(jù)的變化而非語句，因此不會(huì)存在這個(gè)問題。

產(chǎn)生延遲的兩種方式

突然產(chǎn)生延遲，然后再跟上；

穩(wěn)定的延遲增大

前者通常是由于一條執(zhí)行時(shí)間過長(zhǎng)的 SQL 導(dǎo)致，而后者即使在沒有慢語句也會(huì)出現(xiàn)。

對(duì)于前者，我們可以通過備庫(kù)上的慢查詢?nèi)罩緛磉M(jìn)行優(yōu)化。在備庫(kù)上開啟 log_slow_slave_statement 選項(xiàng)，可以在慢查詢?nèi)罩局杏涗洀?fù)制線程執(zhí)行的語句。

而對(duì)于后者，沒有針對(duì)性的解決方案，只能通過各種方式提高備庫(kù)的復(fù)制效率。而當(dāng)我們想去對(duì)備庫(kù)做優(yōu)化時(shí)，會(huì)發(fā)現(xiàn)，除了購(gòu)買更快的磁盤和 CPU，并沒有太多的調(diào)優(yōu)空間。只能通過 MySQL 選項(xiàng)禁止某些額外的工作以減少備庫(kù)的復(fù)制?？梢酝ㄟ^下面幾種方式：

使用 InnoDB 引擎時(shí)，設(shè)置 innodb_flush_log_at_trx_commit 值為 2，來使備庫(kù)不要頻繁的刷新磁盤，以提高事務(wù)提交效率。

禁止二進(jìn)制日志記錄。把 innodb_locks_unsafe_for_binlog 設(shè)置為 1，并把 MyISAM 的 delay_key_write 設(shè)置為 ALL。要注意的是，這些設(shè)置是以安全換取速度，在將備庫(kù)提升為主庫(kù)時(shí)，記得把這些選項(xiàng)設(shè)置回安全的值。

拆分效率較低的復(fù)制 SQL，分離復(fù)雜語句中的 SELECT 和 UPDATE 語句，降低復(fù)制消耗，提高效率。

復(fù)制問題要分清楚是 master 的問題，還是 slave 的問題。

master 問題找 binlog，slave 問題找 relaylog。