content_image/788112.jpg
•If your source makes use of transactions and you are not concerned about transaction support on your replicas, use MyISAM  or another nontransactional engine on the replicas. See Section 17.4.4, “Using Replication with Different Source and Replica Storage Engines” . 

•If your replicas are not acting as sources, and you have a potential solution in place to ensure that you can bring up a source in the event of failure, then you can disable the log_slave_updates  system variable on the replicas. This prevents “dumb”  replicas from also logging events they have executed into their own binary log. 

## 17.4.8 Switching Sources During Failover 

You can tell a replica to change to a new source using the CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or CHANGE MASTER TO  statement (before MySQL 8.0.23). The replica does not check whether the databases on the source are compatible with those on the replica; it simply begins reading and executing events from the specified coordinates in the new source’s binary log. In a failover situation, all the servers in the group are typically executing the same events from the same binary log file, so changing the source of the events should not affect the structure or integrity of the database, provided that you exercise care in making the change. 

Replicas should be run with binary logging enabled (the --log-bin  option), which is the default. If you are not using GTIDs for replication, then the replicas should also be run with --log-slave-updates=OFF (logging replica updates is the default). In this way, the replica is ready to become a source without restarting the replica mysqld . Assume that you have the structure shown in Figure 17.4, “Redundancy Using Replication, Initial Structure” . 

<img src='content_image/788112.jpg'>

