MariaDB's replication implementation requires several types of threads.
The master usually only has one type of replication-related thread: the binary log dump thread.
If semisynchronous replication is enabled, then the master also has an ACK receiver thread.
The binary log dump thread runs on the master and dumps the binary log to the slave. This thread can be identified by running the SHOW PROCESSLIST
statement and finding the thread where the thread command is "Binlog Dump"
.
The master creates a separate binary log dump thread for each slave connected to the master. You can identify which slaves are connected to the master by executing the SHOW SLAVE HOSTS
statement.
When a master server is shutdown and it goes through the normal shutdown process, the master kills client threads in random order. By default, the master also considers its binary log dump threads to be regular client threads. As a consequence, the binary log dump threads can be killed while client threads still exist, and this means that data can be written on the master during a normal shutdown that won't be replicated. This is true even if semi-synchronous replication is being used.
In MariaDB 10.4 and later, this problem can be solved by shutting down the server using either the mysqladmin
utility or the SHUTDOWN
command, and providing a special option.
For example, this problem can be solved by shutting down the server with the mysqladmin
utility and by providing the --wait-for-all-slaves
option to the utility and by executing the shutdown
command with the utility:
mysqladmin --wait-for-all-slaves shutdown
Or this problem can be solved by shutting down the server with the SHUTDOWN
command and by providing the WAIT FOR ALL SLAVES
option to the command:
SHUTDOWN WAIT FOR ALL SLAVES;
When one of these special options is provided, the server only kills its binary log dump threads after all client threads have been killed, and it only completes the shutdown after the last binary log has been sent to all connected slaves.
In MariaDB 10.4 and later, it is still not possible to enable this behavior by default. This means that this behavior is currently inaccessible when shutting down the server using tools like systemd
or sysVinit
.
In MariaDB 10.3 and before, it is recommended to manually switchover slaves to a new master before shutting down the old master.
When semisynchronous replication is enabled, semisynchronous slaves send acknowledgements (ACKs) to their master confirm that they have received some transaction. The master creates an ACK receiver thread to receive these ACKs.
The slave has three types of replication-related threads: the slave I/O thread, the slave SQL thread, and worker threads, which are only applicable when parallel replication is in use.
When multi-source replication is in use, each independent replication connection has its own slave threads of each type.
The slave's I/O thread receives the binary log events from the master and writes them to its relay log.
The binary log position of the slave's I/O thread can be checked by executing the SHOW SLAVE STATUS
statement. It will be shown as the Master_Log_File
and Read_Master_Log_Pos
columns.
The binary log position of the slave's I/O thread can be set by setting the MASTER_LOG_FILE
and MASTER_LOG_POS
options with the CHANGE MASTER
statement.
The binary log position of the slave's I/O thread and the values of most other CHANGE MASTER
options are written to either the default master.info
file or the file that is configured by the master_info_file
option. The slave's I/O thread keeps this binary log position updated as it downloads events. See CHANGE MASTER TO: Option Persistence for more information
The slave's SQL thread reads events from the relay log. What it does with them depends on whether parallel replication is in use. If parallel replication is not in use, then the SQL thread applies the events to its local copy of the data. If parallel replication is in use, then the SQL thread hands off the events to its worker threads to apply in parallel.
The relay log position of the slave's SQL thread can be checked by executing the SHOW SLAVE STATUS
statement. It will be shown as the Relay_Log_File
and Relay_Log_Pos
columns.
The relay log position of the slave's SQL thread can be set by setting the RELAY_LOG_FILE
and RELAY_LOG_POS
options with the CHANGE MASTER
statement.
The relay log position of the slave's SQL thread is written to either the default relay-log.info
file or the file that is configured by the relay_log_info_file
system variable. The slave's SQL thread keeps this relay log position updated as it applies events. See CHANGE MASTER TO: Option Persistence for more information.
The corresponding binary log position of the current relay log position of the slave's SQL thread can be checked by executing the SHOW SLAVE STATUS
statement. It will be shown as the Relay_Master_Log_File
and Exec_Master_Log_Pos
columns.
If the slave is replicating binary log events that contain GTIDs, then the slave's SQL thread will write every GTID that it applies to the mysql.gtid_slave_pos
table. This GTID can be inspected and modified through the gtid_slave_pos
system variable.
If the slave has the log_slave_updates
system variable enabled and if the slave has the binary log enabled, then every write by the slave's SQL thread will also go into the slave's binary log. This means that GTIDs of replicated transactions would be reflected in the value of the gtid_binlog_pos
system variable.
See CHANGE MASTER TO: GTID Persistence for more information.
When parallel replication is in use, then the SQL thread hands off the events to its worker threads to apply in parallel.
© 2019 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/replication-threads/