一次mysql主從同步解決過程 前天進行表結構的修改，將其中一個表進行欄位結構的擴展，從varchar(30)擴展到varchar(50)，表數據是120萬多條，在主庫執行起來只用了40秒，而從庫同步卻要用4小時。 雖然主庫執行很快，但是影響的行數是120萬行，從庫是同步120萬行的結構變化而去，而 ...
一次mysql主從同步解決過程
前天進行表結構的修改，將其中一個表進行欄位結構的擴展，從varchar(30)擴展到varchar(50)，表數據是120萬多條，在主庫執行起來只用了40秒，而從庫同步卻要用4小時。
雖然主庫執行很快，但是影響的行數是120萬行，從庫是同步120萬行的結構變化而去，而不是簡單的執行sql命令修改從庫。
一開始並沒有發現，後面當業務緩慢的時候，就開始感覺不對勁了，趕緊上了mysql上進行查看當前堵塞的mysql進程：
show proccesslist
這裡的結果不是當時的結果（當時是很多查詢均被堵塞）：
| Id | User | Host | db | Command | Time | State | Info | +--------+-------+-----------------+------+-------------+--------+-----------------------------------------------------------------------+------------------+ | 722874 | bakup | 127.0.0.1:36759 | NULL | Binlog Dump | 281055 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL | | 991867 | root | localhost | NULL | Sleep | 780 | | NULL | | 992585 | root | localhost | NULL | Query | 0 | NULL | show processlist |
1.Id :進程id，你要kill一個語句的時候很有用。
2.User：顯示單前用戶，如果不是root，這個命令就只顯示你許可權範圍內的sql語句。
3.Host：顯示這個語句是從哪個ip的哪個埠上發出的
4.db:顯示這個進程目前連接的是哪個資料庫
5.Command:顯示當前連接的執行的命令，休眠（sleep），查詢（query），連接（connect），binlog（主從）
6.Time:此這個狀態持續的時間，單位是秒。
7.State:顯示使用當前連接的sql語句的狀態，很重要的列，後續會有所有的狀態的描述，請註意，state只是語句執行中的某一個狀態，一個sql語句，已查詢為例，可能需要經過copying to tmp table，Sorting result，Sending data等狀態才可以完成，
8.info:顯示這個sql語句
當下進行了殺掉堵塞進程，即同步修改結構的進程
kill 722874
得以恢復業務正常的查詢，但是新的問題來了，主從被強制暫停，發生了錯誤，主庫無法同步到從庫，業務查詢最新數據無法同步過來了。
上從庫查詢命令（這裡的結果不是當時的結果（當時是提示錯誤的信息））：
(Mon Jun 26 20:49:40 2017) db_2 >>show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 127.0.0.1 Master_User: bakup Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000330 Read_Master_Log_Pos: 445043216 Relay_Log_File: 174-relay-bin.000043 Relay_Log_Pos: 445043362 Relay_Master_Log_File: mysql-bin.000330 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: information_schema,mysql,performance_schema,test,zabbix,information_schema,mysql,performance_schema,test,zabbix Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 445043216 Relay_Log_Space: 445043559 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 1 row in set (0.00 sec)
於是找運維商議，採取瞭如下方法：
1 恢復主庫到改變欄位前的狀態
2 停止主從二進位日誌的寫入，主從同步停止
3 開始改變主庫欄位結構
4 改變從庫欄位結構（註意此時主從同步已經停止）
5 修正此前發生的同步錯誤
6 恢復主從二進位日誌的寫入
7 重新開啟主從同步
問題得以解決，40分鐘左右。
這次操作也是有點急促，本應該在夜晚後臺幾乎不被訪問的時候，進行大數據量的結構改變比較好。當天也進行了評估，是2個小時內既可以成功。
因此如果你不著急，那麼在夜間進行同步修改是可以的。
附，state 列信息：
Checking table 正在檢查數據表（這是自動的）。 Closing tables 正在將表中修改的數據刷新到磁碟中，同時正在關閉已經用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁碟空間是否已經滿了或者磁碟是否正處於重負中。 Connect Out 複製從伺服器正在連接主伺服器。 Copying to tmp table on disk 由於臨時結果集大於tmp_table_size，正在將臨時表從記憶體存儲轉為磁碟存儲以此節省記憶體。 Creating tmp table 正在創建臨時表以存放部分查詢結果。 deleting from main table 伺服器正在執行多表刪除中的第一部分，剛刪除第一個表。 deleting from reference tables 伺服器正在執行多表刪除中的第二部分，正在刪除其他表的記錄。 Flushing tables 正在執行FLUSH TABLES，等待其他線程關閉數據表。 Killed 發送了一個kill請求給某線程，那麼這個線程將會檢查kill標誌位，同時會放棄下一個kill請求。MySQL會在每次的主迴圈中檢查kill標誌位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那麼kill請求會在鎖釋放時馬上生效。 Locked 被其他查詢鎖住了。 Sending data 正在處理SELECT查詢的記錄，同時正在把結果發送給客戶端。 Sorting for group 正在為GROUP BY做排序。 Sorting for order 正在為ORDER BY做排序。 Opening tables 這個過程應該會很快，除非受到其他因素的干擾。例如，在執ALTER TABLE或LOCK TABLE語句行完以前，數據表無法被其他線程打開。正嘗試打開一個表。 Removing duplicates 正在執行一個SELECT DISTINCT方式的查詢，但是MySQL無法在前一個階段優化掉那些重覆的記錄。因此，MySQL需要再次去掉重覆的記錄，然後再把結果發送給客戶端。 Reopen table 獲得了對一個表的鎖，但是必須在表結構修改之後才能獲得這個鎖。已經釋放鎖，關閉數據表，正嘗試重新打開數據表。 Repair by sorting 修複指令正在排序以創建索引。 Repair with keycache 修複指令正在利用索引緩存一個一個地創建新索引。它會比Repair by sorting慢些。 Searching rows for update 正在講符合條件的記錄找出來以備更新。它必須在UPDATE要修改相關的記錄之前就完成了。 Sleeping 正在等待客戶端發送新請求. System lock 正在等待取得一個外部的系統鎖。如果當前沒有運行多個mysqld伺服器同時請求同一個表，那麼可以通過增加--skip-external-locking參數來禁止外部系統鎖。 Upgrading lock INSERT DELAYED正在嘗試取得一個鎖表以插入新記錄。 Updating 正在搜索匹配的記錄，並且修改它們。 User Lock 正在等待GET_LOCK()。 Waiting for tables 該線程得到通知，數據表結構已經被修改了，需要重新打開數據表以取得新的結構。然後，為了能的重新打開數據表，必須等到所有其他線程關閉這個表。以下幾種情況下會產生這個通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。 waiting for handler insert INSERT DELAYED已經處理完了所有待處理的插入操作，正在等待新的請求。
