Replication Features and Issues Using different storage engines on source and replica.   It is possible to replicate transactional tables on the source using nontransactional tables on the replica. For example, you can replicate an  InnoDB source table as a  MyISAM  replica table. However, if you do this, there are problems if the replica is stopped in the middle of a  BEGIN  ...  COMMIT  block because the replica restarts at the beginning of the  BEGIN  block. It is also safe to replicate transactions from  MyISAM  tables on the source to transactional tables, such as tables that use the  InnoDB  storage engine, on the replica. In such cases, an  AUTOCOMMIT=1  statement issued on the source is replicated, thus enforcing  AUTOCOMMIT  mode on the replica. When the storage engine type of the replica is nontransactional, transactions on the source that mix updates of transactional and nontransactional tables should be avoided because they can cause inconsistency of the data between the source transactional table and the replica nontransactional table. That is, such transactions can lead to source storage engine-specific behavior with the possible effect of replication going out of synchrony. MySQL does not issue a warning about this, so extra care should be taken when replicating transactional tables from the source to nontransactional tables on the replicas. Changing the binary logging format within transactions.   The  binlog_format  and binlog_checksum  system variables are read-only as long as a transaction is in progress. Every transaction (including  autocommit  transactions) is recorded in the binary log as though it starts with a  BEGIN  statement, and ends with either a  COMMIT  or a  ROLLBACK  statement. This is even true for statements affecting tables that use a nontransactional storage engine (such as  MyISAM ). For restrictions that apply specifically to XA transactions, see Section 13.3.8.3, “Restrictions on XA Transactions” . Note 17.5.1.36 Replication and Triggers With statement-based replication, triggers executed on the source also execute on the replica. With row- based replication, triggers executed on the source do not execute on the replica. Instead, the row changes on the source resulting from trigger execution are replicated and applied on the replica. This behavior is by design. If under row-based replication the replica applied the triggers as well as the row changes caused by them, the changes would in effect be applied twice on the replica, leading to different data on the source and the replica. If you want triggers to execute on both the source and the replica, perhaps because you have different triggers on the source and replica, you must use statement-based replication. However, to enable replica- side triggers, it is not necessary to use statement-based replication exclusively. It is sufficient to switch to statement-based replication only for those statements where you want this effect, and to use row-based replication the rest of the time. A statement invoking a trigger (or function) that causes an update to an  AUTO_INCREMENT  column is not replicated correctly using statement-based replication. MySQL 8.0 marks such statements as unsafe. (Bug #45677) A trigger can have triggers for different combinations of trigger event ( INSERT ,  UPDATE ,  DELETE ) and action time ( BEFORE ,  AFTER ), and multiple triggers are permitted. For brevity, “multiple triggers”  here is shorthand for “multiple triggers that have the same trigger event and action time.” Upgrades.  Multiple triggers are not supported in versions earlier than MySQL 5.7. If you upgrade servers in a replication topology that use a version earlier than MySQL 5.7, upgrade the replicas first and then upgrade the source. If an upgraded replication source server still has old replicas using MySQL versions 3678