Bug #95496 | Replication of memory tables | ||
---|---|---|---|
Submitted: | 23 May 2019 13:51 | Modified: | 24 Jul 2020 15:45 |
Reporter: | Iwo P | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.7.26, 8.0.16 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[23 May 2019 13:51]
Iwo P
[30 May 2019 11:41]
MySQL Verification Team
Hello Iwo P, Thank you for the report and feedback. Thanks, Umesh
[11 Aug 2019 9:40]
Daniƫl van Eeden
This is directly related to my contribution in https://bugs.mysql.com/bug.php?id=93771 which unfortunately isn't implemented completely yet
[24 Jul 2020 15:45]
Margaret Fisher
Posted by developer: Changelog entry added for MySQL 8.0.22 and 5.7.32: When a replication source server shuts down and restarts, its MEMORY tables become empty. To replicate this effect to replicas, the first time that the source uses a given MEMORY table after startup, it logs an event that notifies replicas that the table must be emptied by writing a statement to the binary log to that effect. Previously, this was a DELETE statement, but it is now a TRUNCATE statement. A replica server also writes this statement to its own binary log when it shuts down and restarts. The statement is always logged in statement format, even if the binary logging format is set to ROW, and it is written even if read_only or super_read_only mode is set on the server. Documentation updates made in https://dev.mysql.com/doc/refman/8.0/en/replication-features-memory.html https://dev.mysql.com/doc/refman/8.0/en/memory-storage-engine.html
[11 Jul 2021 19:51]
Margaret Fisher
Posted by developer: Already changelogged, reclosing.