Replication Features and Issues The replica also writes a  DELETE  or (from MySQL 8.0.22)  TRUNCATE TABLE  statement to its own binary log, which is passed on to any downstream replicas, causing them to empty their own  MEMORY  tables. The safe way to restart a replica that is replicating  MEMORY  tables is to first drop or delete all rows from the MEMORY  tables on the source and wait until those changes have replicated to the replica. Then it is safe to restart the replica. An alternative restart method may apply in some cases. When  binlog_format=ROW , you can prevent the replica from stopping if you set  slave_exec_mode=IDEMPOTENT  before you start the replica again. This allows the replica to continue to replicate, but its  MEMORY  tables still differ from those on the source. This is acceptable if the application logic is such that the contents of  MEMORY  tables can be safely lost (for example, if the  MEMORY  tables are used for caching).  slave_exec_mode=IDEMPOTENT  applies globally to all tables, so it may hide other replication errors in non- MEMORY  tables. (The method just described is not applicable in NDB Cluster, where  slave_exec_mode  is always IDEMPOTENT , and cannot be changed.) The size of  MEMORY  tables is limited by the value of the  max_heap_table_size  system variable, which is not replicated (see Section 17.5.1.39, “Replication and Variables” ). A change in  max_heap_table_size takes effect for  MEMORY  tables that are created or updated using  ALTER TABLE ... ENGINE = MEMORY or  TRUNCATE TABLE  following the change, or for all  MEMORY  tables following a server restart. If you increase the value of this variable on the source without doing so on the replica, it becomes possible for a table on the source to grow larger than its counterpart on the replica, leading to inserts that succeed on the source but fail on the replica with  Table is full  errors. This is a known issue (Bug #48666). In such cases, you must set the global value of  max_heap_table_size  on the replica as well as on the source, then restart replication. It is also recommended that you restart both the source and replica MySQL servers, to ensure that the new value takes complete (global) effect on each of them. See Section 16.3, “The MEMORY Storage Engine” , for more information about  MEMORY  tables. Data modification statements made to tables in the  mysql  schema are replicated according to the value of  binlog_format ; if this value is  MIXED , these statements are replicated using row-based format. However, statements that would normally update this information indirectly—such  GRANT ,  REVOKE , and statements manipulating triggers, stored routines, and views—are replicated to replicas using statement- based replication. It is possible for the data on the source and replica to become different if a statement is written in such a way that the data modification is nondeterministic; that is, left up the query optimizer. (In general, this is not a good practice, even outside of replication.) Examples of nondeterministic statements include  DELETE  or UPDATE  statements that use  LIMIT  with no  ORDER BY  clause; see Section 17.5.1.18, “Replication and LIMIT” , for a detailed discussion of these. Replication is supported between partitioned tables as long as they use the same partitioning scheme and otherwise have the same structure, except where an exception is specifically allowed (see Section 17.5.1.9, “Replication with Differing Table Definitions on Source and Replica” ). Replication between tables that have different partitioning is generally not supported. This because statements (such as  ALTER TABLE ... DROP PARTITION ) that act directly on partitions in such cases might produce different results on the source and the replica. In the case where a table is partitioned on the source but not on the replica, any statements that operate on partitions on the source’s copy of the replica fail on the replica. When the replica’s copy of the table is partitioned but the source’s copy is not, 17.5.1.24 Replication and Partitioning 17.5.1.23 Replication and the Query Optimizer 17.5.1.22 Replication of the mysql System Schema 3669