Semisynchronous Replication

Description

Standard MariaDB replication is asynchronous, but MariaDB also provides a semisynchronous replication option. The feature is built into the server and is always available. In versions prior to , it was a separate plugin that needed to be installed.

With regular asynchronous replication, replicas request events from the primary's binary log whenever the replicas are ready. The primary does not wait for a replica to confirm that an event has been received.

With fully synchronous replication, all replicas are required to respond that they have received the events. See Galera Cluster.

Semisynchronous replication waits for just one replica to acknowledge that it has received and logged the events.

Semisynchronous replication therefore comes with some negative performance impact, but increased data integrity. Since the delay is based on the roundtrip time to the replica and back, this delay is minimized for servers in close proximity over fast networks.

Semisynchronous replication is built into the server. See for more information.

Enabling Semisynchronous Replication

Semisynchronous replication can be enabled by setting the relevant system variables on the primary and the replica.

If a server needs to be able to switch between acting as a primary and a replica, then you can enable both the primary and replica system variables on the server. For example, you might need to do this if is being used to enable auto-failover or switchover with MariaDB Monitor.

Enabling Semisynchronous Replication on the Primary

Semisynchronous replication can be enabled on the primary by setting the system variable to ON. It can be set dynamically with . For example:

It can also be set in a server in an prior to starting up the server. For example:

Enabling Semisynchronous Replication on the Replica

Semisynchronous replication can be enabled on the replica by setting the system variable to ON. It can be set dynamically with . For example:

It can also be set in a server in an prior to starting up the server. For example:

When switching between semisynchronous replication and asynchronous replication on a replica with already running, the replica I/O thread will need to be restarted. For example:

If this is not done, then the replica IO thread will continue to use the previous setting.

Configuring the Primary Timeout

In semisynchronous replication, only after the events have been written to the relay log and flushed does the replica acknowledge receipt of a transaction's events. If the replica does not acknowledge the transaction before a certain amount of time has passed, then a timeout occurs and the primary switches to asynchronous replication. This will be reflected in the primary's with messages like the following:

When this occurs, the status variable will be switched to OFF.

When at least one semisynchronous replica catches up, semisynchronous replication is resumed. This will be reflected in the primary's with messages like the following:

When this occurs, the status variable will be switched to ON.

The number of times that semisynchronous replication has been switched off can be checked by looking at the value of the status variable.

If you see a lot of timeouts like this in your environment, then you may want to change the timeout period. The timeout period can be changed by setting the system variable. It can be set dynamically with . For example:

It can also be set in a server in an prior to starting up the server. For example:

To determine a good value for the system variable, you may want to look at the values of the and status variables.

Configuring the Primary Wait Point

In semisynchronous replication, there are two potential points at which the primary can wait for the replica acknowledge the receipt of a transaction's events. These two wait points have different advantages and disadvantages.

The wait point is configured by the system variable. The supported values are:

• AFTER_SYNC

• AFTER_COMMIT

It can be set dynamically with . For example:

It can also be set in a server in an prior to starting up the server. For example:

When this variable is set to AFTER_SYNC, the primary performs the following steps:

1. Prepares the transaction in the storage engine.

2. Syncs the transaction to the .

3. Waits for acknowledgement from the replica.

4. Commits the transaction to the storage engine.

The effects of the AFTER_SYNC wait point are:

• All clients see the same data on the primary at the same time; after acknowledgement by the replica and after being committed to the storage engine on the primary.

• If the primary crashes, then failover should be lossless, because all transactions committed on the primary would have been replicated to the replica.

• However, if the primary crashes, then its may also contain events for transactions that were prepared by the storage engine and written to the binary log, but that were never actually committed by the storage engine. As part of the server's process, the server may recover these prepared transactions when the server is restarted. This could cause the "old" crashed primary to become inconsistent with its former replicas when they have been reconfigured to replace the old primary with a new one. The old primary in such a scenario can be re-introduced only as a . The server post-crash recovery of the server configured with rpl_semi_sync_slave_enabled = ON

