不，並非如此。副本可以關閉或斷線數小時甚至數天，然後重新連接並趕上更新。例如，您可以透過撥接連線設定來源/副本關係，其中連線僅偶爾且短暫地開啟。這意味著，除非您採取一些特殊措施，否則無法保證副本在任何給定時間都與來源同步。

為了確保斷線的副本可以趕上進度，您不得從來源移除包含尚未複製到副本的資訊的二進位記錄檔。非同步複製只有在副本能夠從上次讀取事件的點繼續讀取二進位記錄時才能運作。

是，必須在來源和副本上啟用網路。如果未啟用網路，副本將無法連接到來源並傳輸二進位記錄。請驗證是否在任一伺服器的設定檔中啟用了 skip_networking 系統變數。

請檢查 SHOW REPLICA | SLAVE STATUS 輸出的 Seconds_Behind_Master 欄位。請參閱第 19.1.7.1 節，〈檢查複製狀態〉。

當複製 SQL 執行緒執行從來源讀取的事件時，它會將自己的時間修改為事件時間戳記。（這就是為什麼 TIMESTAMP 能夠很好地複製。）在 SHOW PROCESSLIST 輸出的 Time 欄位中，顯示的複製 SQL 執行緒秒數是最後一個複製事件的時間戳記與副本機器的實際時間之間的秒數。您可以使用此資訊來判斷最後一個複製事件的日期。請注意，如果您的副本與來源斷線一小時，然後重新連線，您可能會立即在 SHOW PROCESSLIST 中看到複製 SQL 執行緒出現較大的 Time 值，例如 3600。這是因為副本正在執行一小時前的陳述句。請參閱第 19.2.3 節，〈複製執行緒〉。

使用下列步驟

MySQL 複製目前不支援來源與副本之間的任何鎖定協定，以保證分散式（跨伺服器）更新的原子性。換句話說，客戶端 A 可能會對共同來源 1 進行更新，同時，在它傳播到共同來源 2 之前，客戶端 B 可能會對共同來源 2 進行更新，導致客戶端 A 的更新與在共同來源 1 上的運作方式不同。因此，當客戶端 A 的更新到達共同來源 2 時，即使來自共同來源 2 的所有更新也都已傳播，也會產生與共同來源 1 不同的資料表。這表示您不應以雙向複製關係將兩個伺服器鏈接在一起，除非您確定您的更新可以安全地以任何順序發生，或者除非您在客戶端程式碼中以某種方式處理順序錯誤的更新。

您還應該意識到，雙向複製實際上並不會大幅提升（如果有的話）更新的效能。每個伺服器都必須執行與單一伺服器相同的更新次數。唯一的區別在於，由於來自其他伺服器的更新會在一個複製執行緒中序列化，因此鎖定競爭會稍微減少。即使此好處也可能被網路延遲抵消。

設定一個伺服器作為來源，並將所有寫入操作導向它。然後，根據您的預算和機架空間，配置盡可能多的複本，並在來源和複本之間分配讀取操作。您也可以使用 --skip-innodb 選項啟動複本，啟用 low_priority_updates 系統變數，並將 delay_key_write 系統變數設定為 ALL，以在複本端獲得速度提升。在這種情況下，複本會使用非交易型的 MyISAM 資料表而不是 InnoDB 資料表，以消除交易開銷來獲得更高的速度。

請參閱關於使用複寫作為擴展解決方案的指南，第 19.4.5 節，「使用複寫進行擴展」。

MySQL 複寫對於處理頻繁讀取和不頻繁寫入的系統最有益。理論上，透過使用單一來源/多個複本的設定，您可以透過新增更多複本來擴展系統，直到網路頻寬耗盡，或者您的更新負載增加到來源無法處理的程度。

要確定您可以使用多少個複本，在增加的好處開始趨於平緩之前，以及您可以將網站的效能提高多少，您必須了解您的查詢模式，並透過基準測試來經驗性地確定典型來源和典型複本上讀取和寫入吞吐量之間的關係。這裡的範例顯示了一個簡化的計算，說明了您可以透過複寫獲得什麼。讓 reads 和 writes 分別表示每秒的讀取和寫入次數。

假設系統負載由 10% 的寫入和 90% 的讀取組成，並且我們透過基準測試確定 reads 為 1200 - 2 * writes。換句話說，系統可以在沒有寫入的情況下每秒執行 1200 次讀取，平均寫入速度是平均讀取速度的兩倍，並且關係是線性的。假設來源和每個複本具有相同的容量，並且我們有一個來源和 N 個複本。那麼對於每個伺服器（來源或複本），我們有

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1)（讀取被分割，但寫入被複寫到所有複本）

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N + 1))

最後一個方程式表示在每秒最大可能讀取速率為 1200 且讀寫比例為 9 比 1 的情況下，N 個複本的最大寫入次數。

此分析得出以下結論

這些計算假設無限的網路頻寬，並忽略了其他幾個可能對您的系統很重要的因素。在許多情況下，如果您新增 N 個複本，您可能無法執行類似於剛才顯示的計算來準確預測系統上會發生什麼。但是，回答以下問題應該有助於您判斷複寫是否以及在多大程度上可以提高您系統的效能

您如何實作冗餘完全取決於您的應用程式和情況。高可用性解決方案（具有自動容錯移轉）需要主動監控以及自訂腳本或第三方工具，以提供從原始 MySQL 伺服器到複本的容錯移轉支援。

若要手動處理該過程，您應該能夠透過變更您的應用程式以與新伺服器交談，或透過將 MySQL 伺服器的 DNS 從失敗的伺服器調整到新伺服器，從失敗的來源切換到預先配置的複本。

如需更多資訊和一些範例解決方案，請參閱 第 19.4.8 節，「容錯移轉期間切換來源」。

檢查 binlog_format 系統變數的值

mysql> SHOW VARIABLES LIKE 'binlog_format';

顯示的值始終是 STATEMENT、ROW 或 MIXED 之一。對於 MIXED 模式，預設使用基於陳述式的記錄，但在某些情況下，例如不安全的陳述式，複寫會自動切換為基於列的記錄。如需了解可能發生這種情況的資訊，請參閱 第 7.4.4.3 節，「混合二進制日誌格式」。

複本會自動知道要使用哪種格式。

使用 --replicate-wild-ignore-table=mysql.% 選項啟動伺服器，以忽略 mysql 資料庫中資料表的複寫。

是。

是。