如何使 MySQL 複製可靠？
- 大師版：5.5.13-1
- 從機版本：5.5.14-1
- 二進制日誌格式：MIXED
我的從屬數據庫（~40GB）與主數據庫不同步。我在錯誤日誌中找不到任何有趣的東西。Google給了我一個非常有用的連結。
我將按照此說明重新同步數據庫，以最大限度地減少 Master 上的停機時間。但在這樣做之前，我只是想確保這種情況在未來受到限制。我將瀏覽上面的部分，向您展示我所做的：
- 從數據庫配置了
read-only選項- 有一些不安全的查詢。基於 MIXED 的複制是否會出現一些問題？
- 我複制了所有數據庫
- 我同時使用了 InnoDB 和 MyISAM 儲存引擎
- 開發人員使用了大量的臨時表
我是不是該：
- 不要使用不安全的查詢
- 要求開發者將所有臨時表放到一個單獨的數據庫中
還有別的事嗎？如果不同步，是否
mk-table-sync足夠可靠以自動重新同步？有人在生產中使用它嗎？更新：2 月 28 日星期二 23:27:13 ICT 2012
我的從屬數據庫（~40GB）與主數據庫不同步。我在錯誤日誌中找不到任何有趣的東西。
要獲取有關正在發生的事情的更多資訊，Slave 應該以
--log-warnings=2.
觀察#1
您提到詢問開發人員將所有臨時表放入一個單獨的數據庫中
如果您的開發人員使用 CREATE TEMPORARY TABLE 命令來創建臨時表，他們需要使用 CREATE TABLE 代替。原因如下：
隨著 MySQL 複製處理臨時表，這就是發生的情況
- 主執行
CREATE TEMPORARY TABLE
- 插入二進制日誌的命令
- 複製通過 I/O 執行緒將其複製到從站的中繼日誌
- 從 SQL 執行緒執行
CREATE TEMPORARY TABLE
- 從站使用該臨時表處理數據
偶爾，有人可能會跑來
STOP SLAVE;執行備份。如果STOP SLAVE;在第 4 步之後發出，則創建的 temp 將消失，其數據也將消失。當您執行START SLAVE;複制中斷時，會立即抱怨該表不存在。這是正常的，因為當數據庫連接有意或意外終止時，CREATE TEMPORARY TABLE在數據庫會話中打開的所有臨時表都將被刪除。執行STOP SLAVE;殺死正在打開臨時表的 SQL 執行緒。唯一的解決方法是使用
CREATE TABLE而不是創建表CREATE TEMPORARY TABLE。執行時STOP SLAVE;，您通常創建的臨時表不會消失。在我的 DBA 職業生涯中，我已經看到這種情況發生了 10 次。使用二進制日誌修復它以找出臨時表的名稱，使用創建這些表
CREATE TABLE，然後啟動複製是唯一可能的維護，而無需暴力複製主伺服器。觀察#2
mk-table-sync僅適用於具有主鍵和/或唯一鍵的表。它可能在 99% 的時間內有效。我見過主從表的校驗和不同的實例。我會跑mk-table-sync，還是有區別的（當然，我是mk-table-sync用 3 個 master 進行循環複製，這可能有點危險。在 Master/Slave 中使用它要穩定得多）觀察#3
你提到有一些不安全的查詢。基於 MIXED 的複制是否會出現一些問題？
這取決於。最流行的不安全查詢是任何使用
ORDER BY ... LIMIT. 使用 SBR，這可能會導致 MySQL 以與 Master 不同的順序從 Slave 上的表中更新或刪除行。使用 RBR，我相信行中的確切更改對於從站上的 UPDATE 或 DELETE 更容易辨識。解決方案：避免使用不安全的查詢。那麼，你就不用擔心了！！！
觀察#4
我剛剛閱讀了您的第二個連結。羅弗爾！！！我熟悉答案的海報。