--binlog-row-event-max-size=N

使用基於列的二進位日誌時，此設定是基於列的二進位日誌事件最大大小的軟性限制，以位元組為單位。在可能的情況下，儲存在二進位日誌中的列會分組到大小不超過此設定值的事件中。如果事件無法分割，則可能會超過最大大小。此值必須是 (或四捨五入為) 256 的倍數。預設值為 8192 個位元組。

--log-bin[=base_name]

指定用於二進制日誌檔案的基本名稱。啟用二進制日誌後，伺服器會將所有變更資料的語句記錄到二進制日誌中，用於備份和複製。二進制日誌是一系列具有基本名稱和數字擴展名的檔案。 --log-bin 選項的值是日誌序列的基本名稱。伺服器會透過在基本名稱上新增數字後綴來依序建立二進制日誌檔案。

如果您未提供 --log-bin 選項，MySQL 會使用 binlog 作為二進制日誌檔案的預設基本名稱。為了與早期版本相容，如果您提供的 --log-bin 選項沒有字串或空字串，則基本名稱預設為 host_name-bin，使用主機的名稱。

二進制日誌檔案的預設位置是資料目錄。您可以使用 --log-bin 選項來指定替代位置，方法是在基本名稱中新增前導絕對路徑名稱，以指定不同的目錄。當伺服器從二進制日誌索引檔案讀取條目時，該檔案會追蹤已使用的二進制日誌檔案，它會檢查條目是否包含相對路徑。如果包含，則路徑的相對部分會被使用 --log-bin 選項設定的絕對路徑取代。記錄在二進制日誌索引檔案中的絕對路徑保持不變；在這種情況下，必須手動編輯索引檔案，才能啟用新的路徑或多個路徑。二進制日誌檔案的基本名稱和任何指定的路徑都可用作 log_bin_basename 系統變數。

在 MySQL 9.0 中，無論您是否指定 --log-bin 選項，預設都會啟用二進制日誌。例外情況是，如果您使用 mysqld 透過使用 --initialize 或 --initialize-insecure 選項呼叫它來手動初始化資料目錄，則預設會停用二進制日誌。在這種情況下，可以透過指定 --log-bin 選項來啟用二進制日誌。啟用二進制日誌後，顯示伺服器上二進制日誌狀態的 log_bin 系統變數會設定為 ON。

若要停用二進制日誌，您可以在啟動時指定 --skip-log-bin 或 --disable-log-bin 選項。如果指定了其中一個選項，且也指定了 --log-bin，則稍後指定的選項優先。停用二進制日誌後， log_bin 系統變數會設定為 OFF。

當伺服器上正在使用 GTID 時，如果您在異常關閉後重新啟動伺服器時停用二進制日誌，則可能會遺失某些 GTID，導致複製失敗。在正常關閉時，目前二進制日誌檔案中的 GTID 集會儲存在 mysql.gtid_executed 資料表中。在發生未執行此操作的異常關閉後，在復原期間，GTID 會從二進制日誌檔案新增至資料表，前提是二進制日誌仍處於啟用狀態。如果伺服器重新啟動時停用了二進制日誌，則伺服器無法存取二進制日誌檔案以復原 GTID，因此無法啟動複製。在正常關閉後，可以安全地停用二進制日誌。

--log-replica-updates 和 --replica-preserve-commit-order 選項需要二進制日誌。如果停用二進制日誌，請省略這些選項，或指定 --log-replica-updates=OFF 和 --skip-replica-preserve-commit-order。當指定 --skip-log-bin 或 --disable-log-bin 時，MySQL 預設會停用這些選項。如果您將 --log-replica-updates 或 --replica-preserve-commit-order 與 --skip-log-bin 或 --disable-log-bin 一起指定，則會發出警告或錯誤訊息。

當啟用二進制日誌時，伺服器可以使用預設伺服器 ID 啟動，但如果您沒有透過設定 server_id 系統變數來明確指定伺服器 ID，則會發出資訊訊息。對於在複製拓撲中使用的伺服器，您必須為每個伺服器指定唯一的非零伺服器 ID。

如需二進制日誌的格式和管理資訊，請參閱第 7.4.4 節，「二進制日誌」。

--log-bin-index[=file_name]

二進制日誌索引檔案的名稱，其中包含二進制日誌檔案的名稱。預設情況下，它與使用 --log-bin 選項為二進制日誌檔案指定的值具有相同的位置和基本名稱，再加上擴展名 .index。如果您未指定 --log-bin，則預設二進制日誌索引檔案名稱為 binlog.index。如果您指定了沒有字串或空字串的 --log-bin 選項，則預設的二進制日誌索引檔案名稱為 host_name-bin.index，使用主機的名稱。

如需二進制日誌的格式和管理資訊，請參閱第 7.4.4 節，「二進制日誌」。

--binlog-do-db=db_name

此選項會以類似於 --replicate-do-db 影響複製的方式來影響二進制日誌記錄。

