2013-07-09 67 views
1

我們有一個「1主站,1從站」MySQL設置。我們突然停電奪走了奴隸。讓本機備份後,我發現,從在外面和主機同步的:崩潰後Mysql從站不同步

mysql> show slave status\G 
*************************** 1. row *************************** 
       Slave_IO_State: Waiting for master to send event 
        Master_Host: 10.0.0.1 
        Master_User: slave 
        Master_Port: 3306 
       Connect_Retry: 60 
       Master_Log_File: mysql-log.001576 
      Read_Master_Log_Pos: 412565824 
       Relay_Log_File: mysqld-relay-bin.002671 
       Relay_Log_Pos: 6930 
     Relay_Master_Log_File: mysql-log.001573 
      Slave_IO_Running: Yes 
      Slave_SQL_Running: No 
       Replicate_Do_DB: 
      Replicate_Ignore_DB: 
      Replicate_Do_Table: 
     Replicate_Ignore_Table: blah.table2 
     Replicate_Wild_Do_Table: 
    Replicate_Wild_Ignore_Table: 
        Last_Errno: 1032 
        Last_Error: Could not execute Update_rows event on table blah.info; Can't find record in 'info', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-log.001573, end_log_pos 689031225 
       Skip_Counter: 0 
      Exec_Master_Log_Pos: 689030864 
       Relay_Log_Space: 2944772417 
       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: NULL 
Master_SSL_Verify_Server_Cert: No 
       Last_IO_Errno: 0 
       Last_IO_Error: 
       Last_SQL_Errno: 1032 
       Last_SQL_Error: Could not execute Update_rows event on table blah.info; Can't find record in 'info', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-log.001573, end_log_pos 689031225 
    Replicate_Ignore_Server_Ids: 
      Master_Server_Id: 1 
1 row in set (0.00 sec) 

我們正在使用的「行」一個二進制日誌格式,所以當我嘗試使用mysqlbinlog可以看違規行,我沒有看到任何使用。我不想簡單地設置跳過計數器,因爲我認爲這會讓我的表進一步不同步。

有什麼我可以做的奴隸基本上「回滾」到一個給定的時間點,然後我可以重置主日誌號碼,位置等?如果沒有,我能做些什麼來恢復同步?

回答

1

通常用戶可以使用pt-table-checksumpt-table-sync小的差異恢復。

它看起來對我來說,你的奴隸的二進制日誌序列失去了它的地方,當它崩潰。從站不斷將其最後一次處理的binlog事件寫入datadir /relay-log.info,但該文件使用了緩衝寫入,因此它很容易在崩潰時丟失數據。

這就是爲什麼Percona Server創建了一個crash-resistant replication功能來在InnoDB表中存儲相同的從屬信息,從這種情況中恢復。

MySQL 5.6已經實現了一個similar feature:您可以設置relay_log_info_repository=TABLE,這樣從站就可以以防碰撞的方式保存其狀態。


回覆您的評論:

是,在理論 PT-表同步可以修復從漂移的任何金額,但它並不一定改正較大差異的最有效方式。在某些情況下,使用來自主服務器的新備份清理過時的從服務器並重新初始化它會更快更高效。

結帳How to setup a slave for replication in 6 simple steps with Percona Xtrabackup

+0

奴隸現在大約比中型/大型,非常快速更新的數據庫晚9個小時。考慮到主數據不斷變化,我認爲在這裏pt-table-sync可能並不理想。 – Phil