今天在公司的工程環境中做了個案例，手動切換關閉主庫的mysql服務，從庫上升為主庫之後，發現主庫處於read_only狀態，通過高可用的元件觀察了剩餘主從庫的alive以及delay的狀態發現均正常。由於處於公司的內網環境中，所以就沒有儲存圖片，就通過文字的方式記錄下今天這個案例。

環境：mysql5.7.18 一主兩從 做了高可用

操作步驟：通過高可用元件發現三臺mysql的主從關係，alive，delay均為正常狀態，登入主庫所在的主機進行關閉資料庫服務，正常情況下，關閉主庫之後，一個從庫上升為新主，另一臺同時為主庫形成一主一從的架構。但是，實際結果為一個從庫上升為主庫，但是處於read_only狀態；另一臺從庫還是和舊主同步，因為舊主已經關閉，所以存在主從同步異常。

處理過程：通過分析，新主置於read_only狀態的原因為：主從切換之後，從庫上升為新主，但是存在主從同步異常，此時只有一個主庫的架構，所以新主為read_only狀。此時的處理方法為將舊主服務啟動，這樣就能形成主從關係，新主就不會為read_only狀態。啟動完舊主之後(它與新主之後有個gtid比對的過程，多與新主則flashback閃回)，與新主形成主庫關係，發現另一個從庫與新主沒有形成主從關係，通過檢視從庫show slave status記下gtid和檢視主庫show master status的gtid，發現兩個資料庫之間的gtid的不一致。所以就通過reset slave all從庫然後再將set_purge置於主庫的gtid，然後start slave。發現主從關係正常。最後通過自己手動切換主從關係，檢視是否還存在主從關係異常的狀況，發現無異常。

總結：以後在做手動切換主從之類的操作，應該謹慎比對主從之間的gtid的值，發現不一致時應該不操作，需等到gtid一致或相差較小的時再做主從切換。

譯者介紹：家華，從事mysqlDBA的工作，記錄自己對mysql的一些總結