Replication Features and Issues session, a replica always replicates a  DROP TEMPORARY TABLE IF EXISTS  statement, regardless of any exclusion rules that would normally apply for the specified table. A recommended practice when using statement-based replication is to designate a prefix for exclusive use in naming temporary tables that you do not want replicated, then employ a  --replicate-wild- ignore-table  option to match that prefix. For example, you might give all such tables names beginning with  norep  (such as  norepmytable ,  norepyourtable , and so on), then use  --replicate-wild- ignore-table=norep%  to prevent them from being replicated. The global system variable  slave_transaction_retries  sets the maximum number of times for applier threads on a single-threaded or multithreaded replica to automatically retry failed transactions before stopping. Transactions are automatically retried when the SQL thread fails to execute them because of an  InnoDB  deadlock, or when the transaction’s execution time exceeds the  InnoDB innodb_lock_wait_timeout  value. If a transaction has a non-temporary error that prevents it from succeeding, it is not retried. The default setting for  slave_transaction_retries  is 10, meaning that a failing transaction with an apparently temporary error is retried 10 times before the applier thread stops. Setting the variable to 0 disables automatic retrying of transactions. On a multithreaded replica, the specified number of transaction retries can take place on all applier threads of all channels. The Performance Schema table replication_applier_status  shows the total number of transaction retries that took place on each replication channel, in the  COUNT_TRANSACTIONS_RETRIES  column. The process of retrying transactions can cause lag on a replica or on a Group Replication group member, which can be configured as a single-threaded or multithreaded replica. The Performance Schema table replication_applier_status_by_worker  shows detailed information on transaction retries by the applier threads on a single-threaded or multithreaded replica. This data includes timestamps showing how long it took the applier thread to apply the last transaction from start to finish (and when the transaction currently in progress was started), and how long this was after the commit on the original source and the immediate source. The data also shows the number of retries for the last transaction and the transaction currently in progress, and enables you to identify the transient errors that caused the transactions to be retried. You can use this information to see whether transaction retries are the cause of replication lag, and investigate the root cause of the failures that led to the retries. By default, source and replica servers assume that they are in the same time zone. If you are replicating between servers in different time zones, the time zone must be set on both source and replica. Otherwise, statements depending on the local time on the source are not replicated properly, such as statements that use the  NOW()  or  FROM_UNIXTIME()  functions. Verify that your combination of settings for the system time zone ( system_time_zone ), server current time zone (the global value of  time_zone ), and per-session time zones (the session value of  time_zone ) on the source and replica is producing the correct results. In particular, if the  time_zone  system variable is set to the value  SYSTEM , indicating that the server time zone is the same as the system time zone, this can cause the source and replica to apply different time zones. For example, a source could write the following statement in the binary log: If this source and its replica have a different setting for their system time zones, this statement can produce unexpected results on the replica, even if the replica’s global  time_zone  value has been set to match the source’s. For an explanation of MySQL Server’s time zone settings, and how to change them, see Section 5.1.15, “MySQL Server Time Zone Support” . SET @@session.time_zone=’SYSTEM’; 3674 17.5.1.33 Replication and Time Zones 17.5.1.32 Replication Retries and Timeouts