不，它不是必須的。複本可以關閉或斷線數小時甚至數天，然後重新連線並趕上更新。例如，您可以透過撥號連線設定來源/複本關聯，其中連線僅零星且短暫地啟動。這表示，除非您採取一些特殊措施，否則無法保證複本在任何給定時間都與來源同步。

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

是的，必須在來源和複本上啟用網路。如果未啟用網路，複本將無法連線到來源並傳輸二進位記錄。確認 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 時，它會產生與共同來源 1 上的表格不同的表格，即使來自共同來源 2 的所有更新也已傳播。這表示您不應將兩個伺服器以雙向複製關係鏈接在一起，除非您確定您的更新可以安全地以任何順序進行，或者除非您在用戶端程式碼中以某種方式處理排序錯誤的更新。

您也應該了解，就更新而言，雙向複製實際上並不會大幅提升效能（如果有的話）。每個伺服器都必須執行相同數量的更新，就像您讓單一伺服器執行一樣。唯一的差異是鎖定爭用稍微減少，因為來自另一個伺服器的更新會序列化在一個複製執行緒中。即使這種好處也可能會被網路延遲抵銷。

設定一台伺服器作為來源，並將所有寫入操作導向該伺服器。然後根據您的預算和機架空間配置盡可能多的副本伺服器，並在來源伺服器和副本伺服器之間分配讀取操作。您也可以使用 --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 資料庫中資料表的複製。

是的。

是的。