我有一个10.6.8
托管在 Amazon RDS ( db.m6g.4xlarge
) 上的 MariaDB 实例 ( )。它启用了自动次要升级,不幸的是,它在上次触发时导致了数小时的停机时间。
在查看日志时,问题似乎是我们的一些最大的表需要在升级完成之前重建。
error : Table rebuild required. Please do "ALTER TABLE 'my_table' FORCE" or dump/reload to fix it!
每个都需要几个小时。最大的有大约 1.7 亿行和 20 列。
我想在最坏的情况下,我们可以安排停机时间。但是,如果有某种方法可以以不同的方式做事,这样这就不会成为未来的问题,那将是更可取的。
到目前为止,我调查过:
- 添加修剪以避免在其中一些表中保留不需要的旧数据。这使得它们足够小,重建不会导致数小时的停机
- 将来,做并安排我自己的小升级,
mysqlcheck
提前运行,至少事先知道哪些表可能需要重建。这仍然不理想,因为该ALTER TABLE 'my_table' FORCE
命令锁定了表,这当然也会导致我们的应用程序停机 - 假定所需的表重建不太可能再次发生。实施自动重建,选择旧表的块并将它们插入新表,直到它们的内容匹配。然后删除旧表并将新表重命名为旧表的名称。这可行——但需要时间,并且每次需要重建表时都需要完成
- 将大表在逻辑上拆分为具有相同架构的不同表。如果数据访问模式不经常需要一次查询多个表,那么我可以将一次为重建完成的锁定限制为一个(较小的)表,而不是一次锁定重建大表
理想情况下,我希望能够再次打开自动次要版本升级,并且它在预先选择的窗口中以最短的停机时间“正常工作”。