When this variable is set to AFTER_COMMIT, the primary performs the following steps:

1. Prepares the transaction in the storage engine.

2. Syncs the transaction to the .

3. Commits the transaction to the storage engine.

4. Waits for acknowledgement from the replica.

The effects of the AFTER_COMMIT wait point are:

• Other clients may see the committed transaction before the committing client.

• If the primary crashes, then failover may involve some data loss, because the primary may have committed transactions that had not yet been acknowledged by the replicas.

Versions

System Variables

rpl_semi_sync_master_enabled

• Description: Set to ON to enable semi-synchronous replication primary. Disabled by default.

• Command line: --rpl-semi-sync-master-enabled[={0|1}]

• Scope: Global

• Dynamic: Yes

rpl_semi_sync_master_timeout

• Description: The timeout value, in milliseconds, for semi-synchronous replication in the primary. If this timeout is exceeded in waiting on a commit for acknowledgement from a replica, the primary will revert to asynchronous replication.

  • When a timeout occurs, the status variable will also be switched to OFF.

  • See for more information.

rpl_semi_sync_master_trace_level

• Description: The tracing level for semi-sync replication. Four levels are defined:

  • 1: General level, including for example time function failures.

  • 16: More detailed level, with more verbose information.

rpl_semi_sync_master_wait_no_slave

• Description: If all replicas have disconnected from the primary (i.e. is 0), this variable controls whether or not the primary will still suspend the next transaction's (and any others that commit within duration) commit phase to wait for a replica to connect or reconnect, and send an ACK. If set to ON, the default, the replica count may drop to zero, and the primary will still wait for the timeout period for the next transaction, and any more that commit after this transaction within the semi-sync timeout duration. If no ACK is received in this time, the primary will revert to asynchronous replication. If set to OFF, the primary will revert to asynchronous replication as soon as the replica count drops to zero.

• Command line: --rpl-semi-sync-master-wait-no-slave[={0|1}]

rpl_semi_sync_master_wait_point

• Description: Whether the transaction should wait for semi-sync acknowledgement after having synced the binlog (AFTER_SYNC), or after having committed in storage engine (AFTER_COMMIT, the default).

  • When this variable is set to AFTER_SYNC, the primary performs the following steps:

    1. Prepares the transaction in the storage engine.

rpl_semi_sync_slave_delay_master

• Description: Only write primary info file when ack is needed.

• Command line: --rpl-semi-sync-slave-delay-master[={0|1}]

• Scope: Global

• Dynamic: Yes

rpl_semi_sync_slave_enabled

• Description: Set to ON to enable semi-synchronous replication replica. Disabled by default.

• Command line: --rpl-semi-sync-slave-enabled[={0|1}]

• Scope: Global

• Dynamic: Yes

rpl_semi_sync_slave_kill_conn_timeout

• Description: Timeout for the mysql connection used to kill the replica io_thread's connection on primary. This timeout comes into play when stop slave is executed.

• Command line: --rpl-semi-sync-slave-kill-conn-timeout[={0|1}]

• Scope: Global

• Dynamic: Yes

rpl_semi_sync_slave_trace_level

• Description: The tracing level for semi-sync replication. The levels are the same as for .

• Command line: --rpl-semi-sync-slave-trace_level[=#]

• Scope: Global

• Dynamic: Yes

Options

init-rpl-role

• From , , , , and , changes the condition for semi-sync recovery to truncate the to instead use this option, when set to SLAVE. This avoids a possible error state where the replica’s state is ahead of the primaries. See .

rpl-semi-sync_master

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

rpl-semi-sync_slave

• Description: Controls how the server should treat the plugin when the server starts up.

  • Valid values are:

    • OFF - Disables the plugin without removing it from the table.

Status Variables

For a list of status variables added when the plugin is installed, see .

_{This page is licensed: CC BY-SA / Gnu FDL}