--master-retry-count=count

此選項已棄用；預計在未來的 MySQL 版本中會移除。請改用 CHANGE REPLICATION SOURCE TO 陳述式的 SOURCE_RETRY_COUNT 選項。

--max-relay-log-size=size

伺服器自動輪換中繼日誌檔案的大小。如果此值為非零值，則當中繼日誌的大小超過此值時，會自動輪換中繼日誌。如果此值為零 (預設值)，則中繼日誌輪換發生的大小由 max_binlog_size 的值決定。如需更多資訊，請參閱第 19.2.4.1 節，"中繼日誌"。

--relay-log-purge={0|1}

停用或啟用在不再需要時自動清除中繼日誌。預設值為 1 (已啟用)。這是一個全域變數，可以使用 SET GLOBAL relay_log_purge = N 動態變更。當啟用 --relay-log-recovery 選項時，停用中繼日誌的清除會使資料一致性面臨風險，因此不具有當機安全性。

--relay-log-space-limit=size

此選項設定副本上所有中繼日誌總大小的上限 (以位元組為單位)。值為 0 表示 「無限制」。這對於磁碟空間有限的副本伺服器主機非常有用。當達到限制時，I/O (接收器) 執行緒會停止從來源伺服器讀取二進位日誌事件，直到 SQL 執行緒趕上並刪除一些未使用的中繼日誌。請注意，此限制並非絕對：在某些情況下，SQL (應用程式) 執行緒需要更多事件才能刪除中繼日誌。在這種情況下，接收器執行緒會超過限制，直到應用程式執行緒能夠刪除一些中繼日誌，因為如果不這樣做會導致死鎖。您不應該將 --relay-log-space-limit 設定為小於 --max-relay-log-size (或如果 --max-relay-log-size 為 0 則為 --max-binlog-size) 的兩倍。在這種情況下，接收器執行緒可能會因為 --relay-log-space-limit 超出而等待可用空間，但應用程式執行緒沒有要清除的中繼日誌，因此無法滿足接收器執行緒。這會強制接收器執行緒暫時忽略 --relay-log-space-limit。

--replicate-do-db=db_name

使用資料庫名稱建立複寫篩選器。此類篩選器也可以使用 CHANGE REPLICATION FILTER REPLICATE_DO_DB 來建立。

此選項支援通道特定的複寫篩選器，使多來源副本能夠針對不同的來源使用特定的篩選器。若要在名為 channel_1 的通道上設定通道特定的複寫篩選器，請使用 --replicate-do-db:channel_1:db_name。在此情況下，第一個冒號會被解釋為分隔符號，而後續的冒號則是文字冒號。如需更多資訊，請參閱第 19.2.5.4 節，"基於複寫通道的篩選器"。

此複寫篩選器的確切效果取決於使用陳述式或以資料列為基礎的複寫。

以陳述式為基礎的複寫。 告訴複寫 SQL 執行緒將複寫限制為預設資料庫 (即由 USE 選取的資料庫) 為 db_name 的陳述式。若要指定多個資料庫，請多次使用此選項，每個資料庫使用一次；但是，這樣做 不會 複寫跨資料庫陳述式，例如 UPDATE some_db.some_table SET foo='bar'，而選取的是不同的資料庫 (或沒有選取資料庫)。

以下是一個範例，說明在使用以陳述式為基礎的複寫時，不符合您預期的行為：如果以 --replicate-do-db=sales 啟動副本，且您在來源上發出以下陳述式，則 UPDATE 陳述式 不會 複寫

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

這種 「僅檢查預設資料庫」行為的主要原因是，僅從陳述式很難知道是否應複寫 (例如，如果您使用的是多表格 DELETE 陳述式或跨越多個資料庫的多表格 UPDATE 陳述式)。如果不需要，也只需檢查預設資料庫，而無需檢查所有資料庫，這樣速度會更快。

以資料列為基礎的複寫。 告訴複寫 SQL 執行緒將複寫限制為資料庫 db_name。只會變更屬於 db_name 的表格；目前的資料庫對此沒有影響。假設以 --replicate-do-db=sales 啟動副本，並且以資料列為基礎的複寫生效，然後在來源上執行以下陳述式

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

副本上 sales 資料庫中的 february 表格會根據 UPDATE 陳述式進行變更；無論是否發出 USE 陳述式，都會發生這種情況。但是，當使用以資料列為基礎的複寫和 --replicate-do-db=sales 時，在來源上發出以下陳述式對副本沒有影響

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

即使將陳述式 USE prices 變更為 USE sales，UPDATE 陳述式的效果仍然不會被複寫。

另一個在以陳述式為基礎的複寫與以資料列為基礎的複寫中，處理 --replicate-do-db 的重要差異發生在參考多個資料庫的陳述式。假設以 --replicate-do-db=db1 啟動副本，並在來源上執行以下陳述式

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

如果您使用以陳述式為基礎的複寫，則副本上的兩個表格都會更新。但是，當使用以資料列為基礎的複寫時，只有 table1 會在副本上受到影響；由於 table2 位於不同的資料庫中，因此副本上的 table2 不會因 UPDATE 而變更。現在假設，與 USE db1 陳述式相反，使用了 USE db4 陳述式

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

在這種情況下，當使用以陳述式為基礎的複寫時，UPDATE 陳述式對副本沒有影響。但是，如果您使用以資料列為基礎的複寫，UPDATE 會變更副本上的 table1，但不會變更 table2，換句話說，只會變更 --replicate-do-db 所命名資料庫中的表格，而預設資料庫的選擇對此行為沒有影響。

如果需要讓跨資料庫更新正常運作，請改用 --replicate-wild-do-table=db_name.%。請參閱第 19.2.5 節，"伺服器如何評估複寫篩選規則"。

--replicate-ignore-db=db_name

使用資料庫名稱建立複寫篩選器。 也可以使用 CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB 來建立此類篩選器。

此選項支援通道特定的複寫篩選器，使多來源複本能夠為不同的來源使用特定的篩選器。若要在名為 channel_1 的通道上設定通道特定的複寫篩選器，請使用 --replicate-ignore-db:channel_1:db_name。在此情況下，第一個冒號會被解讀為分隔符號，後續的冒號則為文字冒號。請參閱 第 19.2.5.4 節「基於複寫通道的篩選器」以取得更多資訊。

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

如同 --replicate-do-db，此篩選的精確效果取決於是否使用基於語句或基於列的複寫，並在接下來的幾個段落中進行說明。

基於語句的複寫。 告知複寫 SQL 執行緒不要複寫預設資料庫（即由 USE 選取的資料庫）為 db_name 的任何語句。

基於列的複寫。 告知複寫 SQL 執行緒不要更新資料庫 db_name 中的任何表格。預設資料庫沒有任何作用。

當使用基於語句的複寫時，以下範例不會如預期般運作。假設複本啟動時使用 --replicate-ignore-db=sales，並且您在來源上發出以下語句：

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

