摘要：一旦使用的復(fù)制功能，就很大可能會(huì)碰到主備切換的情況。對(duì)于主備切換，如果是計(jì)劃內(nèi)的操作，較為容易至少比緊急情況下容易。可能有主庫(kù)上已發(fā)生的修改還沒(méi)有更新到它任何一臺(tái)備庫(kù)上的情況。假設(shè)是和的主庫(kù)。

一旦使用 MySQL 的復(fù)制功能，就很大可能會(huì)碰到主備切換的情況。也許是為了迭代升級(jí)服務(wù)器，或者是主庫(kù)出現(xiàn)問(wèn)題時(shí)，將一臺(tái)備庫(kù)轉(zhuǎn)換成主庫(kù)，或者只是希望重新分配容量。不過(guò)出于什么原因，都需要將新主庫(kù)的信息告訴其它備庫(kù)。

對(duì)于主備切換，如果是計(jì)劃內(nèi)的操作，較為容易（至少比緊急情況下容易）。只需在備庫(kù)簡(jiǎn)單的使用 CHANGE MASTER TO 命令，并指定合適的值即可。而且大多數(shù)的值是可選的，只要指定需要改變的配置項(xiàng)接口。

備庫(kù)將拋棄之前的配置和中繼日志，并從新的主庫(kù)開(kāi)始復(fù)制。同時(shí)，新的參數(shù)會(huì)被更新到 master.info 文件中，這樣就算重啟，備庫(kù)配置信息也不會(huì)丟失。

整個(gè)過(guò)程中最難的是獲取新主庫(kù)上合適的二進(jìn)制日志位置。這樣備庫(kù)才可以從老主庫(kù)相同的邏輯位置開(kāi)始復(fù)制。

把備庫(kù)提升為主庫(kù)要較為麻煩，我們把備庫(kù)提升主庫(kù)分為計(jì)劃內(nèi)切換和計(jì)劃外切換兩種場(chǎng)景。

備庫(kù)提升為主庫(kù)，簡(jiǎn)單來(lái)說(shuō)，有以下步驟：

停止向老主庫(kù)寫(xiě)入。

讓備庫(kù)追趕上主庫(kù)（可選，可以簡(jiǎn)化后續(xù)的步驟）。

將一臺(tái)備庫(kù)配置為新主庫(kù)。

將備庫(kù)和寫(xiě)操作指向新主庫(kù)，然后開(kāi)啟主庫(kù)寫(xiě)入。

但上面的過(guò)程中還因此著很多細(xì)節(jié)。一些場(chǎng)景可能依賴(lài)于復(fù)制的拓?fù)浣Y(jié)構(gòu)。更深入一點(diǎn)，下面是大多數(shù)配置需要的步驟：

停止當(dāng)前主庫(kù)上的所有寫(xiě)操作。如果可以，最好能將所有的客戶(hù)端程序關(guān)閉（除了復(fù)制連接）。

通過(guò) FLUSH TABLE WITH READ LOCK 命令在主庫(kù)上停止所有活躍的寫(xiě)入。也可以在主庫(kù)上設(shè)置 read_only 選項(xiàng)。意味著從這一刻起，禁止向老主庫(kù)做任何寫(xiě)入操作。因?yàn)橐坏┣袚Q的新主庫(kù)，老主庫(kù)的寫(xiě)入就意味著數(shù)據(jù)丟失。要注意的是，即使設(shè)置了 read_only 也不會(huì)阻止當(dāng)前已存在的事務(wù)繼續(xù)提交。因此，可以 kill 所有打開(kāi)的事務(wù)，真正的結(jié)束所有寫(xiě)入。

選擇一個(gè)備庫(kù)作為新的主庫(kù)，并確保它已經(jīng)完全跟上主庫(kù)（例如，讓它執(zhí)行完所有從主庫(kù)獲得的中繼日志）。

確保新主庫(kù)和老主庫(kù)數(shù)據(jù)一致。

在新主庫(kù)上執(zhí)行 STOP SLAVE。

在新主庫(kù)上執(zhí)行 CHANGE MASTER TO MASTER_HOST=""，然后再執(zhí)行 RESET SLAVE，使其斷開(kāi)與老主庫(kù)的連接，并丟棄 master.info 里記錄的信息（如果連接信息記錄在 my.cnf 里，會(huì)無(wú)法正常工作，因此我們建議不要把復(fù)制連接信息寫(xiě)到配置文件里）。

