# Replication Threads

{% hint style="info" %}
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](https://jira.mariadb.org/browse/MDEV-18777) to follow progress on this effort.
{% endhint %}

MariaDB's [replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication) implementation requires several types of threads.

## Threads on the Primary

The primary usually only has one type of replication-related thread: the binary log dump thread.

If [semisynchronous replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/semisynchronous-replication) is enabled, then the primary also has an ACK receiver thread.

### Binary Log Dump Thread

The binary log dump thread runs on the primary and dumps the [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) to the replica. This thread can be identified by running the [SHOW PROCESSLIST](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/show/show-processlist) statement and finding the thread where the [thread command](https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/buffers-caches-and-threads/thread-command-values) is `"Binlog Dump"`.

The primary creates a separate binary log dump thread for each replica connected to the primary. You can identify which replicas are connected to the primary by executing the [SHOW SLAVE HOSTS](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/show/show-replica-hosts) statement.

#### Binary Log Dump Threads and the Shutdown Process

When a primary server is shut down and it goes through the normal shutdown process, the primary kills client threads in random order. By default, the primary 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 primary during a normal shutdown that won't be replicated. This is true even if [semi-synchronous replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/semisynchronous-replication) is being used. Data is not lost; it is stored in the primary server's binary log. The replicas on reconnection, after the primary server restarts, will resume at the exact position they were killed off during the primary shutdown. No data is lost.

In [MariaDB 10.4](https://app.gitbook.com/s/aEnK0ZXmUbJzqQrTjFyb/community-server/old-releases/10.4/what-is-mariadb-104) and later, this problem can be solved by shutting down the server using either the [mariadb-admin](https://mariadb.com/docs/server/clients-and-utilities/administrative-tools/mariadb-admin) utility or the [SHUTDOWN](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/shutdown) command and providing a special option.

For example, this problem can be solved by shutting down the server with the [mariadb-admin](https://mariadb.com/docs/server/clients-and-utilities/administrative-tools/mariadb-admin) utility and by providing the `--wait-for-all-slaves` option to the utility and by executing the `shutdown` command with the utility:

```
mariadb-admin --wait-for-all-slaves shutdown
```

Or this problem can be solved by shutting down the server with the [SHUTDOWN](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/shutdown) command and by providing the `WAIT FOR ALL SLAVES` option to the command:

```sql
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](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) has been sent to all connected replicas.

In [MariaDB 10.4](https://app.gitbook.com/s/aEnK0ZXmUbJzqQrTjFyb/community-server/old-releases/10.4/what-is-mariadb-104) 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](https://mariadb.com/docs/server/server-management/starting-and-stopping-mariadb/systemd) or [sysVinit](https://mariadb.com/docs/server/server-management/starting-and-stopping-mariadb/sysvinit).

In [MariaDB 10.3](https://app.gitbook.com/s/aEnK0ZXmUbJzqQrTjFyb/community-server/old-releases/10.3/what-is-mariadb-103) and before, it is recommended to manually switchover replicas to a new primary before shutting down the old primary.

### ACK Receiver Thread

When [semisynchronous replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/semisynchronous-replication) is enabled, semisynchronous replicas send acknowledgements (ACKs) to their primary to confirm that they have received some transaction. The primary creates an ACK receiver thread to receive these ACKs.

## Threads on the Replica

The replica has three types of replication-related threads: the replica I/O thread, the replica SQL thread, and worker threads, which are only applicable when [parallel replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/parallel-replication) is in use.

When [multi-source replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/multi-source-replication) is in use, each independent replication connection has its own replica threads of each type.

### Replica I/O Thread

The replica's I/O thread receives the [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) events from the primary and writes them to its [relay log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log).

#### Binary Log Position

The [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) position of the replica's I/O thread can be checked by executing the [SHOW SLAVE STATUS](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/show/show-replica-status) statement. It will be shown as the `Master_Log_File` and `Read_Master_Log_Pos` columns.

The [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) position of the replica's I/O thread can be set by setting the [MASTER\_LOG\_FILE](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to#master_log_file) and [MASTER\_LOG\_POS](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to#master_log_pos) options with the [CHANGE MASTER](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to) statement.

The [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) position of the replica's I/O thread and the values of most other [CHANGE MASTER](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to) options are written to either the default `master.info` file or the file that is configured by the [master\_info\_file](https://mariadb.com/docs/server/server-management/starting-and-stopping-mariadb/mariadbd-options) option. The replica's I/O thread keeps this [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) position updated as it downloads events only when the [MASTER\_USE\_GTID](#master_use_gtid) option is set to `NO`. Otherwise the file is not updated on a per event basis. See [CHANGE MASTER TO: Option Persistence](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to#option-persistence) for more information.

### Replica SQL Thread

The replica's SQL thread reads events from the [relay log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log). What it does with them depends on whether [parallel replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/parallel-replication) is in use. If [parallel replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/parallel-replication) is not in use, then the SQL thread applies the events to its local copy of the data. If [parallel replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/parallel-replication) is in use, then the SQL thread hands off the events to its worker threads to apply in parallel.

#### Relay Log Position

The [relay log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log) position of the replica's SQL thread can be checked by executing the [SHOW SLAVE STATUS](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/show/show-replica-status) statement. It will be shown as the `Relay_Log_File` and `Relay_Log_Pos` columns.

The [relay log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log) position of the replica's SQL thread can be set by setting the [RELAY\_LOG\_FILE](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to#relay_log_file) and [RELAY\_LOG\_POS](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to#relay_log_pos) options with the [CHANGE MASTER](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to) statement.

The [relay log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log) position of the replica'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](https://mariadb.com/docs/server/ha-and-performance/replication-and-binary-log-system-variables#relay_log_info_file) system variable. The replica's SQL thread keeps this [relay log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log) position updated as it applies events. See [CHANGE MASTER TO: Option Persistence](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to#option-persistence) for more information.

#### Binary Log Position

The corresponding [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) position of the current [relay log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log) position of the replica's SQL thread can be checked by executing the [SHOW SLAVE STATUS](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/show/show-replica-status) statement. It will be shown as the `Relay_Master_Log_File` and `Exec_Master_Log_Pos` columns.

#### GTID Position

If the replica is replicating [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) events that contain [GTIDs](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid), then the [replica's's SQL thread](#replica-sql-thread) will write every GTID that it applies to the [mysql.gtid\_slave\_pos](https://mariadb.com/docs/server/reference/system-tables/the-mysql-database-tables/mysqlgtid_slave_pos-table) table. This GTID can be inspected and modified through the [gtid\_slave\_pos](https://mariadb.com/docs/server/ha-and-performance/gtid#gtid_slave_pos) system variable.

If the replica has the [log\_slave\_updates](https://mariadb.com/docs/server/ha-and-performance/replication-and-binary-log-system-variables#log_slave_updates) system variable enabled and if the replica has the [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log) enabled, then every write by the [replica's SQL thread](#replica-sql-thread) will also go into the replica's [binary log](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log). This means that [GTIDs](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid) of replicated transactions would be reflected in the value of the [gtid\_binlog\_pos](https://mariadb.com/docs/server/ha-and-performance/gtid#gtid_binlog_pos) system variable.

See [CHANGE MASTER TO: GTID Persistence](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to#gtid-persistence) for more information.

### Worker Threads

When [parallel replication](https://mariadb.com/docs/server/ha-and-performance/standard-replication/parallel-replication) is in use, then the SQL thread hands off the events to its worker threads to apply in parallel.

<sub>*This page is licensed: CC BY-SA / Gnu FDL*</sub>

{% @marketo/form formId="4316" %}