在複製A->B->C中，A可以是binlog_format=STATEMENT，B可以是binlog_format=ROW嗎？
我在本地 MySQL 5.6 伺服器 (A) 和另一個本地 MySQL 5.6 伺服器 (B) 之間進行了複製設置。我正在設置一個我想要遷移然後複製的 AWS DMS 實例 (C)。它告訴我，我必須將 binlog_format 設置為基於 ROW 的複制。
這可行嗎？我可以期望 A 上的更改正確複製到 C 嗎？
STATEMENT→ROW絕對是一個有效的配置。您可能忽略了伺服器 B 需要
log_slave_updates啟用，否則它不會將任何內容從 A 複製到 C。但要解決手頭的問題，請考慮下表，該表描述了配置
@@binlog_format和實際寫入伺服器 binlog 之間的比較。假設A是master，B是A的slave，不直接對B做任何改動，當然log_slave_updates是在B上啟用的：A binlog_format | A actually writes | B binlog_format | B actually writes ------------------------------------------------------------------------- STATEMENT STATEMENT STATEMENT STATEMENT STATEMENT STATEMENT MIXED MIXED STATEMENT STATEMENT ROW ROW MIXED MIXED STATEMENT TOTALLY FAILS EVENTUALLY MIXED MIXED MIXED MIXED MIXED MIXED ROW ROW ROW ROW STATEMENT TOTALLY FAILS VERY QUICKLY ROW ROW MIXED ROW ROW ROW ROW ROW這裡發生了什麼？
當 B 寫入其二進制日誌時，它會寫入一個條目來複製它所做的更改。它以本地優化器確定應使用的格式寫入這些條目。當
STATEMENTorROW模式生效時，這是唯一的選擇，因此根據您的情況，傳入STATEMENT變為傳出。ROW伺服器 B 很容易轉換，因為它執行傳入事件，然後簡單地記錄它在其本地數據中插入/更新/刪除的行，以及這些行中列的值。每個 MySQL 伺服器都可以設置自己的並且只能設置自己的二進制日誌記錄格式（無論
binlog_format設置為全域還是會話範圍都是如此）。這意味著更改複製主伺服器上的日誌格式不會導致從伺服器更改其日誌格式以匹配。$$ … $$ 在複製正在進行時更改主伺服器上的二進制日誌格式，或者在從伺服器上不更改它可能會導致複製失敗，並出現錯誤，例如執行行事件時出錯：
'Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.'http://dev.mysql.com/doc/refman/5.7/en/binary-log-setting.html
這就是我在上面所指的
TOTALLY FAILS。唯一無效的配置是伺服器處於STATEMENT模式，而至少有一個上游主伺服器處於ROW或MIXED。為什麼？每個可以用
STATEMENT格式表示的可能查詢總是可以隨後用ROW格式表示，因為ROW格式是絕對確定的。相反，以ROW格式複制的任何查詢都不能隨後以STATEMENT格式複制。請注意，
MIXED格式只是在逐個查詢的基礎上為本地優化器提供瞭如何複製的選項 -STATEMENT或ROW- 但如果傳入的複制事件是ROW唯一的傳出選擇也是ROW。此外，
STATEMENT模式非常糟糕。盡快遠離它。在此之前，驗證 B 上的數據是否與 A 上的數據在各個方面都相同至關重要，因為 B 上的數據很容易不同步並且在 A 處於STATEMENT模式時未被檢測到。