執(zhí)行 SHOW MASTER STATUS 記錄新主庫(kù)的二進(jìn)制日志坐標(biāo)。

確保其它備庫(kù)已經(jīng)追趕上老主庫(kù)。

關(guān)閉老主庫(kù)。

將客戶(hù)端連接到新主庫(kù)。

在每臺(tái)備庫(kù)上執(zhí)行 CHANGE MASTER TO 語(yǔ)句，使用之前獲得的二進(jìn)制日志坐標(biāo)，指向新的主庫(kù)。

當(dāng)主庫(kù)崩潰時(shí)，需要將一臺(tái)備庫(kù)提升為主庫(kù)。這個(gè)過(guò)程就比較麻煩。如果只有一臺(tái)備庫(kù)，可以直接使用這臺(tái)備庫(kù)。但如果有超過(guò)一臺(tái)的備庫(kù)，就需要做一些額外的工作。

另外，還有潛在的丟失復(fù)制事件的問(wèn)題。可能有主庫(kù)上已發(fā)生的修改還沒(méi)有更新到它任何一臺(tái)備庫(kù)上的情況。甚至可能一條語(yǔ)句在主庫(kù)上執(zhí)行了回滾，但在備庫(kù)上沒(méi)有回滾，這樣備庫(kù)可能就超過(guò)主庫(kù)的邏輯復(fù)制位置。如果能在某一點(diǎn)恢復(fù)主庫(kù)的數(shù)據(jù)，也許就可以取得丟失語(yǔ)句，并手動(dòng)執(zhí)行他們。

在以下描述中，需要確保在服務(wù)器中使用 Master_Log_File 和 Read_Master_Log_Pos 的值。

確定哪臺(tái)備庫(kù)的數(shù)據(jù)最新。檢查每臺(tái)備庫(kù)上 SHOW_SLAVE_STATUS 命令的輸出，選擇其中 Master_Log_File 和 Read_Master_Log_Pos 的值最新的那個(gè)。

讓所有備庫(kù)執(zhí)行完所有從老主庫(kù)崩潰前獲得的中繼日志。

在新主庫(kù)上執(zhí)行 STOP SLAVE。

在新主庫(kù)上執(zhí)行 CHANGE MASTER TO MASTER_HOST=""，然后再執(zhí)行 RESET SLAVE，使其斷開(kāi)與老主庫(kù)的連接，并丟棄 master.info 里記錄的信息。

執(zhí)行 SHOW MASTER STATUS 記錄新主庫(kù)的二進(jìn)制日志坐標(biāo)。

比較每臺(tái)備庫(kù)和新主庫(kù)上的 Master_Log_File 和 Read_Master_Log_Pos 的值。

將客戶(hù)端連接到新主庫(kù)。

在每臺(tái)備庫(kù)上執(zhí)行 CHANGE MASTER TO 語(yǔ)句，使用之前獲得的二進(jìn)制日志坐標(biāo)，指向新的主庫(kù)。

如果已經(jīng)在所有備庫(kù)上開(kāi)啟了 log_bin 和 log_slave_updates，就可以將所有備庫(kù)恢復(fù)到一個(gè)一致的時(shí)間點(diǎn)，如果沒(méi)有開(kāi)啟這兩個(gè)選項(xiàng)，則很難做到這一點(diǎn)。

上面過(guò)程中比較重要的一點(diǎn)是確定日志位置。接下來(lái)，我們就來(lái)看看如何卻。

如果有備庫(kù)和新主庫(kù)的位置不相同，則需要找到該備庫(kù)最后一條執(zhí)行的事件在新主庫(kù)的二進(jìn)制日志中對(duì)應(yīng)的位置，然后再執(zhí)行 CHANGE MASTER TO。可以通過(guò) mysqlbinlog 工具來(lái)找到備庫(kù)執(zhí)行的最后一條查詢(xún)，然后再主庫(kù)上找到同樣的查詢(xún)，進(jìn)行簡(jiǎn)單的計(jì)算即可得到。