此選項的效果取決於正在使用基於語句或基於列的日誌記錄格式，與 --replicate-do-db 的效果取決於正在使用基於語句或基於列的複製的方式相同。您應該記住，用於記錄給定語句的格式可能不一定與 binlog_format 的值所指示的格式相同。例如，諸如 CREATE TABLE 和 ALTER TABLE 等 DDL 語句始終記錄為語句，而不考慮生效的日誌記錄格式，因此以下基於語句的 --binlog-do-db 規則始終適用於判斷是否記錄語句。

基於語句的日誌記錄。 只有預設資料庫（即 USE 選取的資料庫）為 db_name 的語句才會寫入二進制日誌。若要指定多個資料庫，請多次使用此選項，每個資料庫一次；但是，這樣做 不會 導致記錄跨資料庫語句，例如 UPDATE some_db.some_table SET foo='bar'，同時選取不同的資料庫（或沒有資料庫）。

當使用基於語句的日誌記錄時，以下是不會如您預期般運作的範例：如果伺服器以 --binlog-do-db=sales 啟動，而您發出下列語句，則 UPDATE 語句將不會被記錄

USE prices;
UPDATE sales.january SET amount=amount+1000;

此「僅檢查預設資料庫」行為的主要原因是，僅從語句很難知道是否應該複製該語句（例如，如果您正在使用跨多個資料庫運作的多資料表 DELETE 語句或多資料表 UPDATE 語句）。如果沒有必要，僅檢查預設資料庫而不是所有資料庫也更快。

當複製給定資料庫時，即使在設定選項時未指定該資料庫，也可能會出現另一個不言自明的情況。如果伺服器以 --binlog-do-db=sales 啟動，即使在設定 --binlog-do-db 時未包含 prices，也會記錄下列 UPDATE 語句

USE sales;
UPDATE prices.discounts SET percentage = percentage + 10;

因為當發出 UPDATE 語句時，sales 是預設資料庫，所以會記錄 UPDATE。

基於列的記錄 (Row-based logging)。 記錄僅限於資料庫 db_name。只會記錄屬於 db_name 的表格變更；預設資料庫對此沒有影響。假設伺服器啟動時使用了 --binlog-do-db=sales，並且啟用了基於列的記錄，然後執行以下語句：

USE prices;
UPDATE sales.february SET amount=amount+100;

根據 UPDATE 語句，對 sales 資料庫中 february 表格的變更會被記錄；無論是否發出 USE 語句，都會發生此情況。然而，當使用基於列的記錄格式和 --binlog-do-db=sales 時，以下 UPDATE 所做的變更將不會被記錄：

USE prices;
UPDATE prices.march SET amount=amount-25;

即使將 USE prices 語句更改為 USE sales，UPDATE 語句的效果仍然不會寫入二進制日誌。

對於引用多個資料庫的語句，在基於語句的記錄與基於列的記錄之間，--binlog-do-db 的處理方式存在另一個重要差異。假設伺服器啟動時使用了 --binlog-do-db=db1，並且執行以下語句：

USE db1;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

如果您使用的是基於語句的記錄，則對兩個表格的更新都會寫入二進制日誌。然而，當使用基於列的格式時，只會記錄對 table1 的變更；table2 位於不同的資料庫中，因此不會因 UPDATE 而變更。現在假設，使用的不是 USE db1 語句，而是 USE db4 語句：

USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

在這種情況下，當使用基於語句的記錄時，UPDATE 語句不會寫入二進制日誌。然而，當使用基於列的記錄時，對 table1 的變更會被記錄，但對 table2 的變更則不會記錄—換句話說，只會記錄對 --binlog-do-db 所命名之資料庫中表格的變更，而預設資料庫的選擇對此行為沒有影響。

--binlog-ignore-db=db_name

此選項影響二進制記錄的方式，與 --replicate-ignore-db 影響複寫的方式類似。

此選項的效果取決於正在使用的基於語句或基於列的記錄格式，與 --replicate-ignore-db 的效果取決於正在使用的基於語句或基於列的複寫的方式相同。您應該記住，用於記錄給定語句的格式不一定與 binlog_format 的值所指示的格式相同。例如，CREATE TABLE 和 ALTER TABLE 等 DDL 語句始終會作為語句記錄，而與生效的記錄格式無關，因此以下 --binlog-ignore-db 的基於語句的規則始終適用於確定是否記錄語句。

基於語句的記錄。 告知伺服器不要記錄任何預設資料庫（即由 USE 選取的資料庫）為 db_name 的語句。

