在主庫上備份表 t (假設備份快照 GTID 為 aaaa:1-10000)；

恢復到從庫；

啟動復制。

這里的問題是復制起始位點是 aaaa:101，從庫上表 t 的數據狀態是領先其他表的。aaaa:101-10000 這些事務中只要有修改表 t 數據的事務，就會導致復制報錯 ，比如主鍵沖突、記錄不存在(而 aaaa:101 這個之前復制報錯的事務必定是修改表 t 的事務)

解決辦法：啟動復制時跳過 aaaa:101-10000 這些事務中修改表 t 的事務。

正確的修復步驟：

1. 在主庫上備份表 t (假設備份快照 GTID 為 aaaa:1-10000)，恢復到從庫；

2. 設置復制過濾，過濾表 t：

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t');

3. 啟動復制，回放到 aaaa:10000 時停止復制(此時從庫上所有表的數據都在同一狀態，是一致的);

START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000';

4. 刪除復制過濾，正常啟動復制。

注意事項：這里要用 mysqldump --single-transaction --master-data=2，記錄備份快照對應的 GTID

場景 2

如果復制報錯后，使用跳過錯誤、復制過濾等辦法修復了主從復制。主、從庫數據一直在更新。

修復步驟：

在主庫上備份表 t (假設備份快照 GTID為 aaaa:1-10000)；

停止從庫復制，GTID為 aaaa:1-20000；

恢復表 t 到從庫；

啟動復制。

這里的問題是復制起始位點是 aaaa:20001，aaaa:10000-20000 這些事務將不會在從庫上回放，如果這里面有修改表 t 數據的事務，從庫上將丟失這部分數據。

解決辦法：從備份開始到啟動復制，鎖定表 t，保證 aaaa:10000-20000 中沒有修改表 t 的事務。

正確修復步驟：

對表 t 加讀鎖；

在主庫上備份表 t；

停止從庫復制，恢復表 t；

啟動復制；

解鎖表 t。

如果是大表，這里可以用可傳輸表空間方式備份、恢復表，減少鎖表時間。

總結

以上是生活随笔為你收集整理的mysql录数据总是错误_MySQL数据库出错的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。