本文目錄一覽:
MySQL數據庫出錯
如果從庫上表 t 數據與主庫不一致,導致複製錯誤,整個庫的數據量很大,重做從庫很慢,如何單獨恢復這張表的數據?通常認為是不能修復單表數據的,因為涉及到各表狀態不一致的問題。下面就列舉備份單表恢復到從庫會面臨的問題以及解決辦法:
場景 1
如果複製報錯後,沒有使用跳過錯誤、複製過濾等方法修復主從複製。主庫數據一直在更新,從庫數據停滯在報錯狀態(假設 GTID 為 aaaa:1-100)。
修復步驟:
在主庫上備份表 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為什麼有時候備份任務會失敗?
可能是遇到了網絡環境不穩定、實例狀態異常、參數修改異常等情況,都會導致自動備份出現失敗,此時需要進行手動備份,才可以保障數據的安全。如果在備份過程中,執行了DDL操作⌄就會鎖表,也會導致備份失敗。
win10mysql數據庫備份提示拒絕
打開任務欄上的開始菜單,然後點運行。輸入gpedit.msc後回車。,可能權限不夠或被禁止,具體操作是打開開始運行-輸入gpedit.msc打開組策略編輯器。看看組策略的用戶權利指派里,禁止用戶訪問的幾個項目有沒有對應的名字。重啟服務器。
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-hant/n/302754.html