START REPLICA [thread_types] [until_option] [connection_options] [channel_option]
thread_types:
[thread_type [, thread_type] ... ]
thread_type:
IO_THREAD | SQL_THREAD
until_option:
UNTIL { {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
| SOURCE_LOG_FILE = 'log_name', SOURCE_LOG_POS = log_pos
| RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
| SQL_AFTER_MTS_GAPS }
connection_options:
[USER='user_name'] [PASSWORD='user_pass'] [DEFAULT_AUTH='plugin_name'] [PLUGIN_DIR='plugin_dir']
channel_option:
FOR CHANNEL channel
gtid_set:
uuid_set [, uuid_set] ...
| ''
uuid_set:
uuid:interval[:interval]...
uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
h:
[0-9,A-F]
interval:
n[-n]
(n >= 1)
START REPLICA
會啟動複製執行緒,可以一起啟動,也可以個別啟動。
START REPLICA
需要 REPLICATION_SLAVE_ADMIN
權限(或已棄用的 SUPER
權限)。START REPLICA
會導致正在進行的交易隱含提交。請參閱 第 15.3.3 節,「導致隱含提交的陳述式」。
對於執行緒類型選項,您可以指定 IO_THREAD
、SQL_THREAD
、這兩者或兩者皆不指定。只有啟動的執行緒會受到陳述式的影響。
沒有執行緒類型選項的
START REPLICA
會啟動所有複製執行緒,而帶有兩個執行緒類型選項的START REPLICA
也會這樣做。IO_THREAD
啟動複製接收器執行緒,該執行緒會從來源伺服器讀取事件並將其儲存在中繼日誌中。SQL_THREAD
啟動複製套用器執行緒,該執行緒會從中繼日誌讀取事件並執行它們。多執行緒複本(使用replica_parallel_workers
> 0)使用協調器執行緒和多個套用器執行緒套用交易,而SQL_THREAD
會啟動所有這些執行緒。
START REPLICA
在所有複製執行緒啟動後,會向使用者傳送確認。但是,複製接收器執行緒可能尚未成功連線到來源,或者套用器執行緒可能會在啟動後立即套用事件時停止。START REPLICA
在啟動後不會繼續監控執行緒,因此如果執行緒後續停止或無法連線,它不會向您發出警告。您必須檢查複本的錯誤日誌,以查看複製執行緒產生的錯誤訊息,或使用 SHOW REPLICA STATUS
檢查它們是否執行正常。成功的 START REPLICA
陳述式會導致 SHOW REPLICA STATUS
顯示 Replica_SQL_Running=Yes
,但它可能顯示也可能不顯示 Replica_IO_Running=Yes
,因為只有在接收器執行緒正在執行且已連線時,才會顯示 Replica_IO_Running=Yes
。如需詳細資訊,請參閱第 19.1.7.1 節「檢查複製狀態」。
選用的 FOR CHANNEL
子句可讓您命名陳述式所套用的複製通道。提供 channel
FOR CHANNEL
子句會將 channel
START REPLICA
陳述式套用至特定的複製通道。如果沒有命名子句且沒有其他通道存在,則陳述式會套用至預設通道。如果在使用多個通道時,START REPLICA
陳述式未定義通道,則此陳述式會為所有通道啟動指定的執行緒。如需詳細資訊,請參閱第 19.2.2 節「複製通道」。
群組複製的複製通道(group_replication_applier
和 group_replication_recovery
)由伺服器實例自動管理。START REPLICA
完全不能用於 group_replication_recovery
通道,而且只有在群組複製未執行時才應與 group_replication_applier
通道一起使用。group_replication_applier
通道只有一個套用器執行緒,沒有接收器執行緒,因此如果需要,可以使用 SQL_THREAD
選項啟動它,而無需 IO_THREAD
選項。
START REPLICA
支援可插拔的使用者密碼驗證(請參閱第 8.2.17 節「可插拔驗證」),並提供下列清單中描述的 USER
、PASSWORD
、DEFAULT_AUTH
和 PLUGIN_DIR
選項。當您使用這些選項時,您必須啟動接收器執行緒(IO_THREAD
選項)或所有複製執行緒;您不能單獨啟動複製套用器執行緒(SQL_THREAD
選項)。
-
USER
帳戶的使用者名稱。如果使用
PASSWORD
,您必須設定此選項。此選項不能設定為空白或 null 字串。-
PASSWORD
指定使用者帳戶的密碼。
-
DEFAULT_AUTH
驗證外掛程式的名稱。預設值為 MySQL 原生驗證。
-
PLUGIN_DIR
驗證外掛程式的位置。
您使用 START REPLICA
設定的密碼在寫入 MySQL 伺服器的日誌、效能綱要表和 SHOW PROCESSLIST
陳述式時會被遮罩。但是,它會以純文字的形式透過連線傳送到複本伺服器實例。為了保護傳輸中的密碼,請使用 SSL/TLS 加密、SSH 通道或其他方法來保護複本伺服器實例與您用來發出 START REPLICA
的用戶端之間的連線,使其免受未經授權的檢視。
UNTIL
子句使複本開始複製,然後處理交易,直到您在 UNTIL
子句中指定的位置,然後再次停止。UNTIL
子句可用於使複本進行到剛好在您想要略過不想要的交易的位置之前,然後如第 19.1.7.3 節「略過交易」所述略過交易。若要識別交易,您可以使用 mysqlbinlog 與來源的二進位日誌或複本的中繼日誌,或使用 SHOW BINLOG EVENTS
陳述式。
您也可以使用 UNTIL
子句來偵錯複製,方法是一次或分段處理交易。如果您使用 UNTIL
子句來執行此操作,請使用 --skip-replica-start
啟動複本,以防止複本伺服器啟動時 SQL 執行緒執行。在程序完成後移除選項或系統變數設定,以免在伺服器意外重新啟動時忘記。
SHOW REPLICA STATUS
陳述式包含顯示 UNTIL
條件目前值的輸出欄位。UNTIL
條件會持續到受影響的執行緒仍在執行,並在它們停止時移除。
UNTIL
子句會在複製套用器執行緒(SQL_THREAD
選項)上運作。您可以使用 SQL_THREAD
選項,或讓複本預設啟動兩個執行緒。如果您單獨使用 IO_THREAD
選項,則會忽略 UNTIL
子句,因為不會啟動套用器執行緒。
您在 UNTIL
子句中指定的位置可以是下列選項中的任何一個(且只有一個)
-
SOURCE_LOG_FILE
和SOURCE_LOG_POS
這些選項使複製套用器處理交易,直到其在中繼日誌中的位置,該位置由來源伺服器上二進位日誌中對應點的檔案名稱和檔案位置識別。套用器執行緒會尋找指定位置或之後最近的交易邊界,完成套用交易,並在此處停止。對於壓縮的交易負載,請指定壓縮的
Transaction_payload_event
的結束位置。當在
CHANGE REPLICATION SOURCE TO
陳述式上設定GTID_ONLY
選項,以防止複製通道在複製中繼資料存放區中保留檔案名稱和檔案位置時,仍然可以使用這些選項。檔案名稱和檔案位置會在記憶體中追蹤。-
RELAY_LOG_FILE
和RELAY_LOG_POS
這些選項使複製套用器處理交易,直到複本中繼日誌中的位置,該位置由中繼日誌檔案名稱和該檔案中的位置識別。套用器執行緒會尋找指定位置或之後最近的交易邊界,完成套用交易,並在此處停止。對於壓縮的交易負載,請指定壓縮的
Transaction_payload_event
的結束位置。當在
CHANGE REPLICATION SOURCE TO
陳述式上設定GTID_ONLY
選項,以防止複製通道在複製中繼資料存放區中保留檔案名稱和檔案位置時,仍然可以使用這些選項。檔案名稱和檔案位置會在記憶體中追蹤。-
SQL_BEFORE_GTIDS
此選項使複製套用器開始處理交易,並在遇到指定 GTID 集合中的任何交易時停止。不會套用從 GTID 集合中遇到的交易,也不會套用 GTID 集合中的任何其他交易。此選項採用包含一個或多個全域交易識別碼的 GTID 集合作為引數(請參閱GTID 集合)。GTID 集合中的交易不一定會按照其 GTID 的順序出現在複製串流中,因此套用器停止之前的交易不一定是時間最早的交易。
-
SQL_AFTER_GTIDS
此選項使複製套用器開始處理交易,並在處理完指定 GTID 集合中的所有交易時停止。此選項採用包含一個或多個全域交易識別碼的 GTID 集合作為引數(請參閱GTID 集合)。
使用
SQL_AFTER_GTIDS
時,複製執行緒會在處理完 GTID 集合中的所有交易後停止。交易會按照接收到的順序處理,因此這些交易有可能包含不屬於 GTID 集合的交易,但在集合中的所有交易提交之前接收(並處理)。例如,執行START REPLICA UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56
會導致複本從來源取得(並處理)所有交易,直到處理完序號為 11 到 56 的所有交易,然後停止,而不會在此點到達後處理任何其他交易。在較舊版本的 MySQL 中,此選項不能與
replica_parallel_workers > 1
一起使用。在 MySQL 9.0 中,這不再是問題,而且可以使用SQL_AFTER_GTIDS
而不會導致複本回退到單執行緒模式。-
SQL_AFTER_MTS_GAPS
僅適用於多執行緒複本(使用
replica_parallel_workers
> 0),此選項使複本處理交易,直到中繼日誌中執行的交易序列中沒有更多間隙。使用多執行緒複本時,在下列情況下可能會發生間隙協調器執行緒已停止。
套用器執行緒中發生錯誤。
mysqld 意外關閉。
當複製通道出現間隙時,複本的資料庫會處於來源端可能從未存在過的狀態。複本會在內部追蹤這些間隙,並且不允許執行會移除間隙資訊的
CHANGE REPLICATION SOURCE TO
陳述式。所有複本預設都是多執行緒的。當複本上的
replica_preserve_commit_order=ON
(預設值)時,除了此變數描述中列出的特定情況外,不應該發生間隙。如果replica_preserve_commit_order
為OFF
,則不會保留交易的提交順序,因此發生間隙的機會會大得多。如果未使用 GTID,且您需要將失敗的多執行緒複本變更為單執行緒模式,您可以依顯示的順序發出以下一系列陳述式:
START REPLICA UNTIL SQL_AFTER_MTS_GAPS; SET @@GLOBAL.replica_parallel_workers = 0; START REPLICA SQL_THREAD;