在這種情況下，UPDATE 語句會被複寫，因為 --replicate-ignore-db 僅適用於預設資料庫（由 USE 語句決定）。由於語句中明確指定了 sales 資料庫，因此該語句未被篩選。但是，當使用基於列的複寫時，UPDATE 語句的效果不會傳播到複本，並且複本的 sales.january 表格副本保持不變；在此實例中，--replicate-ignore-db=sales 會導致複本忽略來源 sales 資料庫副本中表格的所有變更。

如果您使用跨資料庫更新，並且不希望複寫這些更新，則不應使用此選項。請參閱 第 19.2.5 節「伺服器如何評估複寫篩選規則」。

如果需要跨資料庫更新才能運作，請改用 --replicate-wild-ignore-table=db_name.%。請參閱 第 19.2.5 節「伺服器如何評估複寫篩選規則」。

--replicate-do-table=db_name.tbl_name

建立複寫篩選器，告知複寫 SQL 執行緒將複寫限制為指定的表格。若要指定多個表格，請多次使用此選項，每個表格使用一次。與 --replicate-do-db 相反，這適用於跨資料庫更新和預設資料庫更新。請參閱 第 19.2.5 節「伺服器如何評估複寫篩選規則」。您也可以透過發出 CHANGE REPLICATION FILTER REPLICATE_DO_TABLE 語句來建立此類篩選器。

此選項支援通道特定的複寫篩選器，使多來源複本能夠為不同的來源使用特定的篩選器。若要在名為 channel_1 的通道上設定通道特定的複寫篩選器，請使用 --replicate-do-table:channel_1:db_name.tbl_name。在此情況下，第一個冒號會被解讀為分隔符號，後續的冒號則為文字冒號。請參閱 第 19.2.5.4 節「基於複寫通道的篩選器」以取得更多資訊。

此選項僅影響適用於表格的語句。它不會影響僅適用於其他資料庫物件（例如預存常式）的語句。若要篩選操作預存常式的語句，請使用一個或多個 --replicate-*-db 選項。

--replicate-ignore-table=db_name.tbl_name

建立複寫篩選器，告知複寫 SQL 執行緒不要複寫更新指定表格的任何語句，即使同一語句可能會更新任何其他表格。若要指定要忽略的多個表格，請多次使用此選項，每個表格使用一次。與 --replicate-ignore-db 相反，這適用於跨資料庫更新。請參閱 第 19.2.5 節「伺服器如何評估複寫篩選規則」。您也可以透過發出 CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE 語句來建立此類篩選器。

此選項支援通道特定的複寫篩選器，使多來源複本能夠為不同的來源使用特定的篩選器。若要在名為 channel_1 的通道上設定通道特定的複寫篩選器，請使用 --replicate-ignore-table:channel_1:db_name.tbl_name。在此情況下，第一個冒號會被解讀為分隔符號，後續的冒號則為文字冒號。請參閱 第 19.2.5.4 節「基於複寫通道的篩選器」以取得更多資訊。

此選項僅影響適用於表格的語句。它不會影響僅適用於其他資料庫物件（例如預存常式）的語句。若要篩選操作預存常式的語句，請使用一個或多個 --replicate-*-db 選項。

--replicate-rewrite-db=from_name->to_name

告知複本建立複寫篩選器，如果來源上是 from_name，則將指定的資料庫轉換為 to_name。僅影響涉及表格的語句，而不影響諸如 CREATE DATABASE、DROP DATABASE 和 ALTER DATABASE 等語句。

若要指定多個重寫，請多次使用此選項。伺服器會使用第一個具有相符 from_name 值的選項。資料庫名稱轉換會在測試 --replicate-* 規則之前完成。您也可以透過發出 CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB 語句來建立此類篩選器。

如果您在命令列上使用 --replicate-rewrite-db 選項，並且 > 字元對您的命令解譯器而言很特殊，請將選項值加上引號。例如：

$> mysqld --replicate-rewrite-db="olddb->newdb"

--replicate-rewrite-db 選項的效果會因查詢使用基於語句還是基於列的二進位日誌記錄格式而異。使用基於語句的格式，DML 語句會根據目前資料庫（由 USE 語句指定）進行轉換。使用基於列的格式，DML 語句會根據修改表格所在的資料庫進行轉換。DDL 語句始終會根據目前資料庫（由 USE 語句指定）進行篩選，無論二進位日誌記錄格式為何。

為了確保重寫產生預期的結果，特別是與其他複寫篩選選項組合使用時，在使用 --replicate-rewrite-db 選項時，請遵循這些建議：

如果遵循這些建議，則可以安全地將 --replicate-rewrite-db 選項與表格層級的複寫篩選選項（例如 --replicate-do-table）結合使用。

此選項支援針對特定管道的複製篩選器，讓多來源複本能夠針對不同的來源使用特定的篩選器。請指定管道名稱，後面加上一個冒號，然後再接篩選器規格。第一個冒號會被視為分隔符號，後續的冒號則會被視為字面上的冒號。例如，要在名為 channel_1 的管道上設定特定管道的複製篩選器，請使用：

$> mysqld --replicate-rewrite-db=channel_1:db_name1->db_name2

如果您使用冒號但未指定管道名稱，則此選項會設定預設複製管道的複製篩選器。請參閱第 19.2.5.4 節「基於複製通道的篩選規則」以取得更多資訊。

--replicate-same-server-id

此選項用於複本上。預設值為 0 (FALSE)。如果將此選項設定為 1 (TRUE)，複本將不會跳過具有自己伺服器 ID 的事件。此設定通常僅在極少數的組態中才有用。

當在複本上啟用二進制記錄時，如果在伺服器是環狀複製拓樸的一部分時，複本上的 --replicate-same-server-id 和 --log-replica-updates 選項的組合可能會導致複製中的無限迴圈。(在 MySQL 9.0 中，二進制記錄預設為啟用，且當二進制記錄啟用時，複本更新記錄為預設值。) 但是，使用全域交易識別碼 (GTID) 可防止這種情況，因為它會跳過執行已套用的交易。如果在複本上設定了 gtid_mode=ON，您可以使用此選項組合啟動伺服器，但在伺服器執行時無法變更為任何其他 GTID 模式。如果設定了任何其他 GTID 模式，伺服器將不會使用此選項組合啟動。

依預設，如果複製 I/O (接收器) 執行緒的事件具有複本的伺服器 ID，則不會將二進制記錄事件寫入中繼記錄 (此最佳化有助於節省磁碟使用量)。如果您想使用 --replicate-same-server-id，請務必先使用此選項啟動複本，然後再讓複本讀取您希望複製 SQL (應用程式) 執行緒執行的自身事件。

--replicate-wild-do-table=db_name.tbl_name

建立複製篩選器，指示複製 SQL (應用程式) 執行緒將複製限制為任何更新表格符合指定資料庫和表格名稱模式的陳述式。模式可以包含 % 和 _ 的萬用字元，其意義與 LIKE 模式比對運算子相同。若要指定多個表格，請多次使用此選項，每個表格使用一次。這適用於跨資料庫更新。請參閱第 19.2.5 節「伺服器如何評估複製篩選規則」。您也可以透過發出 CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE 陳述式來建立這類篩選器。

