Replication Features and Issues that do not support multiple triggers, an error occurs on those replicas if a trigger is created on the source for a table that already has a trigger with the same trigger event and action time. Downgrades.  If you downgrade a server that supports multiple triggers to an older version that does not, the downgrade has these effects: To avoid these problems, modify your triggers before downgrading. For each table that has multiple triggers per combination of trigger event and action time, convert each such set of triggers to a single trigger as follows: TRUNCATE TABLE  is normally regarded as a DML statement, and so would be expected to be logged and replicated using row-based format when the binary logging mode is  ROW  or  MIXED . However this caused issues when logging or replicating, in  STATEMENT  or  MIXED  mode, tables that used transactional storage engines such as  InnoDB  when the transaction isolation level was  READ COMMITTED  or  READ UNCOMMITTED , which precludes statement-based logging. TRUNCATE TABLE  is treated for purposes of logging and replication as DDL rather than DML so that it can be logged and replicated as a statement. However, the effects of the statement as applicable to  InnoDB and other transactional tables on replicas still follow the rules described in Section 13.1.37, “TRUNCATE TABLE Statement”  governing such tables. (Bug #36763) The maximum length for user names in MySQL 8.0 is 32 characters. Replication of user names longer than 16 characters fails when the replica runs a version of MySQL previous to 5.7, because those versions support only shorter user names. This occurs only when replicating from a newer source to an older replica, which is not a recommended configuration. System variables are not replicated correctly when using  STATEMENT  mode, except for the following variables when they are used with session scope: 3679 • auto_increment_increment • auto_increment_offset 17.5.1.39 Replication and Variables 17.5.1.38 Replication and User Name Length 17.5.1.37 Replication and TRUNCATE TABLE •For each table that has triggers, all trigger definitions are in the  .TRG  file for the table. However, if there are multiple triggers with the same trigger event and action time, the server executes only one of them when the trigger event occurs. For information about  .TRG  files, see the Table Trigger Storage section of the MySQL Server Doxygen documentation, available at https://dev.mysql.com/doc/index-other.html. •If triggers for the table are added or dropped subsequent to the downgrade, the server rewrites the table’s  .TRG  file. The rewritten file retains only one trigger per combination of trigger event and action time; the others are lost. 1. For each trigger, create a stored routine that contains all the code in the trigger. Values accessed using NEW  and  OLD  can be passed to the routine using parameters. If the trigger needs a single result value from the code, you can put the code in a stored function and have the function return the value. If the trigger needs multiple result values from the code, you can put the code in a stored procedure and return the values using  OUT  parameters. 2. Drop all triggers for the table. 3. Create one new trigger for the table that invokes the stored routines just created. The effect for this trigger is thus the same as the multiple triggers it replaces.