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
通道只有一個套用程式執行緒,沒有接收器執行緒,因此如果需要,可以使用不含 IO_THREAD
選項的 SQL_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 8.4 中,這不再是問題,並且可以使用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;