此選項支援針對特定管道的複製篩選器，讓多來源複本能夠針對不同的來源使用特定的篩選器。若要在名為 channel_1 的管道上設定特定管道的複製篩選器，請使用 --replicate-wild-do-table:channel_1:db_name.tbl_name。在此情況下，第一個冒號會被視為分隔符號，後續的冒號則為字面冒號。請參閱第 19.2.5.4 節「基於複製通道的篩選規則」以取得更多資訊。

--replicate-wild-do-table 選項所指定的複製篩選器適用於表格、檢視表和觸發器。它不適用於預存程序和函數，或事件。若要篩選在後者物件上操作的陳述式，請使用一個或多個 --replicate-*-db 選項。

舉例來說，--replicate-wild-do-table=foo%.bar% 只複製使用資料庫名稱開頭為 foo 且表格名稱開頭為 bar 的表格的更新。

如果表格名稱模式為 %，它會比對任何表格名稱，且該選項也適用於資料庫層級的陳述式 (CREATE DATABASE、DROP DATABASE 和 ALTER DATABASE)。例如，如果您使用 --replicate-wild-do-table=foo%.%，如果資料庫名稱符合模式 foo%，則會複製資料庫層級的陳述式。

若要在資料庫或表格名稱模式中包含字面萬用字元，請使用反斜線來逸出它們。例如，若要複製名為 my_own%db 的資料庫的所有表格，但不複製 my1ownAABCdb 資料庫中的表格，您應該像這樣逸出 _ 和 % 字元：--replicate-wild-do-table=my\_own\%db。如果您在命令列上使用此選項，您可能需要根據您的命令直譯器來加倍反斜線或將選項值加上引號。例如，使用 bash shell，您需要輸入 --replicate-wild-do-table=my\\_own\\%db。

--replicate-wild-ignore-table=db_name.tbl_name

建立複製篩選器，以防止複製 SQL 執行緒複製任何表格符合給定萬用字元模式的陳述式。若要指定多個要忽略的表格，請多次使用此選項，每個表格使用一次。這適用於跨資料庫更新。請參閱第 19.2.5 節「伺服器如何評估複製篩選規則」。您也可以透過發出 CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE 陳述式來建立這類篩選器。

此選項支援針對特定管道的複製篩選器，讓多來源複本能夠針對不同的來源使用特定的篩選器。若要在名為 channel_1 的管道上設定特定管道的複製篩選器，請使用 --replicate-wild-ignore:channel_1:db_name.tbl_name。在此情況下，第一個冒號會被視為分隔符號，後續的冒號則為字面冒號。請參閱第 19.2.5.4 節「基於複製通道的篩選規則」以取得更多資訊。

舉例來說，--replicate-wild-ignore-table=foo%.bar% 不會複製使用資料庫名稱開頭為 foo 且表格名稱開頭為 bar 的表格的更新。如需比對如何運作的資訊，請參閱 --replicate-wild-do-table 選項的描述。在選項值中包含字面萬用字元的規則與 --replicate-wild-ignore-table 的規則相同。

如果您需要篩選掉 GRANT 陳述式或其他管理陳述式，一種可能的解決方法是使用 --replicate-ignore-db 篩選器。此篩選器會根據 USE 陳述式所確定的目前生效的預設資料庫進行操作。因此，您可以建立篩選器來忽略不複製的資料庫的陳述式，然後在發出任何您想要忽略的管理陳述式之前，立即發出 USE 陳述式將預設資料庫切換到該資料庫。在管理陳述式中，請命名應用陳述式的實際資料庫。

例如，如果在複本伺服器上設定了 --replicate-ignore-db=nonreplicated，則下列陳述式順序會導致忽略 GRANT 陳述式，因為預設資料庫 nonreplicated 生效

USE nonreplicated;
GRANT SELECT, INSERT ON replicated.t1 TO 'someuser'@'somehost';

--skip-replica-start

--skip-replica-start 會告知複本伺服器在伺服器啟動時不要啟動複製 I/O (接收器) 和 SQL (應用程式) 執行緒。若要稍後啟動執行緒，請使用 START REPLICA 陳述式。

您可以使用 skip_replica_start 系統變數來取代命令列選項，以允許使用 MySQL 伺服器的權限結構來存取此功能，以便資料庫管理員不需要對作業系統具有任何權限存取權。

--skip-slave-start

已棄用的 --skip-replica-start 別名。

--slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]

已棄用的 --replica-skip-errors 同義詞。

--slave-sql-verify-checksum={0|1}

已棄用的 --replica-sql-verify-checksum 同義詞

init_replica

init_replica 類似於 init_connect，但它是一個字串，在每次啟動複寫 SQL 執行緒時，由副本伺服器執行。字串的格式與 init_connect 變數相同。此變數的設定會對後續的 START REPLICA 陳述式生效。

init_slave

已棄用的 init_replica 別名。

log_slow_replica_statements

當啟用慢查詢日誌時，log_slow_replica_statements 會啟用記錄在副本上執行超過 long_query_time 秒的查詢。請注意，如果使用以列為基礎的複寫 (binlog_format=ROW)，則 log_slow_replica_statements 不起作用。只有當查詢以陳述式格式記錄在二進位日誌中時，才會將查詢新增至副本的慢查詢日誌，也就是當設定 binlog_format=STATEMENT 時，或當設定 binlog_format=MIXED 時，且該陳述式是以陳述式格式記錄時。當設定 binlog_format=MIXED 時，以列格式記錄的慢查詢，或當設定 binlog_format=ROW 時記錄的慢查詢，即使啟用了 log_slow_replica_statements，也不會新增至副本的慢查詢日誌。

設定 log_slow_replica_statements 不會立即生效。變數的狀態適用於所有後續的 START REPLICA 陳述式。另請注意，long_query_time 的全域設定適用於 SQL 執行緒的整個生命週期。如果您變更該設定，您必須停止並重新啟動複寫 SQL 執行緒，才能在該處實作變更 (例如，發出 STOP REPLICA 和具有 SQL_THREAD 選項的 START REPLICA 陳述式)。

log_slow_slave_statements

已棄用的 log_slow_replica_statements 別名。

max_relay_log_size

如果副本寫入其中繼日誌，導致目前的日誌檔案大小超過此變數的值，則副本會輪替中繼日誌 (關閉目前的檔案並開啟下一個檔案)。如果 max_relay_log_size 為 0，則伺服器會對二進位日誌和中繼日誌使用 max_binlog_size。如果 max_relay_log_size 大於 0，則它會限制中繼日誌的大小，這可讓您為兩個日誌設定不同的大小。您必須將 max_relay_log_size 設定為介於 4096 位元組和 1GB (含) 之間，或設定為 0。預設值為 0。請參閱 第 19.2.3 節「複寫執行緒」。

