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. 

## 17.5.1.22 Replication of the mysql System Schema 

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. 

## 17.5.1.23 Replication and the Query Optimizer 

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. 

## 17.5.1.24 Replication and Partitioning 

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, 

