Improving Replication Performance Important 17.4.7 Improving Replication Performance Note You should  not  use  --replicate-do-db  for this purpose when using statement- based replication, since statement-based replication causes this option’s effects to vary according to the database that is currently selected. This applies to mixed- format replication as well, since this enables some updates to be replicated using the statement-based format. However, it should be safe to use  --replicate-do-db  for this purpose if you are using row-based replication only, since in this case the currently selected database has no effect on the option’s operation. For example, to support the separation as shown in Figure 17.2, “Replicating Databases to Separate Replicas” , you should configure each replica as follows, before executing  START REPLICA | SLAVE : Each replica in this configuration receives the entire binary log from the source, but executes only those events from the binary log that apply to the databases and tables included by the  --replicate-wild- do-table  option in effect on that replica. If you have data that must be synchronized to the replicas before replication starts, you have a number of choices: This does not work with  InnoDB  databases unless you use innodb_file_per_table . As the number of replicas connecting to a source increases, the load, although minimal, also increases, as each replica uses a client connection to the source. Also, as each replica must receive a full copy of the source’s binary log, the network load on the source may also increase and create a bottleneck. If you are using a large number of replicas connected to one source, and that source is also busy processing requests (for example, as part of a scale-out solution), then you may want to improve the performance of the replication process. One way to improve the performance of the replication process is to create a deeper replication structure that enables the source to replicate to only one replica, and for the remaining replicas to connect to this primary replica for their individual replication requirements. A sample of this structure is shown in Figure 17.3, “Using an Additional Replication Source to Improve Performance” . 3639 •Synchronize all the data to each replica, and delete the databases, tables, or both that you do not want to keep. •Use  mysqldump  to create a separate dump file for each database and load the appropriate dump file on each replica. •Use a raw data file dump and include only the specific files and databases that you need for each replica. •Replica 1 should use  --replicate-wild-do-table=databaseA.% . •Replica 2 should use  --replicate-wild-do-table=databaseB.% . •Replica 3 should use  --replicate-wild-do-table=databaseC.% .