relay_log

中繼日誌檔案的基準名稱。對於預設複寫通道，中繼日誌的預設基準名稱為 host_name-relay-bin。對於非預設複寫通道，中繼日誌的預設基準名稱為 host_name-relay-bin-channel，其中 channel 是記錄在此中繼日誌中的複寫通道名稱。

除非基準名稱是以開頭的絕對路徑名稱指定不同的目錄，否則伺服器會將檔案寫入資料目錄。伺服器會透過在基準名稱中新增數值後綴，依序建立中繼日誌檔案。

複寫伺服器上的中繼日誌和中繼日誌索引，不能與二進位日誌和二進位日誌索引的名稱相同，後者的名稱由 --log-bin 和 --log-bin-index 選項指定。如果二進位日誌和中繼日誌檔案的基準名稱相同，伺服器會發出錯誤訊息，且不會啟動。

由於 MySQL 剖析伺服器選項的方式，如果您在伺服器啟動時指定此變數，您必須提供一個值；只有在實際上未指定選項時，才會使用預設基準名稱。如果您在伺服器啟動時指定 relay_log 系統變數，而未指定值，則可能會導致非預期的行為；此行為取決於使用的其他選項、指定這些選項的順序，以及它們是在命令列中指定還是在選項檔案中指定。如需更多關於 MySQL 如何處理伺服器選項的資訊，請參閱 第 6.2.2 節「指定程式選項」。

如果您指定此變數，指定的值也會作為中繼日誌索引檔案的基準名稱。您可以使用 relay_log_index 系統變數，指定不同的中繼日誌索引檔案基準名稱，以覆寫此行為。

當伺服器從索引檔案讀取項目時，它會檢查該項目是否包含相對路徑。如果包含相對路徑，則路徑的相對部分會以使用 relay_log 系統變數設定的絕對路徑取代。絕對路徑會保持不變；在這種情況下，必須手動編輯索引，才能啟用新的路徑或路徑的使用。

您可能會發現 relay_log 系統變數在執行以下工作時很有用

您可以從 relay_log_basename 系統變數取得中繼日誌檔案名稱 (和路徑)。

relay_log_basename

保留中繼日誌檔案的基準名稱和完整路徑。變數最大長度為 256。此變數由伺服器設定且為唯讀。

relay_log_index

中繼日誌索引檔案的名稱。變數最大長度為 256。如果您未指定此變數，但指定了 relay_log 系統變數，則其值會作為中繼日誌索引檔案的預設基準名稱。如果也未指定 relay_log，則對於預設複寫通道，預設名稱為 host_name-relay-bin.index，使用主機的名稱。對於非預設複寫通道，預設名稱為 host_name-relay-bin-channel.index，其中 channel 是記錄在此中繼日誌索引中的複寫通道名稱。

中繼日誌檔案的預設位置是資料目錄，或使用 relay_log 系統變數指定的任何其他位置。您可以使用 relay_log_index 系統變數，方法是在基準名稱中新增開頭的絕對路徑名稱以指定不同的目錄，進而指定替代位置。

複寫伺服器上的中繼日誌和中繼日誌索引，不能與二進位日誌和二進位日誌索引的名稱相同，後者的名稱由 --log-bin 和 --log-bin-index 選項指定。如果二進位日誌和中繼日誌檔案的基準名稱相同，伺服器會發出錯誤訊息，且不會啟動。

由於 MySQL 剖析伺服器選項的方式，如果您在伺服器啟動時指定此變數，您必須提供一個值；只有在實際上未指定選項時，才會使用預設基準名稱。如果您在伺服器啟動時指定 relay_log_index 系統變數，而未指定值，則可能會導致非預期的行為；此行為取決於使用的其他選項、指定這些選項的順序，以及它們是在命令列中指定還是在選項檔案中指定。如需更多關於 MySQL 如何處理伺服器選項的資訊，請參閱 第 6.2.2 節「指定程式選項」。

relay_log_purge

停用或啟用在中繼日誌檔案不再需要時立即自動清除它們。預設值為 1 (ON)。

relay_log_recovery

若啟用此變數，伺服器啟動後會立即啟用自動中繼日誌復原。復原程序會建立一個新的中繼日誌檔案，將 SQL（應用程式）執行緒的位置初始化為此新的中繼日誌，並將 I/O（接收器）執行緒初始化為應用程式執行緒的位置。然後會繼續從來源讀取中繼日誌。如果使用 CHANGE REPLICATION SOURCE TO 陳述式，為複製通道設定了 SOURCE_AUTO_POSITION=1，則用於啟動複製的來源位置可能是連線中接收到的位置，而不是在此程序中指定的位置。

當 relay_log_recovery 停用時，伺服器會在啟動時清除中繼日誌，方法是執行以下動作：

此全域變數在執行階段為唯讀。其值可以使用副本伺服器啟動時的 --relay-log-recovery 選項設定，此選項應在副本發生意外停止後使用，以確保不會處理任何可能損壞的中繼日誌，並且必須使用此選項才能保證副本的當機安全性。預設值為 0（停用）。如需關於副本上設定組合以使其最能抵抗意外停止的資訊，請參閱第 19.4.2 節，「處理副本的意外停止」。

對於多執行緒副本（其中 replica_parallel_workers 大於 0），在啟動時設定 --relay-log-recovery 會自動處理從中繼日誌執行的交易序列中任何不一致和間隙。當使用基於檔案位置的複製時，可能會發生這些間隙。（如需更多詳細資訊，請參閱第 19.5.1.35 節，「複製和交易不一致」。）中繼日誌復原程序會使用與 START REPLICA UNTIL SQL_AFTER_MTS_GAPS 陳述式相同的方法處理間隙。當副本達到一致的無間隙狀態時，中繼日誌復原程序會繼續從 SQL（應用程式）執行緒位置開始從來源擷取更多交易。當使用基於 GTID 的複製時，多執行緒副本會先檢查 SOURCE_AUTO_POSITION 是否設定為 ON，如果設定為 ON，則會省略計算應該略過或不應該略過的交易的步驟，因此復原程序不需要舊的中繼日誌。

relay_log_space_limit

用於所有中繼日誌的最大空間量。

replica_checkpoint_group

replica_checkpoint_group 設定多執行緒副本在呼叫檢查點作業以更新其狀態（如 SHOW REPLICA STATUS 所示）之前可以處理的最大交易數。設定此變數對未啟用多執行緒的副本沒有影響。設定此變數不會立即生效。此變數的狀態適用於所有後續的 START REPLICA 陳述式。

此變數與 replica_checkpoint_period 系統變數結合使用，當任一限制超出時，就會執行檢查點，並且會重設追蹤交易數和自上次檢查點以來經過的時間的計數器。