當沒有預設資料庫時，不會套用任何 --binlog-ignore-db 選項，並且始終會記錄此類語句。(Bug #11829838, Bug #60188)

基於列的格式。 告知伺服器不要記錄對資料庫 db_name 中任何表格的更新。目前的資料庫沒有影響。

當使用基於語句的記錄時，以下範例的效果可能與您預期的不同。假設伺服器啟動時使用了 --binlog-ignore-db=sales，並且您發出以下語句：

USE prices;
UPDATE sales.january SET amount=amount+1000;

在這種情況下，UPDATE 語句會被記錄，因為 --binlog-ignore-db 僅適用於預設資料庫（由 USE 語句決定）。由於在語句中明確指定了 sales 資料庫，因此該語句未被篩選。然而，當使用基於列的記錄時，UPDATE 語句的效果不會寫入二進制日誌，這表示不會記錄對 sales.january 表格的任何變更；在這種情況下，--binlog-ignore-db=sales 會導致所有對來源 sales 資料庫副本中表格所做的變更，在二進制記錄方面都被忽略。

若要指定多個要忽略的資料庫，請多次使用此選項，每個資料庫使用一次。由於資料庫名稱可以包含逗號，如果您提供逗號分隔的清單，則該清單會被視為單一資料庫的名稱。

如果您使用的是跨資料庫更新，且不希望記錄這些更新，則不應使用此選項。

--binlog-checksum={NONE|CRC32}

啟用此選項會使來源為寫入二進制日誌的事件寫入校驗和。設定為 NONE 以停用，或設定為要用於產生校驗和的演算法名稱；目前僅支援 CRC32 校驗和，而 CRC32 是預設值。您無法在交易中變更此選項的設定。

--max-binlog-dump-events=N

此選項由 MySQL 測試套件內部用於複寫測試和除錯。

--sporadic-binlog-dump-fail

此選項由 MySQL 測試套件內部用於複寫測試和除錯。

binlog_cache_size

用於在交易期間保存二進制日誌變更的記憶體緩衝區大小。

當伺服器上啟用二進制記錄時（log_bin 系統變數設定為 ON），如果伺服器支援任何交易式儲存引擎，則會為每個用戶端配置一個二進制日誌快取。如果交易的資料超出記憶體緩衝區中的空間，則會將多餘的資料儲存在暫存檔中。當伺服器上啟用了二進制日誌加密時，記憶體緩衝區不會加密，但用於保存二進制日誌快取的任何暫存檔都會加密。在每次交易提交後，會透過清除記憶體緩衝區並截斷暫存檔 (如果使用) 來重設二進制日誌快取。

如果您經常使用大型交易，您可以增加此快取大小以獲得更好的效能，方法是減少或消除寫入暫存檔的需求。Binlog_cache_use 和 Binlog_cache_disk_use 狀態變數對於調整此變數的大小可能很有用。請參閱第 7.4.4 節，〈二進制日誌〉。

binlog_cache_size 僅設定交易快取的大小；語句快取的大小由 binlog_stmt_cache_size 系統變數控制。

binlog_checksum

啟用時，此變數會使來源為二進制日誌中的每個事件寫入校驗和。binlog_checksum 支援值 NONE (會停用校驗和) 和 CRC32。預設值為 CRC32。當 binlog_checksum 停用時 (值為 NONE)，伺服器會透過寫入和檢查每個事件的事件長度 (而非校驗和) 來驗證它只將完整的事件寫入二進制日誌。

在來源上將此變數設定為複本無法辨識的值，會導致複本將其自己的 binlog_checksum 值設定為 NONE，並停止複寫且出現錯誤。如果擔心與較舊的複本的回溯相容性，您可能需要將值明確設定為 NONE。

MySQL 9.0 中的群組複寫支援校驗和，因此群組成員可以使用預設設定。

變更 binlog_checksum 的值會導致二進制日誌輪換，因為必須為整個二進制日誌檔案寫入校驗和，而絕不會僅為部分檔案寫入。您無法在交易中變更 binlog_checksum 的值。

當使用 binlog_transaction_compression 系統變數啟用二進制日誌交易壓縮時，不會為壓縮交易負載中的個別事件寫入校驗和。相反地，會為 GTID 事件寫入校驗和，並為壓縮的 Transaction_payload_event 寫入校驗和。

binlog_direct_non_transactional_updates

由於並行問題，當交易包含對交易式和非交易式表格的更新時，複本可能會變得不一致。MySQL 會嘗試透過將非交易式語句寫入交易快取來保留這些語句之間的因果關係，該快取會在提交時清除。然而，當代表交易對非交易式表格所做的修改對其他連線立即可見時，就會出現問題，因為這些變更可能不會立即寫入二進制日誌。

當二進制日誌格式為

binlog_encryption

binlog_error_action

控制當伺服器遇到無法寫入、刷新或同步二進制日誌等錯誤時會發生什麼情況，這可能會導致來源的二進制日誌不一致，並導致副本失去同步。

binlog_expire_logs_seconds

預設二進制日誌到期期間為 2592000 秒，等於 30 天 (30*24*60*60 秒)。

binlog_expire_logs_auto_purge

此變數對

binlog_format

關於在設定每個二進制日誌格式時，如何處理已儲存的程式（預存程序和函式、觸發程序以及事件）的詳細資訊，請參閱第 27.8 節「已儲存程式的二進制日誌記錄」。

在某些情況下，您無法在執行時切換複寫格式。

嘗試在任何這些情況下切換複寫格式（或嘗試設定目前的複寫格式）都會導致錯誤。但是，您可以使用 PERSIST_ONLY (SET @@PERSIST_ONLY.binlog_format) 隨時變更複寫格式，因為此動作不會修改執行時全域系統變數值，並且僅在伺服器重新啟動後才會生效。

當存在任何暫存表格時，不建議在執行時切換複寫格式，因為暫存表格僅在使用陳述式型複寫時才會記錄，而使用資料列型複寫和混合型複寫時則不會記錄。

在複寫來源伺服器上變更記錄格式並不會導致複本將其記錄格式變更為相符。在複寫正在進行時切換複寫格式可能會導致問題，如果複本已啟用二進制日誌記錄，且變更導致複本使用 STATEMENT 格式記錄，而來源正在使用 ROW 或 MIXED 格式記錄。複本無法將以 ROW 記錄格式接收的二進制日誌條目轉換為 STATEMENT 格式以用於其自己的二進制日誌，因此這種情況可能會導致複寫失敗。如需詳細資訊，請參閱第 7.4.4.2 節「設定二進制日誌格式」。

二進制日誌格式會影響以下伺服器選項的行為。

這些影響會在各個選項的描述中詳細討論。

binlog_group_commit_sync_delay

控制二進制日誌提交在將二進制日誌檔案同步到磁碟之前等待的微秒數。預設情況下，binlog_group_commit_sync_delay 設定為 0，表示沒有延遲。將 binlog_group_commit_sync_delay 設定為微秒延遲，可讓更多交易一次同步到磁碟，從而減少提交一組交易的整體時間，因為較大的群組每個群組需要較少的時間單位。

當設定 sync_binlog=0 或 sync_binlog=1 時，在每次二進制日誌提交群組同步之前（或在 sync_binlog=0 的情況下，在繼續之前），都會套用 binlog_group_commit_sync_delay 指定的延遲。當 sync_binlog 設定為大於 1 的值 n 時，延遲會在每 n 個二進制日誌提交群組之後套用。

設定 binlog_group_commit_sync_delay 可以增加任何具有（或在容錯移轉後可能具有）複本的伺服器上平行提交的交易數量，因此可以增加複本上的平行執行。若要從此效果中受益，複本伺服器必須設定 replica_parallel_type=LOGICAL_CLOCK。在設定 binlog_group_commit_sync_delay 時，務必同時考慮來源和複本的輸送量。

設定 binlog_group_commit_sync_delay 也可以減少任何具有二進制日誌的伺服器（來源或複本）上對二進制日誌的 fsync() 呼叫次數。

請注意，設定 binlog_group_commit_sync_delay 會增加伺服器上交易的延遲時間，這可能會影響用戶端應用程式。此外，在高併發工作負載中，延遲可能會增加爭用，因此會降低輸送量。通常，設定延遲的好處大於缺點，但應始終執行微調以確定最佳設定。

binlog_group_commit_sync_no_delay_count

在中止 binlog_group_commit_sync_delay 指定的目前延遲之前，要等待的最大交易次數。如果 binlog_group_commit_sync_delay 設定為 0，則此選項無效。

binlog_max_flush_queue_time

binlog_max_flush_queue_time 已棄用，並標記為在未來 MySQL 版本中最終移除。以前，此系統變數控制從快取佇列讀取交易，然後再進行群組提交的微秒數。它不再有任何作用。

binlog_order_commits

當在複寫來源伺服器上啟用此變數時（預設），發出給儲存引擎的交易提交指令會在單一執行緒上序列化，因此交易始終以與寫入二進制日誌相同的順序提交。停用此變數可允許多個執行緒發出交易提交指令。與二進制日誌群組提交結合使用時，這可防止單一交易的提交速率成為輸送量的瓶頸，因此可能會產生效能提升。

當所有涉及的儲存引擎都確認交易已準備好提交時，交易會寫入二進制日誌。二進制日誌群組提交邏輯會在寫入二進制日誌後提交一組交易。當停用 binlog_order_commits 時，由於此程序會使用多個執行緒，因此提交群組中的交易提交順序可能與其在二進制日誌中的順序不同。（來自單一用戶端的交易始終按時間順序提交。）在許多情況下，這無關緊要，因為在個別交易中執行的操作應產生一致的結果，如果情況並非如此，則應改為使用單一交易。

如果您想要確保來源和多執行緒複本上的交易歷史記錄保持相同，請在複本上設定 replica_preserve_commit_order=1。

binlog_rotate_encryption_master_key_at_startup

指定是否在伺服器啟動時輪換二進制日誌主金鑰。二進制日誌主金鑰是用於加密伺服器上二進制日誌檔案和中繼日誌檔案的檔案密碼的二進制日誌加密金鑰。當首次啟用二進制日誌加密 (binlog_encryption=ON) 啟動伺服器時，會產生一個新的二進制日誌加密金鑰，並用作二進制日誌主金鑰。如果 binlog_rotate_encryption_master_key_at_startup 系統變數也設定為 ON，則每當重新啟動伺服器時，都會產生另一個二進制日誌加密金鑰，並用作所有後續二進制日誌檔案和中繼日誌檔案的二進制日誌主金鑰。如果 binlog_rotate_encryption_master_key_at_startup 系統變數設定為 OFF（預設值），則在重新啟動伺服器後，會再次使用現有的二進制日誌主金鑰。如需有關二進制日誌加密金鑰和二進制日誌主金鑰的詳細資訊，請參閱第 19.3.2 節「加密二進制日誌檔案和中繼日誌檔案」。

binlog_row_event_max_size

使用資料列型二進制日誌記錄時，此設定是資料列型二進制日誌事件的最大大小的軟限制，以位元組為單位。如果可能，儲存在二進制日誌中的資料列會分組到大小不超過此設定值的事件中。如果無法分割事件，則可以超過最大大小。預設值為 8192 位元組。

此全域系統變數是唯讀的，只能在伺服器啟動時設定。因此，只能使用 PERSIST_ONLY 關鍵字或 @@persist_only 限定詞以及 SET 陳述式來修改其值。

binlog_row_image

對於 MySQL 資料列型複寫，此變數決定資料列映像如何寫入二進制日誌。

在 MySQL 基於列的複製中，每個列變更事件包含兩個映像：一個是「之前」的映像，其欄位會用於比對以搜尋要更新的列；另一個是「之後」的映像，其中包含變更。通常，MySQL 會記錄完整列（即所有欄位）作為之前和之後的映像。然而，並非絕對必須在兩個映像中都包含每個欄位，而且通常我們可以只記錄實際需要的欄位，來節省磁碟空間、記憶體和網路使用量。

對於之前的映像，只需要記錄足以唯一識別列的最小欄位集即可。如果包含該列的資料表具有主鍵，則只會將主鍵欄位寫入二進位日誌。否則，如果該資料表具有唯一索引，其所有欄位都為 NOT NULL，則只需要記錄唯一索引中的欄位。（如果該資料表既沒有主鍵也沒有任何沒有 NULL 欄位的唯一索引，則必須在之前的映像中使用並記錄所有欄位。）在之後的映像中，只需要記錄實際已變更的欄位。

您可以使用 binlog_row_image 系統變數，讓伺服器記錄完整或最小的列。這個變數實際上採用三個可能的值之一，如下所示：

預設值為 full。

當使用 minimal 或 noblob 時，如果來源和目標資料表都符合以下條件，則保證刪除和更新可以針對給定資料表正常運作：

（換句話說，資料表必須相同，除了不是資料表主鍵一部分的索引之外）。

如果不符合這些條件，則目標資料表中的主鍵欄位值可能不足以提供刪除或更新的唯一比對。在這種情況下，不會發出警告或錯誤；來源和複本會靜默地分歧，從而破壞一致性。

當二進位日誌格式為 STATEMENT 時，設定此變數沒有影響。當 binlog_format 為 MIXED 時，binlog_row_image 的設定會套用至使用基於列格式記錄的變更，但此設定對記錄為語句的變更沒有影響。

在全域或工作階段層級設定 binlog_row_image 不會導致隱式提交；這表示此變數可以在交易進行中變更，而不會影響交易。

binlog_row_metadata

設定使用基於列的記錄時，新增至二進位日誌的資料表中繼資料量。當設定為 MINIMAL（預設值）時，只會記錄與 SIGNED 旗標、欄位字元集和幾何類型相關的中繼資料。當設定為 FULL 時，會記錄資料表的完整中繼資料，例如欄位名稱、ENUM 或 SET 字串值、PRIMARY KEY 資訊等等。

擴展中繼資料有以下用途：

binlog_row_value_options

當設定為 PARTIAL_JSON 時，這會啟用針對只修改 JSON 文件一小部分的更新使用節省空間的二進位日誌格式，這會導致基於列的複製只將 JSON 文件的修改部分寫入二進位日誌中更新的「之後」映像，而不是寫入完整的文件（請參閱 JSON 值的局部更新）。這適用於使用任何 JSON_SET()、JSON_REPLACE() 和 JSON_REMOVE() 序列修改 JSON 欄位的 UPDATE 語句。如果伺服器無法產生局部更新，則會改用完整的文件。

預設值為空字串，這會停用此格式的使用。若要取消設定 binlog_row_value_options 並還原為寫入完整 JSON 文件，請將其值設定為空字串。

binlog_row_value_options=PARTIAL_JSON 只有在啟用二進位記錄且 binlog_format 設定為 ROW 或 MIXED 時才會生效。基於語句的複製永遠只會記錄 JSON 文件的修改部分，無論為 binlog_row_value_options 設定任何值。為了最大程度地節省空間，請將 binlog_row_image=NOBLOB 或 binlog_row_image=MINIMAL 與此選項搭配使用。binlog_row_image=FULL 節省的空間比這兩個選項都少，因為完整 JSON 文件會儲存在「之前」映像中，而局部更新只會儲存在「之後」映像中。

mysqlbinlog 輸出包含以 base-64 字串編碼的事件形式呈現的局部 JSON 更新，使用 BINLOG 語句。如果指定 --verbose 選項，mysqlbinlog 會使用虛擬 SQL 語句將局部 JSON 更新顯示為可讀的 JSON。

如果無法將修改套用至複本上的 JSON 文件，則 MySQL 複製會產生錯誤。這包括無法找到路徑的情況。請注意，即使有此和其他安全性檢查，如果複本上的 JSON 文件與來源上的 JSON 文件不同，並且套用了局部更新，則理論上仍然有可能在複本上產生有效但意外的 JSON 文件。

binlog_rows_query_log_events

此系統變數只會影響基於列的記錄。啟用時，它會導致伺服器將資訊性日誌事件（例如列查詢日誌事件）寫入其二進位日誌。此資訊可用於偵錯和相關用途，例如在無法從列更新重建來源發出的原始查詢時取得該查詢。

這些資訊性事件通常會被讀取二進位日誌的 MySQL 程式忽略，因此在複製或從備份還原時不會造成任何問題。若要檢視這些事件，請使用 mysqlbinlog 的 --verbose 選項兩次來提高詳細程度，可以使用 -vv 或 --verbose --verbose。

binlog_stmt_cache_size

二進位日誌用於在交易期間保留非交易語句的記憶體緩衝區大小。

如果伺服器上啟用二進位記錄（將 log_bin 系統變數設定為 ON），並且伺服器支援任何交易式儲存引擎，則會為每個用戶端配置單獨的二進位日誌交易和語句快取。如果交易中使用的非交易語句的資料超過記憶體緩衝區中的空間，則多餘的資料會儲存在暫存檔中。當伺服器上啟用二進位日誌加密時，記憶體緩衝區不會加密，但用於保留二進位日誌快取的任何暫存檔都會加密。在每次交易提交後，會清除記憶體緩衝區並截斷使用的暫存檔，來重設二進位日誌語句快取。

如果您在交易期間經常使用大型非交易語句，您可以增加此快取大小以獲得更好的效能，從而減少或消除寫入暫存檔的需求。Binlog_stmt_cache_use 和 Binlog_stmt_cache_disk_use 狀態變數對於調整此變數的大小可能很有用。請參閱 第 7.4.4 節「二進位日誌」。

binlog_cache_size 系統變數會設定交易快取的大小。

binlog_transaction_compression

啟用寫入此伺服器上二進位日誌檔案的交易壓縮。OFF 為預設值。使用 binlog_transaction_compression_level_zstd 系統變數來設定用於壓縮的 zstd 演算法的層級。

設定 binlog_transaction_compression 不會立即生效，而是適用於所有後續的 START REPLICA 陳述式。

啟用二進制日誌交易壓縮時，交易酬載會被壓縮，然後以單一事件 ( Transaction_payload_event) 的形式寫入二進制日誌檔案。壓縮後的交易酬載在複寫串流中傳送到複本、其他群組複寫群組成員或諸如 mysqlbinlog 之類的用戶端時，會保持壓縮狀態，並以壓縮狀態寫入中繼日誌。因此，二進制日誌交易壓縮可節省交易發起者和接收者（及其備份）的儲存空間，並在伺服器實例之間傳送交易時節省網路頻寬。

要使 binlog_transaction_compression=ON 直接生效，必須在伺服器上啟用二進制日誌記錄。當 MySQL 9.0 伺服器實例沒有二進制日誌時，無論其 binlog_transaction_compression 的值為何，它都可以接收、處理和顯示壓縮的交易酬載。此類伺服器實例接收到的壓縮交易酬載會以壓縮狀態寫入中繼日誌，因此它們可以間接受益於複寫拓撲中其他伺服器執行的壓縮。

此系統變數無法在交易的上下文中變更。設定此系統變數的階段作業值是受限制的操作。階段作業使用者必須具有足夠的權限來設定受限制的階段作業變數。請參閱第 7.1.9.1 節「系統變數權限」。

有關二進制日誌交易壓縮的詳細資訊，包括哪些事件會壓縮，哪些不會壓縮，以及使用交易壓縮時行為的變更，請參閱第 7.4.4.5 節「二進制日誌交易壓縮」。

您可以使用 ndb_log_transaction_compression 系統變數來為 NDB 啟用此功能。此外，在命令列或 my.cnf 檔案中設定 --binlog-transaction-compression=ON 會在伺服器啟動時啟用 ndb_log_transaction_compression。請參閱此變數的說明以瞭解更多資訊。

binlog_transaction_compression_level_zstd

設定此伺服器上二進制日誌交易壓縮的壓縮層級，該壓縮由 binlog_transaction_compression 系統變數啟用。該值是一個整數，用於決定壓縮力度，從 1（最低力度）到 22（最高力度）。如果您未指定此系統變數，則壓縮層級設定為 3。

設定 binlog_transaction_compression_level_zstd 不會立即生效，而是適用於所有後續的 START REPLICA 陳述式。

隨著壓縮層級的提高，資料壓縮比也會提高，這會減少交易酬載所需的儲存空間和網路頻寬。但是，資料壓縮所需的工作量也會增加，這會在來源伺服器上花費時間以及 CPU 和記憶體資源。壓縮工作量的增加與資料壓縮比的增加並非線性關係。

此系統變數無法在交易的上下文中變更。設定此系統變數的階段作業值是受限制的操作。階段作業使用者必須具有足夠的權限來設定受限制的階段作業變數。請參閱第 7.1.9.1 節「系統變數權限」。

此變數對 NDB 表格上的交易記錄沒有影響；請改用 ndb_log_transaction_compression_level_zstd。

binlog_transaction_dependency_history_size

設定保留在記憶體中並用於查找上次修改給定列的交易的列雜湊數量的上限。一旦達到此雜湊數量，就會清除歷程記錄。

log_bin

顯示伺服器上二進制日誌記錄的狀態，啟用 ( ON) 或停用 ( OFF)。啟用二進制日誌記錄後，伺服器會將所有變更資料的陳述式記錄到二進制日誌中，該日誌用於備份和複寫。ON 表示二進制日誌可用，OFF 表示它未在使用中。--log-bin 選項可用於指定二進制日誌的基本名稱和位置。

在較早的 MySQL 版本中，預設情況下停用二進制日誌記錄，如果您指定 --log-bin 選項，則會啟用二進制日誌記錄。預設情況下啟用二進制日誌記錄，並且無論您是否指定 --log-bin 選項，log_bin 系統變數都設定為 ON。例外情況是，如果您使用 mysqld 並透過使用 --initialize 或 --initialize-insecure 選項來手動初始化資料目錄，則預設情況下會停用二進制日誌記錄。在這種情況下，可以透過指定 --log-bin 選項來啟用二進制日誌記錄。

如果在啟動時指定 --skip-log-bin 或 --disable-log-bin 選項，則會停用二進制日誌記錄，並且 log_bin 系統變數會設定為 OFF。如果指定了其中一個選項，並且也指定了 --log-bin，則稍後指定的選項優先。

如需二進制日誌的格式和管理資訊，請參閱第 7.4.4 節，「二進制日誌」。

log_bin_basename

保留二進制日誌檔案的基本名稱和路徑，可以使用 --log-bin 伺服器選項進行設定。最大變數長度為 256。在 MySQL 9.0 中，如果未提供 --log-bin 選項，則預設基本名稱為 binlog。為了與 MySQL 5.7 相容，如果提供的 --log-bin 選項沒有字串或空字串，則預設基本名稱為 host_name-bin，使用主機的名稱。預設位置是資料目錄。

log_bin_index

保留二進制日誌索引檔案的基本名稱和路徑，可以使用 --log-bin-index 伺服器選項進行設定。最大變數長度為 256。

log_bin_trust_function_creators

此變數在啟用二進制日誌記錄時適用。它控制是否可以信任儲存函數建立者不會建立可能會導致不安全事件寫入二進制日誌的儲存函數。如果設定為 0（預設值），則不允許使用者建立或變更儲存函數，除非他們除了擁有 CREATE ROUTINE 或 ALTER ROUTINE 權限外，還擁有 SUPER 權限。設定為 0 也會強制執行以下限制：函數必須使用 DETERMINISTIC 特性宣告，或者使用 READS SQL DATA 或 NO SQL 特性宣告。如果變數設定為 1，則 MySQL 不會對儲存函數建立強制執行這些限制。此變數也適用於觸發器建立。請參閱第 27.8 節「儲存程式二進制日誌記錄」。

log_replica_updates

log_replica_updates 指定是否應將複本伺服器從複寫來源伺服器接收的更新記錄到複本自己的二進制日誌中。

啟用此變數會導致複本將從來源接收並由複寫 SQL 線程執行的更新寫入複本自己的二進制日誌中。二進制日誌記錄（由 --log-bin 選項控制，並且預設情況下啟用）也必須在複本上啟用，才能記錄更新。請參閱第 19.1.6 節「複寫和二進制日誌記錄選項和變數」。log_replica_updates 預設為啟用，除非您指定 --skip-log-bin 來停用二進制日誌記錄，在這種情況下，MySQL 也會預設停用複本更新記錄。如果需要在啟用二進制日誌記錄時停用複本更新記錄，請在複本伺服器啟動時指定 --log-replica-updates=OFF。

啟用 log_replica_updates 可啟用複寫伺服器鏈。例如，您可能想要使用此配置設定複寫伺服器

A -> B -> C

在這裡，A 作為複本 B 的來源，而 B 作為複本 C 的來源。為了使此配置有效，B 必須同時是來源和複本。在啟用二進制日誌記錄並啟用 log_replica_updates （這是預設設定）的情況下，從 A 接收的更新將由 B 記錄到其二進制日誌中，因此可以傳遞給 C。

log_slave_updates

已棄用的 log_replica_updates 別名。

log_statements_unsafe_for_binlog

如果遇到錯誤 1592，則控制是否將產生的警告新增至錯誤日誌中。

master_verify_checksum

已棄用的 source_verify_checksum 別名。

max_binlog_cache_size

如果交易需要超過這麼多位元組，伺服器會產生 多語句交易需要超過 'max_binlog_cache_size' 位元組的儲存空間 錯誤。當 gtid_mode 不是 ON 時，建議的最大值為 4GB，因為在這種情況下，MySQL 無法處理大於 4GB 的二進位日誌位置；當 gtid_mode 為 ON 時，此限制不適用，伺服器可以處理任意大小的二進位日誌位置。

如果因為 gtid_mode 不是 ON，或者由於其他原因，您需要保證二進位日誌不超過給定的大小 maxsize，則應根據此處顯示的公式設定此變數。

max_binlog_cache_size < 
  (((maxsize - max_binlog_size) / max_connections) - 1000) / 1.2

此計算會考慮下列條件

max_binlog_cache_size 僅設定交易快取的大小；語句快取的上限由 max_binlog_stmt_cache_size 系統變數控制。

max_binlog_cache_size 對於工作階段的可見性與 binlog_cache_size 系統變數的可見性相符；換句話說，變更其值僅影響變更值後啟動的新工作階段。

max_binlog_size

如果寫入二進位日誌導致目前日誌檔案大小超過此變數的值，則伺服器會旋轉二進位日誌 (關閉目前檔案並開啟下一個檔案)。最小值為 4096 位元組。最大值和預設值為 1GB。加密的二進位日誌檔案具有額外的 512 位元組標頭，該標頭包含在 max_binlog_size 中。

交易會以一個區塊寫入二進位日誌，因此永遠不會在多個二進位日誌之間分割。因此，如果您有大型交易，您可能會看到二進位日誌檔案大於 max_binlog_size。

如果 max_relay_log_size 為 0，則 max_binlog_size 的值也適用於中繼日誌。

當伺服器上使用 GTID 時，如果達到 max_binlog_size，則如果無法存取系統資料表 mysql.gtid_executed 以寫入目前二進位日誌檔案的 GTID，則無法旋轉二進位日誌。在此情況下，伺服器會根據其 binlog_error_action 設定做出回應。如果設定 IGNORE_ERROR，則會在伺服器上記錄錯誤並停止二進位日誌記錄；或者，如果設定 ABORT_SERVER，則伺服器會關閉。

max_binlog_stmt_cache_size

如果交易中的非交易語句需要超過這麼多位元組的記憶體，伺服器會產生錯誤。最小值為 4096。最大值和預設值在 32 位元平台上為 4GB，在 64 位元平台上為 16EB (艾位元組)。

max_binlog_stmt_cache_size 僅設定語句快取的大小；交易快取的上限僅受 max_binlog_cache_size 系統變數控制。

original_commit_timestamp

供複寫內部使用。在複本上重新執行交易時，此值會設定為交易在原始來源上提交的時間，以自 Epoch 以來的微秒為單位測量。這允許原始提交時間戳記在整個複寫拓撲中傳播。

設定此系統變數的工作階段值是受限制的操作。工作階段使用者必須具有 REPLICATION_APPLIER 權限 (請參閱 第 19.3.3 節「複寫權限檢查」) 或足以設定受限工作階段變數的權限 (請參閱 第 7.1.9.1 節「系統變數權限」)。但是，請注意，此變數並非供使用者設定；它由複寫基礎架構自動設定。

source_verify_checksum

啟用 source_verify_checksum 會導致來源透過檢查檢查總和來驗證從二進位日誌讀取的事件，並在發生不符時停止並顯示錯誤。預設會停用 source_verify_checksum；在這種情況下，來源會使用二進位日誌中的事件長度來驗證事件，以便僅從二進位日誌讀取完整事件。

sql_log_bin

此變數控制是否為目前工作階段啟用寫入二進位日誌 (假設已啟用二進位日誌本身)。預設值為 ON。若要停用或啟用目前工作階段的二進位日誌記錄，請將工作階段 sql_log_bin 變數設定為 OFF 或 ON。

將此變數設定為 OFF 以用於工作階段，以便在變更您不希望複寫到複本的來源時暫時停用二進位日誌記錄。

無法在交易或子查詢中設定 sql_log_bin 的工作階段值。

將此變數設定為 OFF 會阻止將 GTID 指派給二進位日誌中的交易。如果您使用 GTID 進行複寫，這表示即使稍後再次啟用二進位日誌記錄，從此點寫入日誌的 GTID 也不會計入這段期間發生的任何交易，因此實際上這些交易會遺失。

sync_binlog

控制 MySQL 伺服器將二進位日誌同步到磁碟的頻率。

為了在使用 InnoDB 和交易的複寫設定中獲得最大的耐用性和一致性，請使用以下設定