為了便于描述，假設(shè)每個(gè)日志事件都有一個(gè)自增數(shù)字 ID。新主庫(kù)在老主庫(kù)崩潰時(shí)獲得了編號(hào)為 100 的事件，另外兩條備庫(kù)：R2 和 R3。R2 已結(jié)獲取了 99 號(hào)事件，R3 獲取了 98 號(hào)事件。

如果把 R2 和 R3 都指向新主庫(kù)的同一個(gè)二進(jìn)制日志位置，它們將從 101 號(hào)事件開(kāi)始復(fù)制，從而導(dǎo)致數(shù)據(jù)不同步。但只要新主庫(kù)的二進(jìn)制日志已結(jié)通過(guò) log_slave_updates 打開(kāi)，就可以在新主庫(kù)的二進(jìn)制日志中找到 99 號(hào) 和 100 號(hào)事件，從而將備庫(kù)恢復(fù)到一致的狀態(tài)。

由于服務(wù)器重啟，不同的配置，日志輪轉(zhuǎn)或者 FLUSH LOGS 命令，同一個(gè)事件在不同的服務(wù)器上可能有不同的偏移量。我們可以通過(guò) mysqlbinlog 從二進(jìn)制日志或中繼日志中解析出每臺(tái)備庫(kù)上執(zhí)行的最后一個(gè)事件，并還有該命令解析新主庫(kù)上的二進(jìn)制文件，找到相同的查詢(xún)，mysqlbinlog 會(huì)打印出該事件的偏移量，在 CHANGE MASTER TO 命令中使用這個(gè)值。

更快的方法是把新主庫(kù)和停止的備庫(kù)上的字節(jié)偏移量相減，它顯示了字節(jié)位置的差異。然后把這個(gè)值和新主庫(kù)當(dāng)前二進(jìn)制日志的位置相減，就可以得到期望的查詢(xún)位置。

一起來(lái)看個(gè)栗子。

假設(shè) s1 是 s2 和 s3 的主庫(kù)。其中 s1 已經(jīng)崩潰。根據(jù) SHOW SLAVE STATUS 獲得 Master_Log_File 和 Read_Master_Log_Pos 的值，s2 已結(jié)執(zhí)行完了 s1 上所有的二進(jìn)制日志，但 s3 還沒(méi)有。如圖 1：

我們可以肯定 s2 已經(jīng)執(zhí)行完了主庫(kù)上的所有二進(jìn)制日志，因?yàn)?Master_log_File 和 Read_Master_Log_Pos 的值和 s1 上最后的日志位置相吻合。因此，我們可以將 s2 提升為新主庫(kù)，并將 s3 設(shè)置為 s2 的備庫(kù)。

應(yīng)該在 s3 上為需要執(zhí)行的 CHANGE MASTER TO 語(yǔ)句賦予什么參數(shù)呢？這里需要做一點(diǎn)計(jì)算。

s3 在偏移量 1493 處停止，比 s2 執(zhí)行的最后一條語(yǔ)句的偏移量 1582 要小 89 字節(jié)。

s2 正在向偏移量為 8167 的二進(jìn)制日志寫(xiě)入，因此，理論上我們應(yīng)該將 s3 指向 s2 日志的偏移量為 8167-89=8078 的位置。

最后在 s2 日志中的 8078 位置，確定該位置上是否是正確的日志事件。

如果驗(yàn)證沒(méi)問(wèn)題，可以通過(guò)下面命令將 s3 切換為 s2 的備庫(kù)：

CHANGE MASTER TO MASTER_HOST="s2 host", MASTER_LOG_FILE="mysql-bin.000009", MASTER_LOG_POS=8078;

如果服務(wù)器在它崩潰時(shí)已經(jīng)執(zhí)行完成并記錄了一個(gè)事件 a。因?yàn)?s2 僅僅讀取并執(zhí)行到了 1582，因此可能會(huì)失去事件 a。但是如果老主庫(kù)的磁盤(pán)沒(méi)有損壞，仍然可以通過(guò) mysqlbinlog 或者從日志服務(wù)器的二進(jìn)制日志中找到丟失的事件。

備庫(kù)提升區(qū)分計(jì)劃內(nèi)和計(jì)劃外場(chǎng)景。

備庫(kù)提升，找到新主庫(kù)準(zhǔn)確的二進(jìn)制日志位置是關(guān)鍵。