此變數允許的最小值為 32，除非伺服器是使用 -DWITH_DEBUG 建置，在這種情況下，最小值為 1。有效值始終是 8 的倍數；您可以將其設定為非此倍數的值，但伺服器會在儲存該值之前將其向下捨入到下一個較低的 8 的倍數。（例外：偵錯伺服器不會執行此類捨入。）無論伺服器如何建置，預設值均為 512，允許的最大值為 524280。

replica_checkpoint_period

replica_checkpoint_period 設定允許經過的最大時間（以毫秒為單位），在此時間過後會呼叫檢查點作業，以更新多執行緒副本的狀態，如 SHOW REPLICA STATUS 所示。設定此變數對未啟用多執行緒的副本沒有影響。設定此變數會立即對所有複製通道生效，包括正在執行的通道。

此變數與 replica_checkpoint_group 系統變數結合使用，當任一限制超出時，就會執行檢查點，並且會重設追蹤交易數和自上次檢查點以來經過的時間的計數器。

此變數允許的最小值為 1，除非伺服器是使用 -DWITH_DEBUG 建置，在這種情況下，最小值為 0。無論伺服器如何建置，預設值均為 300 毫秒，允許的最大值為 4294967295 毫秒（約 49.7 天）。

replica_compressed_protocol

replica_compressed_protocol 指定是否在使用來源/副本連線協定的壓縮，前提是來源和副本都支援它。如果此變數已停用（預設值），則連線不會壓縮。對此變數的變更會在後續的連線嘗試中生效；這包括在發出 START REPLICA 陳述式後，以及由正在執行的複製 I/O（接收器）執行緒進行重新連線時生效。

二進制日誌交易壓縮，由 binlog_transaction_compression 系統變數啟用，也可以用於節省頻寬。如果將二進制日誌交易壓縮與協定壓縮結合使用，協定壓縮對資料的作用機會較少，但仍可以壓縮標頭以及未壓縮的事件和交易酬載。如需有關二進制日誌交易壓縮的更多資訊，請參閱第 7.4.4.5 節，「二進制日誌交易壓縮」。

如果啟用 replica_compressed_protocol，則它會優先於為 CHANGE REPLICATION SOURCE TO 陳述式指定的任何 SOURCE_COMPRESSION_ALGORITHMS 選項。在這種情況下，如果來源和副本都支援該演算法，則與來源的連線會使用 zlib 壓縮。如果停用 replica_compressed_protocol，則會套用 SOURCE_COMPRESSION_ALGORITHMS 的值。如需更多資訊，請參閱第 6.2.8 節，「連線壓縮控制」。

replica_exec_mode

replica_exec_mode 控制複製執行緒如何在複製期間解決衝突和錯誤。IDEMPOTENT 模式會抑制重複鍵和找不到鍵的錯誤；STRICT 表示不會發生此類抑制。

IDEMPOTENT 模式旨在用於多來源複製、循環複製以及 NDB Cluster 複製的一些其他特殊複製場景。（如需更多資訊，請參閱第 25.7.10 節，「NDB Cluster 複製：雙向和循環複製」和第 25.7.12 節，「NDB Cluster 複製衝突解決」。）NDB Cluster 會忽略為 replica_exec_mode 明確設定的任何值，並始終將其視為 IDEMPOTENT。

在 MySQL Server 9.0 中，STRICT 模式是預設值。

設定此變數會立即對所有複製通道生效，包括正在執行的通道。

對於 NDB 以外的儲存引擎，只有在您完全確定可以安全地忽略重複鍵錯誤和找不到鍵的錯誤時，才應使用 IDEMPOTENT 模式。此模式旨在用於 NDB Cluster 的容錯移轉情境，其中採用多來源複製或循環複製，不建議在其他情況下使用。

replica_load_tmpdir

replica_load_tmpdir 指定副本建立暫存檔的目錄名稱。設定此變數會立即對所有複製通道生效，包括正在執行的通道。變數的預設值等於 tmpdir 系統變數的值，或當未指定該系統變數時所套用的預設值。

當複製 SQL 執行緒複製 LOAD DATA 陳述式時，它會從中繼日誌中提取要載入的檔案到暫存檔中，然後將這些檔案載入到資料表中。如果來源上載入的檔案很大，則副本上的暫存檔也會很大。因此，建議使用此選項來告知副本將暫存檔放在具有大量可用空間的檔案系統中的目錄。在這種情況下，中繼日誌也會很大，因此您可能也想設定 relay_log 系統變數，將中繼日誌放在該檔案系統中。

此選項指定的目錄應位於基於磁碟的檔案系統（而不是基於記憶體的檔案系統）中，以便用於複製 LOAD DATA 陳述式的暫存檔可以在機器重新啟動後繼續存在。該目錄也不應是在系統啟動過程中由作業系統清除的目錄。但是，如果暫存檔已移除，則複製現在可以在重新啟動後繼續。

replica_max_allowed_packet

replica_max_allowed_packet 設定複製 SQL（套用程式）和 I/O（接收器）執行緒可以處理的最大封包大小（以位元組為單位）。設定此變數會立即對所有複製通道生效，包括正在執行的通道。來源在加入事件標頭後，可以寫入長度大於其 max_allowed_packet 設定的二進制日誌事件。replica_max_allowed_packet 的設定必須大於來源上的 max_allowed_packet 設定，以便使用基於列的複製的大型更新不會導致複製失敗。

此全域變數的值始終是 1024 的正整數倍數；如果您將其設定為某個不是倍數的值，則該值會四捨五入到下一個最大的 1024 倍數以進行儲存或使用；將 replica_max_allowed_packet 設定為 0 會導致使用 1024。（在所有此類情況下都會發出截斷警告。）預設值和最大值為 1073741824 (1 GB)；最小值為 1024。

replica_net_timeout

replica_net_timeout 指定在副本將連線視為斷開、中止讀取並嘗試重新連線之前，等待來自來源的更多資料或心跳訊號的秒數。設定此變數不會立即生效。此變數的狀態會套用於所有後續的 START REPLICA 命令。

預設值為 60 秒（一分鐘）。第一次重試發生在逾時後立即發生。重試之間的間隔由 CHANGE REPLICATION SOURCE TO 陳述式的 SOURCE_CONNECT_RETRY 選項控制，而重新連線嘗試的次數受 SOURCE_RETRY_COUNT 選項限制。

如果連線仍然良好，心跳間隔會防止在沒有資料的情況下發生連線逾時，心跳間隔由 CHANGE REPLICATION SOURCE TO 陳述式的 SOURCE_HEARTBEAT_PERIOD 選項控制。心跳間隔預設為 replica_net_timeout 值的一半，並記錄在副本的連線中繼資料儲存庫中，並顯示在 replication_connection_configuration Performance Schema 資料表中。請注意，變更 replica_net_timeout 的值或預設設定不會自動變更心跳間隔，無論該間隔是已明確設定還是使用先前計算的預設值。如果連線逾時已變更，您還必須發出 CHANGE REPLICATION SOURCE TO 以將心跳間隔調整為適當的值，以便在連線逾時之前發生。

replica_parallel_type

