A multi-source replica can also be set up as a multi-threaded replica, by setting the slave_parallel_workers  system variable to a value greater than 0. When you do this on a multi- source replica, each channel on the replica has the specified number of applier threads, plus a coordinator thread to manage them. You cannot configure the number of applier threads for individual channels. 

From MySQL 8.0, multi-source replicas can be configured with replication filters on specific replication channels. Channel specific replication filters can be used when the same database or table is present on multiple sources, and you only need the replica to replicate it from one source. For GTID-based replication, if the same transaction might arrive from multiple sources (such as in a diamond topology), you must ensure the filtering setup is the same on all channels. For more information, see Section 17.2.5.4, “Replication Channel Based Filters” . 

This section provides tutorials on how to configure sources and replicas for multi-source replication, how to start, stop and reset multi-source replicas, and how to monitor multi-source replication. 

## 17.1.5.1 Configuring Multi-Source Replication 

A multi-source replication topology requires at least two sources and one replica configured. In these tutorials, we assume that you have two sources source1  and source2 , and a replica replicahost . The replica replicates one database from each of the sources, db1  from source1  and db2  from source2 . 

Sources in a multi-source replication topology can be configured to use either GTID-based replication, or binary log position-based replication. See Section 17.1.3.4, “Setting Up Replication Using GTIDs”  for how to configure a source using GTID-based replication. See Section 17.1.2.1, “Setting the Replication Source Configuration”  for how to configure a source using file position based replication. 

Replicas in a multi-source replication topology require TABLE  repositories for the replica’s connection metadata repository and applier metadata repository, which are the default in MySQL 8.0. Multi-source replication is not compatible with the deprecated alternative file repositories. 

Create a suitable user account on all the sources that the replica can use to connect. You can use the same account on all the sources, or a different account on each. If you create an account solely for the purposes of replication, that account needs only the REPLICATION SLAVE  privilege. For example, to set up a new user, ted , that can connect from the replica replicahost , use the mysql  client to issue these statements on each of the sources: 

mysql> CREATE USER ’ted’@’replicahost’ IDENTIFIED BY ’ password ’; mysql> GRANT REPLICATION SLAVE ON *.* TO ’ted’@’replicahost’; 

For more details, and important information on the default authentication plugin for new users from MySQL 8.0, see Section 17.1.2.3, “Creating a User for Replication” . 

## 17.1.5.2 Provisioning a Multi-Source Replica for GTID-Based Replication 

If the sources in the multi-source replication topology have existing data, it can save time to provision the replica with the relevant data before starting replication. In a multi-source replication topology, cloning or copying of the data directory cannot be used to provision the replica with data from all of the sources, and you might also want to replicate only specific databases from each source. The best strategy for provisioning such a replica is therefore to use mysqldump  to create an appropriate dump file on each source, then use the mysql  client to import the dump file on the replica. 

If you are using GTID-based replication, you need to pay attention to the SET @@GLOBAL.gtid_purged statement that mysqldump  places in the dump output. This statement transfers the GTIDs for the transactions executed on the source to the replica, and the replica requires this information. However, for any case more complex than provisioning one new, empty replica from one source, you need to check 

