關閉複製來源伺服器並稍後重新啟動是安全的。當複本失去與來源的連線時,複本會立即嘗試重新連線,如果失敗,則會定期重試。預設值為每 60 秒重試一次。可以使用 CHANGE REPLICATION SOURCE TO
語句變更此設定。複本也能處理網路連線中斷。不過,複本只有在 replica_net_timeout
秒內沒有收到來自來源的資料後,才會注意到網路中斷。如果您的中斷很短,您可能想要減少 replica_net_timeout
的值。請參閱 第 19.4.2 節,「處理複本的意外停止」。
來源端的非正常關閉(例如,崩潰)可能會導致來源端的二進制日誌的最終位置小於副本讀取的最新位置,因為來源端的二進制日誌檔案沒有被刷新。這可能會導致來源端重新啟動時副本無法進行複製。在來源伺服器的 my.cnf
檔案中設定 sync_binlog=1
有助於最小化這個問題,因為它會導致來源端更頻繁地刷新其二進制日誌。為了在使用 InnoDB
進行事務處理的複製設定中獲得最大的持久性和一致性,您還應該設定 innodb_flush_log_at_trx_commit=1
。使用此設定,InnoDB
重做日誌緩衝區的內容會在每次交易提交時寫入日誌檔案,並且日誌檔案會被刷新到磁碟。請注意,即使使用此設定,事務的持久性仍然無法保證,因為作業系統或磁碟硬體可能會告知 mysqld 刷新到磁碟的操作已完成,即使它實際上沒有完成。
乾淨地關閉副本是安全的,因為它會追蹤它停止的位置。但是,請注意副本沒有開啟臨時表;請參閱第 19.5.1.32 節,「複製和臨時表」。非正常關閉可能會產生問題,尤其是在發生問題之前磁碟快取沒有被刷新到磁碟的情況下。
對於事務,副本會先提交,然後更新
relay-log.info
。如果在這兩個操作之間發生意外退出,relay log 的處理進度會超過資訊檔案所指示的進度,並且副本會在重新啟動後重新執行 relay log 中最後一個交易的事件。如果副本更新了
relay-log.info
,但在寫入刷新到磁碟之前伺服器主機崩潰,則可能會發生類似的問題。為了盡量減少這種情況發生的機率,請在副本的my.cnf
檔案中設定sync_relay_log_info=1
。將sync_relay_log_info
設定為 0 會導致沒有強制寫入磁碟的操作,並且伺服器會依賴作業系統不時地刷新檔案。
如果您擁有良好的不斷電供應系統,則您的系統對於這些類型問題的容錯能力將大大提高。