對於多執行緒副本（replica_parallel_workers 設定為大於 0 的值的副本），replica_parallel_type 指定用於決定允許在副本上平行執行哪些交易的原則。此變數對未啟用多執行緒的副本沒有影響。可能的值為

當啟用 replica_preserve_commit_order 時，您必須使用 LOGICAL_CLOCK。預設為副本伺服器啟用多執行緒（預設為 replica_parallel_workers=4），而預設為 LOGICAL_CLOCK。（預設也會啟用 replica_preserve_commit_order。）

當複製拓撲使用多層副本時，對於副本遠離來源的每一層，LOGICAL_CLOCK 可能會實現較少的平行化。

當使用 binlog_transaction_compression 系統變數啟用二進制日誌交易壓縮時，如果 replica_parallel_type 設定為 DATABASE，則會在排程交易之前對受交易影響的所有資料庫進行對應。與未壓縮的交易相比，將二進制日誌交易壓縮與 DATABASE 原則一起使用可能會降低平行度，未壓縮的交易會針對每個事件進行對應和排程。

replica_parallel_type 已棄用，並已棄用使用資料庫分割來支援交易平行化。預計在未來的版本中將移除對這些的支援，並在此後獨家使用 LOGICAL_CLOCK。

replica_parallel_workers

replica_parallel_workers 在副本上啟用多執行緒，並設定平行執行複製交易的套用程式執行緒數量。當值大於或等於 1 時，副本會使用指定數量的 Worker 執行緒來執行交易，以及從中繼日誌讀取交易並將其排程到 Worker 的協調器執行緒。當值為 0 時，只有一個執行緒按順序讀取和套用交易。如果您使用多個複製通道，則此變數的值會套用於每個通道使用的執行緒。

預設值為 4，這表示預設情況下副本是多執行緒的。

將此變數設定為 0 已棄用，會引發警告，並可能會在未來的 MySQL 版本中移除。對於單個 Worker，請改為將 replica_parallel_workers 設定為 1。

當 replica_preserve_commit_order 設定為 ON (預設值) 時，複本上的交易會依照它們在複本中繼日誌中出現的順序，在複本上外部化。交易在應用程式執行緒之間的分配方式取決於 replica_parallel_type。這些系統變數也具有適用於多執行緒的適當預設值。

若要停用平行執行，請將 replica_parallel_workers 設定為 1。在這種情況下，複本會使用一個讀取交易的協調執行緒和一個應用交易的工作執行緒，這表示交易會依序應用。當 replica_parallel_workers 等於 1 時，replica_parallel_type 和 replica_preserve_commit_order 系統變數將不會生效且會被忽略。如果 replica_parallel_workers 等於 0，而 CHANGE REPLICATION SOURCE TO 選項 GTID_ONLY 已啟用，則複本會具有一個協調執行緒和一個工作執行緒，就像 replica_parallel_workers 設定為 1 時一樣。使用一個平行工作執行緒時，replica_preserve_commit_order 系統變數也不會生效。

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

NDB Cluster 9.0 也支援多執行緒複本。如需更多資訊，請參閱第 25.7.11 節，「使用多執行緒應用程式的 NDB Cluster 複寫」。

增加工作執行緒的數量會提高平行處理的潛力。通常，這會提高效能，直到達到某個點為止，超過該點增加工作執行緒的數量會因為鎖定爭用等並行效應而降低效能。理想的數量取決於硬體和工作負載；這很難預測，通常必須透過測試才能找到。沒有主索引鍵的資料表（總是會損害效能）可能會對 replica_parallel_workers > 1 的複本產生更大的負面效能影響；因此，在啟用此選項之前，請確保所有資料表都有主索引鍵。

replica_pending_jobs_size_max

對於多執行緒複本，此變數會設定應用程式佇列（用於保存尚未應用的事件）可用的最大記憶體量（以位元組為單位）。設定此變數對未啟用多執行緒的複本沒有影響。設定此變數不會立即生效。此變數的狀態會應用於所有後續的 START REPLICA 命令。

此變數的最小可能值為 1024 位元組；預設值為 128MB。最大可能值為 18446744073709551615 (16 exbibytes)。在儲存之前，非 1024 位元組整數倍的值會向下捨入至下一個較小的 1024 位元組整數倍。

此變數的值是軟限制，可以設定為符合正常的工作負載。如果異常大的事件超過此大小，則會保留該交易，直到所有工作執行緒都清空佇列，然後才會處理。所有後續的交易都會被保留，直到大型交易完成為止。

replica_preserve_commit_order

對於多執行緒複本（replica_parallel_workers 設定為大於 0 的值的複本），設定 replica_preserve_commit_order=ON 可確保交易在複本上執行和提交的順序與它們在複本中繼日誌中出現的順序相同。這可以防止已從複本中繼日誌執行的交易序列中出現間隙，並在複本上保留與來源相同的交易歷史記錄（具有以下列出的限制）。此變數對未啟用多執行緒的複本沒有影響。

在 MySQL 9.0 中，預設會為複本伺服器啟用多執行緒 (replica_parallel_workers=4 為預設值)，因此 replica_preserve_commit_order=ON 為預設值，且設定 replica_parallel_type=LOGICAL_CLOCK 也是預設值。此外，如果 replica_parallel_workers 設定為 1，則會忽略 replica_preserve_commit_order 的設定，因為在這種情況下，無論如何都會保留交易的順序。

在複本上不需要二進位記錄和複本更新記錄即可設定 replica_preserve_commit_order=ON，如果需要，可以停用。設定 replica_preserve_commit_order=ON 需要將 replica_parallel_type 設定為 LOGICAL_CLOCK，這是 MySQL 9.0 中的預設值。在變更 replica_preserve_commit_order 和 replica_parallel_type 的值之前，必須停止複寫 SQL 執行緒（如果您使用多個複寫通道，則適用於所有複寫通道）。

當設定 replica_preserve_commit_order=OFF 時，多執行緒複本平行應用的交易可能會以無序的方式提交。因此，檢查最近執行的交易並不能保證來源的所有先前交易都已在複本上執行。已從複本中繼日誌執行的交易序列中有可能出現間隙。這對於使用多執行緒複本時的記錄和復原具有影響。如需更多資訊，請參閱第 19.5.1.35 節，「複寫和交易不一致」。

當設定 replica_preserve_commit_order=ON 時，執行工作執行緒會等待所有先前的交易都提交後再提交。當給定執行緒等待其他工作執行緒提交其交易時，它會將其狀態報告為 Waiting for preceding transaction to commit。在此模式下，多執行緒複本永遠不會進入來源未處於的狀態。這支援使用複寫進行讀取擴充。請參閱第 19.4.5 節，「使用複寫進行擴充」。

replica_sql_verify_checksum

replica_sql_verify_checksum 會導致複寫 SQL（應用程式）執行緒使用從複寫日誌讀取的總和檢查碼來驗證資料。如果發生不符的情況，複本會停止並出現錯誤。設定此變數會立即對所有複寫通道生效，包括正在執行的通道。

