START REPLICA

The terms master and slave have historically been used in replication, and MariaDB has begun the process of adding primary and replica synonyms. The old terms will continue to be used to maintain backward compatibility - see MDEV-18777 to follow progress on this effort.

Syntax

START { SLAVE | REPLICA } ["connection_name"] [thread_type [, thread_type] ... ]
START { SLAVE | REPLICA } ["connection_name"] [SQL_THREAD] UNTIL                
    MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos 
START { SLAVE | REPLICA } ["connection_name"] [SQL_THREAD] UNTIL
    RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos 
START { SLAVE | REPLICA } ["connection_name"] [SQL_THREAD] UNTIL
    MASTER_GTID_POS = <GTID position> 
START ALL { SLAVES | REPLICAS } [thread_type [, thread_type]] 

thread_type: IO_THREAD | SQL_THREAD

Description

Current

START REPLICA is a synonym for START SLAVE which is considered deprecated.

< 10.5.1

Only START SLAVE can be used.

START SLAVE or START REPLICA with no thread_type options starts both of the replica threads (see replication) needed to connect with a master setup with CHANGE MASTER TO . The I/O thread reads events from the primary server and stores them in the relay log. The SQL thread reads events from the relay log and executes them.

Current

START REPLICA requires the REPLICATION SLAVE ADMIN privilege.

< 10.5.2

START REPLICA requires the SUPER privilege.

If START REPLICA succeeds in starting the replica threads, it returns without any error. However, even in that case, it might be that the replica threads start and then later stop (for example, because they do not manage to connect to the primary or read its binary log, or some other problem). START REPLICA does not warn you about this. You must check the replica's error log for error messages generated by the replica threads, or check that they are running satisfactorily with SHOW REPLICA STATUS (SHOW REPLICA STATUS).

START REPLICA UNTIL

START REPLICA UNTIL refers to the SQL_THREAD replica position at which the SQL_THREAD replication will halt. If SQL_THREAD isn't specified both threads are started.

START REPLICA UNTIL master_gtid_pos=xxx is also supported. See Global Transaction ID/START REPLICA UNTIL master_gtid_pos=xxx for more details.

MariaDB starting with 11.3.0

Current

SQL_BEFORE_GTIDS|SQL_AFTER_GTIDS

The START REPLICA UNTIL statement contains the options SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS to allow control of whether the replica stops before or after a provided GTID state. Its syntax is:

START REPLICA UNTIL (SQL_BEFORE_GTIDS|SQL_AFTER_GTIDS)="<gtid_list>"

See Global Transaction ID#SQL_BEFORE_GTIDS/SQL_AFTER_GTIDS for details.

< 11.3

SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS are not available.

connection_name

If there is only one nameless primary, or the default primary (as specified by the default_master_connection system variable) is intended, connection_name can be omitted. If provided, the START REPLICA statement will apply to the specified primary. connection_name is case-insensitive.

Current

The FOR CHANNEL keyword is available for MySQL compatibility. This is identical as using the channel_name directly after START REPLICA.

< 10.7.0

The FOR CHANNEL keyword is not available.

START ALL REPLICAS

START ALL REPLICAS starts all configured replicas (replicas with master_host not empty) that were not started before. It will give a note for all started connections. You can check the notes with SHOW WARNINGS.

See Also

• Setting up replication.

• CHANGE MASTER TO is used to create and change connections.

• STOP REPLICA is used to stop a running connection.

• RESET REPLICA is used to reset parameters for a connection and also to permanently delete a primary connection.

_{This page is licensed: GPLv2, originally from fill_help_tables.sql}