Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
The data in MEMORY tables is not permanent and is lost between server restarts.
Thus, they are more likely to be used for temporary caches than for significant data that requires replication.
In fact, replication desynchronization is unavoidable if the slave restarts, but not the master.
The automatically binlogged TRUNCATE query can represent this desync, which, while well-intentioned, has rather caused some confusion (MDEV-29796, MDEV-35358, MDEV-38600).
But, only by excluding this temporary data from the binlog/replication pipeline (similar to the mysql database, reference) can it be prevented in the first place.
This exclusion should be done on the same server as the source of the memory table, i.e., the master side (MDEV-9345).
The master's Binlog Dump thread should exclude memory tables by default unless the slave has explicitly configured to allow some or all of them.
This new filter should be able to combine with existing replication filters, such as @@replicate_ignore_table.
For convenience, the slave should also receive a new configuration that opts in all memory tables in batch, such as:
- @@replicate_memory_tables
- @@replicate_temporary_tables for including Global Temporary Tables (MDEV-35915) in the future
- @@replicate_do_engine & @@replicate_ignore_engine
The original suggestion is Developers-only in MDEV-38600's comments.
Attachments
Issue Links
- is blocked by
-
MDEV-9345 Replication to enable filtering on master
-
- In Review
-
- relates to
-
MDEV-35915 Implement Global temporary tables
-
- Stalled
-
- split from
-
MDEV-38600 Binlogging of MEMORY table recreation from server restart is silently deferred
-
- Closed
-