Handling an Unexpected Halt of a Replica While S1 is read only, perform the backup. For example, you can use  mysqldump . After the backup operation on S1 completes, restore S1 to its normal operational state by executing these statements: Although performing the backup on S1 is safe (as far as the backup is concerned), it is not optimal for performance because clients of S1 are blocked from executing updates. This strategy applies to backing up a source in a replication setup, but can also be used for a single server in a nonreplication setting. Put the replica R1 in a read-only state by executing these statements on it: While R1 is in a read-only state, the following properties are true: These properties provide the basis for a popular backup scenario: Having one replica busy performing a backup for a while is not a problem because it does not affect the entire network, and the system is still running during the backup. In particular, clients can still perform updates on the source server, which remains unaffected by backup activity on the replica. While R1 is read only, perform the backup. For example, you can use  mysqldump . After the backup operation on R1 completes, restore R1 to its normal operational state by executing these statements: After the replca is restored to normal operation, it again synchronizes to the source by catching up with any outstanding updates from the source’s binary log. In order for replication to be resilient to unexpected halts of the server (sometimes described as crash- safe) it must be possible for the replica to recover its state before halting. This section describes the impact of an unexpected halt of a replica during replication, and how to configure a replica for the best chance of recovery to continue replication. After an unexpected halt of a replica, upon restart the replication SQL thread must recover information about which transactions have been executed already. The information required for recovery is stored in the replica’s applier metadata repository. From MySQL 8.0, this repository is created by default as an InnoDB  table named  mysql.slave_relay_log_info . By using this transactional storage engine the information is always recoverable upon restart. Updates to the applier metadata repository are committed together with the transactions, meaning that the replica’s progress information recorded in that repository 17.4.2 Handling an Unexpected Halt of a Replica mysql>  SET GLOBAL read_only = OFF; mysql>  UNLOCK TABLES; mysql>  FLUSH TABLES WITH READ LOCK; mysql>  SET GLOBAL read_only = ON; mysql>  SET GLOBAL read_only = OFF; mysql>  UNLOCK TABLES; •The source S1 continues to operate, so making a backup on the source is not safe. •The replica R1 is stopped, so making a backup on the replica R1 is safe. Scenario 2: Backup with a Read-Only Replica 3632