MySQL主從資料庫的問題：誰觸發了誰？

資料庫中似乎有一種叫做觸發器的東西，似乎還有另一種叫做事務的東西。

由於種種原因，MySQL主從架構中經常會出現資料不一致的情況，大致可以歸納為以下幾類：

1：寫入備用資料庫。

2：執行非確定性查詢

3：回滾摻雜了事務表和非事務表的事務。

4：二進位日誌或中繼日誌中的資料已損壞。

當出現主從資料不一致的情況時，常見的反應是讓從資料庫下線，然後在半夜找時間停止應用，重新執行同步。 本文介紹如何使用percona-toolkit工具檢視並重新同步MySQL主從資料庫的同步狀態。

第 1 部分：安裝 percona-toolkit

2. 將MySQL的binlog格式修改為行格式。

MySQL 二進位日誌日誌有三種格式：語句、混合和行！

1.網路延遲。

由於MySQL主從複製是基於binlog的非同步複製，binlog檔案是通過網路傳輸的，因此網路延遲自然是導致主從不同步的絕大多數原因，尤其是跨機房資料同步的概率非常大。

2.主機和從機的負載不一致。

由於MySQL主從複製在master資料庫上啟動乙個I/O執行緒，乙個SQL執行緒和乙個I/O執行緒從上面啟動，因此任何一台機器上的負載都很高，而且太忙，導致任何執行緒的資源不足，並且會出現主從不一致的情況。

設定不一致。

master資料庫上設定的最大允許報文量大於從資料庫，當master資料庫上可以執行大型SQL語句時，主資料庫上的設定太小而無法執行，導致主從不一致。

自增鍵開頭的鍵值與自增步長設定不一致導致的主從不一致。

如果未設定 sync binlog=1 或 trx commit=1 處的 innodb flush log，則 binlog 或 relaylog 檔案可能已損壞，導致主站和從站不一致。

由於錯誤本身，主從不同步。

7.如果版本不一致，特別是較高版本為主版本，較低版本為從屬資料庫，則 master 資料庫支援的函式不支援從屬資料庫上的函式。

當主庫的 master 關閉時，資料只能讀不寫，而庫的 master 關閉後，資料仍然可以讀寫，這並不容易做到，如果你對 lua 指令碼有所了解，也許可以修改 mysql-proxy 的讀寫拆分指令碼。 但是主庫關閉時無法訪問，從庫仍可讀寫，不需要配備讀寫分離。

mysql的同步不是很穩定，我以前也做過，普通的插入和刪除都沒有問題，但是如果新增蟹毛裝置，就會失敗。 主伺服器啟動後，重啟後會再次同步輔助伺服器，並讀取主日誌bin資訊。