How Servers Evaluate Replication Filtering Rules when the same database or table is present on multiple sources, and the replica is only required to replicate it from one source. For instructions to set up replication channels, see Section 17.1.5, “MySQL Multi-Source Replication” , and for more information on how they work, see Section 17.2.2, “Replication Channels” . Each channel on a multi-source replica must replicate from a different source. You cannot set up multiple replication channels from a single replica to a single source, even if you use replication filters to select different data to replicate on each channel. This is because the server IDs of replicas must be unique in a replication topology. The source distinguishes replicas only by their server IDs, not by the names of the replication channels, so it cannot recognize different replication channels from the same replica. On a MySQL server instance that is configured for Group Replication, channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replica to a source that is outside the group. They cannot be used on the group_replication_applier  or  group_replication_recovery  channels. Filtering on these channels would make the group unable to reach agreement on a consistent state. For a multi-source replica in a diamond topology (where the replica replicates from two or more sources, which in turn replicate from a common source), when GTID-based replication is in use, ensure that any replication filters or other channel configuration are identical on all channels on the multi-source replica. With GTID- based replication, filters are applied only to the transaction data, and GTIDs are not filtered out. This happens so that a replica’s GTID set stays consistent with the source’s, meaning GTID auto-positioning can be used without re-acquiring filtered out transactions each time. In the case where the downstream replica is multi-source and receives the same transaction from multiple sources in a diamond topology, the downstream replica now has multiple versions of the transaction, and the result depends on which channel applies the transaction first. The second channel to attempt it skips the transaction using GTID auto-skip, because the transaction’s GTID was added to the  gtid_executed  set by the first channel. With identical filtering on the channels, there is no problem because all versions of the transaction contain the same data, so the results are the same. However, with different filtering on the channels, the database can become inconsistent and replication can hang. When multiple replication channels exist, for example in a multi-source replication topology, replication filters are applied as follows: 3612 •Any channel specific replication filter adds the filter to the specified channel’s replication filters for the specified filter type. •Any global replication filter specified is added to the global replication filters of the filter type ( do_db , do_ignore_table , and so on). Important Important Important Overview of Replication Filters and Channels