replica_transaction_retries

replica_transaction_retries 設定單執行緒或多執行緒複本上的複寫 SQL 執行緒在停止之前自動重試失敗交易的最大次數。設定此變數會立即對所有複寫通道生效，包括正在執行的通道。預設值為 10。將變數設定為 0 會停用自動重試交易。

如果複寫 SQL 執行緒因為 InnoDB 死鎖，或因為交易的執行時間超過 InnoDB 的 innodb_lock_wait_timeout 或 NDB 的 TransactionDeadlockDetectionTimeout 或 TransactionInactiveTimeout 而無法執行交易，則它會在停止並出現錯誤之前自動重試 replica_transaction_retries 次。具有非暫時錯誤的交易不會重試。

效能綱要表 replication_applier_status 在 COUNT_TRANSACTIONS_RETRIES 欄位中顯示每個複寫通道發生的重試次數。效能綱要表 replication_applier_status_by_worker 顯示關於單執行緒或多執行緒複本上各個套用執行緒的交易重試詳細資訊，並識別導致最後一個交易和目前正在進行的交易重新嘗試的錯誤。

replica_type_conversions

replica_type_conversions 控制在使用基於列的複寫時，複本上生效的類型轉換模式。其值是逗號分隔的零個或多個元素集合，來自以下列表：ALL_LOSSY、ALL_NON_LOSSY、ALL_SIGNED、ALL_UNSIGNED。將此變數設定為空字串，以禁止來源與複本之間的類型轉換。設定此變數會立即對所有複寫通道生效，包括正在執行的通道。

如需關於基於列的複寫中適用於屬性升級和降級的類型轉換模式的其他資訊，請參閱基於列的複寫：屬性升級和降級。

replication_optimize_for_static_plugin_config

使用共享鎖定，並避免不必要的鎖定獲取，以提升半同步複寫的效能。此設定與 replication_sender_observe_commit_only 有助於隨著複本數量增加，因為鎖定爭用可能會減慢效能。當啟用此系統變數時，無法解除安裝半同步複寫外掛程式，因此您必須先停用此系統變數，才能完成解除安裝。

此系統變數可以在安裝半同步複寫外掛程式之前或之後啟用，並且可以在複寫執行時啟用。半同步複寫來源伺服器也可以透過啟用此系統變數來獲得效能提升，因為它們使用與複本相同的鎖定機制。

當伺服器上使用群組複寫時，可以啟用 replication_optimize_for_static_plugin_config。在該情境中，當由於高工作負載導致鎖定爭用時，它可能會提升效能。

replication_sender_observe_commit_only

限制回呼以提升半同步複寫的效能。此設定與 replication_optimize_for_static_plugin_config 有助於隨著複本數量增加，因為鎖定爭用可能會減慢效能。

此系統變數可以在安裝半同步複寫外掛程式之前或之後啟用，並且可以在複寫執行時啟用。半同步複寫來源伺服器也可以透過啟用此系統變數來獲得效能提升，因為它們使用與複本相同的鎖定機制。

report_host

複本的主機名稱或 IP 位址，在複本註冊期間回報給來源。此值會出現在來源伺服器上 SHOW REPLICAS 的輸出中。如果您不希望複本向來源註冊自身，請保持此值未設定。

report_password

複本的帳戶密碼，在複本註冊期間回報給來源。如果來源是以 --show-replica-auth-info 啟動，則此值會出現在來源伺服器上 SHOW REPLICAS 的輸出中。

儘管此變數的名稱可能暗示其他意思，但 report_password 並未連接到 MySQL 使用者權限系統，因此不一定（甚至不太可能）與 MySQL 複寫使用者帳戶的密碼相同。

report_port

連接到複本的 TCP/IP 連接埠號碼，在複本註冊期間回報給來源。僅當複本在非預設連接埠上監聽，或當您從來源或其他用戶端到複本有特殊的通道時，才設定此項。如果您不確定，請勿使用此選項。

此選項的預設值是複本實際使用的連接埠號碼。這也是 SHOW REPLICAS 顯示的預設值。

report_user

複本的帳戶使用者名稱，在複本註冊期間回報給來源。如果來源是以 --show-replica-auth-info 啟動，則此值會出現在來源伺服器上 SHOW REPLICAS 的輸出中。

儘管此變數的名稱可能暗示其他意思，但 report_user 並未連接到 MySQL 使用者權限系統，因此不一定（甚至不太可能）與 MySQL 複寫使用者帳戶的名稱相同。

rpl_read_size

rpl_read_size 系統變數控制從二進位日誌檔案和中繼日誌檔案讀取的最小資料量（以位元組為單位）。如果這些檔案的大量磁碟 I/O 活動阻礙了資料庫的效能，則當作業系統目前未快取檔案資料時，增加讀取大小可能會減少檔案讀取和 I/O 停頓。

rpl_read_size 的最小值和預設值為 8192 位元組。該值必須是 4KB 的倍數。請注意，會為每個從二進位日誌和中繼日誌檔案讀取的執行緒配置此值大小的緩衝區，包括來源上的傾印執行緒和複本上的協調器執行緒。因此，設定較大的值可能會對伺服器的記憶體消耗產生影響。

rpl_semi_sync_replica_enabled

rpl_semi_sync_replica_enabled 控制是否在複本伺服器上啟用半同步複寫。若要啟用或停用外掛程式，請將此變數分別設定為 ON 或 OFF（或 1 或 0）。預設值為 OFF。

只有在安裝複本端半同步複寫外掛程式時，此變數才可用。

rpl_semi_sync_replica_trace_level

rpl_semi_sync_replica_trace_level 控制複本伺服器上的半同步複寫偵錯追蹤層級。請參閱 rpl_semi_sync_master_trace_level，以瞭解允許的值。

只有在安裝複本端半同步複寫外掛程式時，此變數才可用。

rpl_semi_sync_slave_enabled

已棄用的 rpl_semi_sync_replica_enabled 同義詞。

rpl_semi_sync_slave_trace_level

已棄用的 rpl_semi_sync_replica_trace_level 同義詞。

rpl_stop_replica_timeout

您可以透過設定此變數，控制 STOP REPLICA 在逾時之前等待的時間長度（以秒為單位）。這可用於避免 STOP REPLICA 和使用不同用戶端連線到複本的其他 SQL 陳述式之間的死結。

變數 rpl_stop_replica_timeout 的最大值和預設值為 31536000 秒（1 年），最小值為 2 秒。此變數的變更會對後續的 STOP REPLICA 陳述式生效。

此變數僅影響發出 STOP REPLICA 陳述式的用戶端。當達到逾時時間時，發出要求的用戶端會傳回錯誤訊息，指出命令執行不完整。然後，用戶端會停止等待複製 I/O（接收器）和 SQL（套用器）執行緒停止，但複製執行緒會繼續嘗試停止，並且 STOP REPLICA 陳述式仍然有效。一旦複製執行緒不再忙碌，STOP REPLICA 陳述式就會執行，並且副本會停止。

