摘要：問題原因非正常關機導致沒有把數據及時的寫入硬盤。丟失的臨時表臨時表和基于語句的復制方式不相容。如果備庫崩潰或者正常關閉，任何復制線程擁有的臨時表都會丟失。臨時表的特性只對創建臨時表的連接可見。

主備復制過程中有很大可能會出現各種問題，接下來我們就討論一些比較普遍的問題，以及當遇到這些問題時，如何解決或者預防問題發生。

問題描述：服務器崩潰、斷電、磁盤損壞、內存或網絡錯誤等問題，導致數據損壞或丟失。
問題原因：非正常關機導致沒有把數據及時的寫入硬盤。

這種問題，一般可以分為幾種情況導致：

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

備庫意外關閉重啟時，會去讀 master.info 文件以找到上次停止復制的位置。但是在意外關閉的情況下，這個文件存儲的信息可能是錯誤的。此外，備庫也可能會嘗試重新執行一些二進制文件，這可能會導致唯一索引錯誤。我們可以通過 Percona Toolkit 中的 pt-slave-restart 工具，幫助備庫重新執行日志文件。

如果使用的是 InnoDB 表，可以在重啟后觀察 MySQL 的錯誤日志。InnoDB 在恢復過程中會打印出恢復點的二進制日志坐標，可以使用這個值來決定備庫指向主庫的偏移量。

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

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

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

由于各種各樣的原因，MySQL 的復制碰到服務器崩潰、斷電、磁盤損壞、內存或網絡錯誤時，很難恢復當時丟失的數據。幾乎都需要從某個點開始重啟復制。

如果沒有再 my.cnf 里定義服務器 ID，雖然可以通過 CHANGE MASTER TO 來設置備庫，但在啟動復制時會遇到：

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

這個報錯可能會讓人困惑。因為我們可能已經通過 CHANGE MASTER TO 設置了備庫，并且通過 SHOW MASTER STATUS 也確認了，為什么還會有這樣的報錯呢？我們通過 SELECT @@server_id 可以獲得一個值，要注意的是，這個值只是默認值，我們必須為備庫顯式地設置服務器 ID。也就是在 my.cnf 里顯示的設置服務器 ID。

如果在主庫上有備庫上不存在的數據庫或數據表，復制就很容易中斷，反之亦然。
對于前者，假設在主庫上有一個 single_master 表，備庫沒有。在主庫上對此表進行操作后，備庫在嘗試回放這些操作時就會出現問題，導致復制中斷。

對于后者，假設備庫上有一個 single_slave 表，主庫沒有。在主庫上執行創建 single_slave 表的語句時，備庫在回放該建表語句時就會出現問題。

對于此問題，我們能做的就是做好預防：

主備切換時，盡量在切換后對比數據，查清楚是否有不一致的表或庫。

一定不要在備庫執行寫操作。

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

復制時出現找不到臨時表的異常時，可以做：

直接跳過錯誤，或者手動地創建一個名字和結構相同的表來代替消失的的臨時表。

臨時表的特性：

只對創建臨時表的連接可見。不會和其他擁有相同名字的臨時表的連接起沖突；

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

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

偽臨時表的優劣勢
優勢：

更容易調試應用程序。可以通過別的連接來查看應用正在維護的數據；

劣勢：

比臨時表多一些開銷。創建較慢偽臨時表會較慢，因為表的 .frm 文件需要刷新到磁盤。

使用共享鎖，串行化更新，保證備庫復制時數據一致。

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

事務 1 使用獲取 tab2 數據時，加入共享鎖，并插入 tab1；

同時，事務 2 更新 tab2 數據時，由于寫操作的排它鎖機制，無法獲取 tab2 的鎖，等待；

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

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

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

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

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

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

事務 1 提交事務，寫入 binlog（此時記錄值無變化）；

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

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

產生延遲的兩種方式

突然產生延遲，然后再跟上；

穩定的延遲增大

前者通常是由于一條執行時間過長的 SQL 導致，而后者即使在沒有慢語句也會出現。

對于前者，我們可以通過備庫上的慢查詢日志來進行優化。在備庫上開啟 log_slow_slave_statement 選項，可以在慢查詢日志中記錄復制線程執行的語句。

而對于后者，沒有針對性的解決方案，只能通過各種方式提高備庫的復制效率。而當我們想去對備庫做優化時，會發現，除了購買更快的磁盤和 CPU，并沒有太多的調優空間。只能通過 MySQL 選項禁止某些額外的工作以減少備庫的復制。可以通過下面幾種方式：

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

禁止二進制日志記錄。把 innodb_locks_unsafe_for_binlog 設置為 1，并把 MyISAM 的 delay_key_write 設置為 ALL。要注意的是，這些設置是以安全換取速度，在將備庫提升為主庫時，記得把這些選項設置回安全的值。

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

復制問題要分清楚是 master 的問題，還是 slave 的問題。

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