最近連續經歷了機架掉電和交換機掛掉，着實切了不少主庫，雖然過程心驚膽跳，但是也算是上過戰場，經過了實戰演習，相信TEAM中的小伙伴們對於切主庫已經可以駕輕就熟了。
MySQL的主庫切換也屬於DBA的一個基本技能，下面我們就來聊聊MySQL主庫切換那些事。
正常切主庫
首先我們說說正常情況下的主庫切換，在這種情況下，我們有時間可以做計划慢慢進行切換，所以這種切換其實時流程化的操作。
我們先說一下技術層面的步驟：
1、挑選一台服務器作為新主庫
可以是現有的slave，也可以是新擴容出來的slave，但是歸根結底它的角色是slave
2、在new master上設置log-slave-update，用來記錄中繼的binlog。
3、交替使用slave start until 和 change master to命令，將現有結構從A-B 切換成A-B-C結構，即級聯結構。
其中A=old master，B=new master，C=slaves
4、設定new master的read_only=OFF，保證新主庫可寫
5、建立old master和new master的雙主結構，保證切換失敗之后可以回退，並且數據一致。
需要注意的時auto_increment，如果有字段有這個屬性，需要在old 和 new master上分別設置如下來規避自增沖突。
set global auto_increment_increment=2;set global auto_increment_offset=2;set session auto_increment_increment=2;set session auto_increment_offset=2; set global auto_increment_increment=2;set global auto_increment_offset=1;set session auto_increment_increment=2;set session auto_increment_offset=1;
6、改變寫入目的到new master
可能是修改DNS，或者飄VIP，或者修改配置等等，這個步驟最好選擇業務低峰期操作，能規避很多隱患
7、斷掉雙主
old master可以變成slave或者干掉whatever
我們在說說流程方面的步驟：
1、通知開發同學們我們做這個事情了。
2、做的過程中每個步驟需要第二名同事進行double check。
3、聯系運維同學對new master進行測試，一定要測的就是路由。
4、檢查授權是否new master和old master一致。
5、檢查參數是否new master和old master一致。
6、修改寫入目的之前通知大家一聲。
尤其是除業務之外的流程團隊，比如NOC，或者故障管理組，或者變更管理組等等組織
7、修改寫入目的之后聯系業務同學check一下業務。
8、發個完成通知告訴大家可以洗洗睡了。
從上面我們可以看出，其實流程方面就2個事情“check”和“通知”，僅此而已。
正常切主庫最常見的場景就是MySQL版本升級，需要對表結構進行大改或者需要修改表引擎等等，但是總體來說，基本都是順順利利搞定的居多。
緊急切主庫
下面我們就來聊聊緊急切主庫，這種情況一般發生在主庫由於各種原因宕機的場景下，比如服務器掛了，機架掉電，路由宕機，硬盤，內存，cpu壞了等等情況。
在這種情況下，我們就要進行緊急切主庫了，而在我們真正切換之前需要考慮清楚，我們要的究竟是服務的可用性，還是數據的一致性，這將決定我們后續操作步驟的不一樣。
首先，對於互聯網行業來說，服務的可用性要更高一些，我們需要更快速的將服務啟動起來對外提供服務，所以在這種情況下，我們可以容忍一部分的數據存在不一致的可能性。
so，步驟如下：
1、找一台slave作為new master。
當然，這個前提是最少是1M1S結構，這樣才有的可切，如果是1M的單點情況，那么除了祈禱服務器趕緊重啟，就只有洗洗睡了
2、在new master上執行reset master。
這只是讓我們后續的change操作更方便而已，注意不需要更改log-slave-updates
3、在new master 設置 read_only=OFF，准許寫入。
4、修改寫入目的到new master，最快速的恢復寫入服務。
5、慢慢操作其他slave
change master to master_host="new master host",master_log_file="mysql-bin.000001",master_log_pos=107;
6、檢查服務是否正常。
對於這話情況，如果一個端口還好辦，如果超過10個端口，那么肯定避免不了手忙腳亂的情況，再有心理素質的人也會被不停的報警和手機搞得心煩意亂。
針對這種情況，我來說說一些有用的經驗。
1、監控覆蓋要快、准、全。
我們必須第一時間知道出了問題，並且知道出了什么問題，涉及哪些業務，只有一個強健的報警系統才能讓DBA在第一時間進行反映
2、盡早升級問題給領導。
領導的能量比我們想象的大的多，也許你在辛苦的切主庫，領導一句話服務就降級了，主庫切換也就不那么緊急了。要記住解決問題並不僅有技術手段
3、需要指揮系統。
小業務可以單兵作戰，大規模后，一定要並發處理，這個時候就需要一個調度人員來統一指揮。並且可以將業務、故障管理等等人員屏蔽在一線操作人員外面，減少風險
下面我們再說說如果是數據一致性比較重要的話應該怎么辦。
1、首先確定一下實例的引擎時myisam還是innodb。
2、如果是innodb，那么在可以重啟主庫實例的情況下最好選擇重啟並等待auto recover，這樣丟數據的風險最低。
3、如果是myisam，那么就只能進行主庫切換了，因為myisam的表損壞之后的修表時間太不可控了，而且修好的幾率也不高。
4、而在主庫切換的時候，挑選new master，除了考慮性能之外，需要找到執行了主庫binlog最多的一個slave作為new master，其他slave需要重發這段binlog。
5、最后，其他步驟和上面的沒有多大區別了。
可以看出，在數據一致性的要求下，不太考慮時間成本。（注明的某銀行有整套的IDC容災就是不切就是這個原因）
自動化切主庫
我們都活在一個自動化的時代中，這年頭能自動化的都自動化了，那么切換主庫可不可以呢？ 自然是可以的了。
1、純軟件的有MMM，MHA。
2、帶上VIP的可以用keepalived或者heartbeat。
3、玩硬件的可以用drbd，甚至上SAN。
4、更高級一點的，結合各種中間件來進行fail over。
其實，只要知道上面的原理，完全可以自己寫一個，但是對於DBA來說，我們不能只知道自動化，而不知道真正的切換原理，這就本末倒置了，這也是為什么我最后才說自動化的原因。
以上就是想隨便聊聊的主庫切換那些事，希望所有的DBA們，都不需要半夜2點爬起來切主庫。