rpl_stop_slave_timeout

已棄用的 rpl_stop_replica_timeout 同義詞。

skip_replica_start

skip_replica_start 會告知副本伺服器在伺服器啟動時不要啟動複製 I/O（接收器）和 SQL（套用器）執行緒。若要稍後啟動執行緒，請使用 START REPLICA 陳述式。

此系統變數為唯讀，可使用 PERSIST_ONLY 關鍵字或 @@persist_only 限定詞搭配 SET 陳述式進行設定。--skip-replica-start 命令列選項也會設定此系統變數。您可以使用系統變數來取代命令列選項，以允許透過 MySQL Server 的權限結構來存取此功能，使資料庫管理員不需要任何對作業系統的特殊存取權限。

skip_slave_start

已棄用的 --skip-replica-start 同義詞。

slave_checkpoint_group

已棄用的 replica_checkpoint_group 同義詞。

slave_checkpoint_period

已棄用的 replica_checkpoint_period 同義詞。

slave_compressed_protocol

已棄用的 replica_compressed_protocol 別名。

slave_exec_mode

已棄用的 replica_exec_mode 別名。

slave_load_tmpdir

已棄用的 replica_load_tmpdir 別名。

slave_max_allowed_packet

已棄用的 replica_max_allowed_packet 別名。

slave_net_timeout

已棄用的 replica_net_timeout 別名。

slave_parallel_type

已棄用的 replica_parallel_type 別名。

slave_parallel_workers

已棄用的 replica_parallel_workers 別名。

slave_pending_jobs_size_max

已棄用的 replica_pending_jobs_size_max 別名。

slave_preserve_commit_order

已棄用的 replica_preserve_commit_order 別名。

slave_skip_errors

已棄用的 replica_skip_errors 別名。

replica_skip_errors

通常，當副本上發生錯誤時，複製會停止，這讓您有機會手動解決資料中的不一致問題。此變數會使複製 SQL 執行緒在陳述式傳回變數值中列出的任何錯誤時繼續複製。

slave_sql_verify_checksum

已棄用的 replica_sql_verify_checksum 別名。

slave_transaction_retries

已棄用的 replica_transaction_retries 別名。

slave_type_conversions

已棄用的 replica_type_conversions 別名。

sql_replica_skip_counter

sql_replica_skip_counter 指定副本應略過來源的事件數量。設定此選項不會立即生效。此變數會套用至下一個 START REPLICA 陳述式；下一個 START REPLICA 陳述式也會將值變回 0。當此變數設定為非零值且設定了多個複製通道時，START REPLICA 陳述式只能搭配 FOR CHANNEL channel 子句使用。

此選項與基於 GTID 的複製不相容，且當設定 gtid_mode=ON 時，不得設定為非零值。如果您在使用 GTID 時需要略過交易，請改為使用來源的 gtid_executed。如果您已使用 CHANGE REPLICATION SOURCE TO 陳述式的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 選項，在複製通道上啟用 GTID 指派，則 sql_replica_skip_counter 可用。請參閱 章節 19.1.7.3，「略過交易」。

sql_slave_skip_counter

已棄用的 sql_replica_skip_counter 別名。

sync_master_info

已棄用的 sync_source_info 別名。

sync_relay_log

如果此變數的值大於 0，MySQL 伺服器會在每次將 sync_relay_log 事件寫入中繼記錄檔後，將其中繼記錄檔同步到磁碟（使用 fdatasync()）。設定此變數會立即對所有複製通道生效，包括正在執行的通道。

將 sync_relay_log 設定為 0 會導致不會對磁碟執行任何同步作業；在這種情況下，伺服器會依賴作業系統不時刷新中繼記錄檔的內容，如同任何其他檔案一樣。

值為 1 是最安全的選擇，因為在發生意外停止時，您最多只會遺失中繼日誌中的一個事件。然而，這也是最慢的選擇（除非磁碟具有電池備援快取，這會使同步變得非常快）。有關複本上最能抵抗意外停止的設定組合資訊，請參閱第 19.4.2 節「處理複本的意外停止」。

sync_relay_log_info

複本更新 applier 中繼資料儲存庫的交易次數。當 applier 中繼資料儲存庫以 InnoDB 資料表儲存時（這是預設值），會在每次交易後更新，並且忽略此系統變數。如果 applier 中繼資料儲存庫以檔案儲存（已棄用），則複本會在執行這麼多次交易後，將其 relay-log.info 檔案同步至磁碟（使用 fdatasync()）。0 (零) 表示僅由作業系統刷新檔案內容。設定此變數會立即對所有複寫通道生效，包括正在執行的通道。

由於以檔案儲存 applier 中繼資料已棄用，此變數也已棄用，並且伺服器會在您設定或讀取其值時發出警告。您應該預期 sync_relay_log_info 會在未來版本的 MySQL 中移除，並立即遷移可能依賴它的應用程式。

sync_source_info

sync_source_info 指定複本更新連線中繼資料儲存庫的事件次數。當連線中繼資料儲存庫以 InnoDB 資料表儲存時（預設值），會在這麼多次事件後更新。如果連線中繼資料儲存庫以檔案儲存（已棄用），則複本會在執行這麼多次事件後，將其 master.info 檔案同步至磁碟（使用 fdatasync()）。預設值為 10000，而值為零表示永遠不會更新儲存庫。設定此變數會立即對所有複寫通道生效，包括正在執行的通道。

terminology_use_previous

MySQL 8.0 中對包含 master、slave 和 mts（表示「多執行緒從屬」）等詞彙的檢測名稱進行了不相容的變更，它們分別變更為 source、replica 和 mta（表示「多執行緒 Applier」）。如果這些不相容的變更影響您的應用程式，請將 terminology_use_previous 設定為 BEFORE_8_0_26，讓 MySQL 伺服器對先前清單中指定的物件使用舊版本的名稱。這可讓依賴舊名稱的監控工具繼續運作，直到它們可以更新為使用新名稱為止。

MySQL 9.0 通常會在 SHOW CREATE EVENT、SHOW EVENTS 的輸出中以及針對 Information Schema EVENTS 資料表的查詢中顯示 REPLICA_SIDE_DISABLED，而不是 SLAVESIDE_DISABLED。您可以藉由將 terminology_use_previous 設定為 BEFORE_8_0_26 或 BEFORE_8_2_0，來使其改為顯示 SLAVESIDE_DISABLED。

請使用工作階段範圍設定 terminology_use_previous 系統變數以支援個別使用者，或使用全域範圍設為所有新工作階段的預設值。當使用全域範圍時，慢速查詢日誌會包含舊版本的名稱。

受影響的檢測名稱在下列清單中提供。terminology_use_previous 系統變數僅影響這些項目。它不會影響 MySQL 8.0 中引入的系統變數、狀態變數和命令列選項的新別名，並且在啟用時仍然可以使用這些別名。