content_image/810729.jpg
• LOAD DATA statements. LOAD DATA  is treated as unsafe and when binlog_format=MIXED  the statement is logged in row-based format. When binlog_format=STATEMENT LOAD DATA  does not generate a warning, unlike other unsafe statements. 

• XA transactions.  If two XA transactions committed in parallel on the source are being prepared on the replica in the inverse order, locking dependencies can occur with statement-based replication that cannot be safely resolved, and it is possible for replication to fail with deadlock on the replica. When binlog_format=STATEMENT  is set, DML statements inside XA transactions are flagged as being unsafe and generate a warning. When binlog_format=MIXED  or binlog_format=ROW  is set, DML statements inside XA transactions are logged using row-based replication, and the potential issue is not present. 

• DEFAULT  clause that refers to a nondeterministic function.  If an expression default value refers to a nondeterministic function, any statement that causes the expression to be evaluated is unsafe for statement-based replication. This includes statements such as INSERT , UPDATE , and ALTER TABLE . Unlike most other unsafe statements, this category of statement cannot be replicated safely in row- based format. When binlog_format  is set to STATEMENT , the statement is logged and executed but a warning message is written to the error log. When binlog_format  is set to MIXED  or ROW , the statement is not executed and an error message is written to the error log. For more information on the handling of explicit defaults, see Explicit Default Handling as of MySQL 8.0.13. 

For additional information, see Section 17.5.1, “Replication Features and Issues” . 

## 17.2.2 Replication Channels 

In MySQL multi-source replication, a replica opens multiple replication channels, one for each source server. The replication channels represent the path of transactions flowing from a source to the replica. Each replication channel has its own receiver (I/O) thread, one or more applier (SQL) threads, and relay log. When transactions from a source are received by a channel’s receiver thread, they are added to the channel’s relay log file and passed through to the channel’s applier threads. This enables each channel to function independently. 

This section describes how channels can be used in a replication topology, and the impact they have on single-source replication. For instructions to configure sources and replicas for multi-source replication, to start, stop and reset multi-source replicas, and to monitor multi-source replication, see Section 17.1.5, “MySQL Multi-Source Replication” . 

The maximum number of channels that can be created on one replica server in a multi-source replication topology is 256. Each replication channel must have a unique (nonempty) name, as explained in Section 17.2.2.4, “Replication Channel Naming Conventions” . The error codes and messages that are issued when multi-source replication is enabled specify the channel that generated the error. 

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

## Note 

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. 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. 

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. 

