当复制源服务器关闭并重新启动时,其
MEMORY
表变为空。为了将这种效果复制到副本,源MEMORY
在启动后第一次使用给定表时,它会记录一个事件,通知副本必须通过将该表的
DELETE
语句写入二进制日志来清空该表。该语句始终以语句格式记录,即使二进制日志记录格式设置为
ROW
,即使
在服务器上设置了read_only
或
super_read_only
模式,它也会被写入。请注意,副本仍然有过时的数据
MEMORY
在源重新启动和它第一次使用该表之间的间隔期间。为了避免直接查询副本可能返回陈旧数据的时间间隔,您可以设置
系统变量来命名一个文件,该文件包含在启动时
init_file
填充源表的语句
。MEMORY
当副本服务器关闭并重新启动时,其
MEMORY
表变为空。这会导致副本与源不同步,并可能导致其他故障或导致副本停止:
从源接收的行格式更新和删除可能会失败并显示。
Can't find record in '
memory_table
'诸如此类的语句 可能会在源和副本上插入一组不同的行。
INSERT INTO ... SELECT FROM
memory_table
副本还将一条DELETE
语句写入自己的二进制日志,该日志将传递给任何下游副本,导致它们清空自己的
MEMORY
表。
重新启动正在复制
MEMORY
表的副本的安全方法是首先从源上的表中删除或删除所有行,MEMORY
然后等待这些更改已复制到副本。然后重新启动副本是安全的。
在某些情况下可能会应用替代的重启方法。当 时
,如果您
在再次启动副本之前进行binlog_format=ROW
设置,则可以防止副本停止
。slave_exec_mode=IDEMPOTENT
这允许副本继续复制,但它的
MEMORY
表仍然与源上的不同。如果应用程序逻辑可以安全地丢失表的内容MEMORY
(例如,如果
MEMORY
表用于缓存),这是可以接受的。
slave_exec_mode=IDEMPOTENT
全局应用于所有表,因此它可能隐藏非MEMORY
表中的其他复制错误。
(刚刚描述的方法不适用于 NDB Cluster,其中slave_exec_mode
始终是
IDEMPOTENT
,并且无法更改。)
表的大小MEMORY
受系统变量的值限制,
max_heap_table_size
系统变量不被复制(参见
第 17.4.1.35 节,“复制和变量”)。中的更改
对使用更改或更改后创建或更新max_heap_table_size
的表生效
,或者对服务器重新启动后的所有
表生效。如果您在源上增加此变量的值而不在副本上这样做,则源上的表可能会变得比副本上的对应表大,导致插入在源上成功但在副本上失败表已满MEMORY
ALTER TABLE
... ENGINE = MEMORY
TRUNCATE
TABLE
MEMORY
错误。这是一个已知问题(缺陷 #48666)。在这种情况下,您必须在副本和源上设置全局值
max_heap_table_size
,然后重新启动复制。还建议您重新启动源和副本 MySQL 服务器,以确保新值对它们中的每一个都产生完整(全局)影响。
有关表
的更多信息,
请参见第 15.3 节,“内存存储引擎” 。MEMORY