在高可用系统中使用超大表的技术

Question

我们在MySql InnoDB（v5.0.85）中有一个大约2000万条记录的大表。该表记录了用户操作的状态，并由多个应用服务器共享。偶尔会出现一个新要求，这意味着我们需要在此表中添加一个新列来存储其他信息。运行alter命令大约需要20分钟，在此期间应用程序无法执行其职责，因为表已被锁定 - 这对于我们的业务模型已不再可接受，因为应用程序需要尽可能保持可用状态，并且只需非常短暂的中断推送新的服务器代码。

我正在尝试寻找重新设计架构的方法，以便我们可以添加新列以支持新用例并同时保持应用程序在线。我们正在考虑引入一个归档过程来从表中删除旧记录，但预计它仍然非常大。

任何人都可以向我指出任何书籍，在线资源，或者仅仅是您自己在管理可用性，表格大小和不断变化的需求之间的平衡方面有什么用处和没有用过的经验？

谢谢！

Answer 1

你无法得到任何东西。几乎所有我能想到的添加新字段的解决方案都会导致一次性短暂中断或长期永久性性能问题但不会中断，或新设备和结构的成本更适合您的数据大小有。就个人而言，我发现短暂的一次性停电（在最繁忙时段发生）是最好的长期解决方案。

Answer 2

如果您需要定期添加新列，您应该找到一种技术，可以在加载时添加不需要更改表的新信息。

以下是一些可以想到的解决方案：

• 使用PropertyType / PropertyValue表，其中PropertyType是一个枚举，只要必须添加新信息，您就可以向其添加新条目。正如HLGEM所指出的，这种模式有缺点。 EAV允许非常动态的模型，但如果查询不是由专用层生成的话，则很难管理。

• 有一个完全规范化的架构，您可以为每个新信息创建一个新的独立表。

• 您没有说读/写统计信息，但如果可以使用20分钟的只读窗口，则可以使用复制的只读版本来处理更改期间的查询负载表

Answer 3

您应该能够使用新列创建扩展表。它与现有表格具有一对一的关系。 如果您愿意，稍后您可以将这些列作为更有计划的维护任务添加到主表中。

Answer 4

如何使用两种不同的数据库服务器设置，其中1个集群将被删除，更改然后重新获取并复制到新模式。当源缺少新列时，刚添加的列可能适用于常规复制。当它再次更新时，将所有流量切换到新群集，更改被动群集并开始复制回到该群集。

相当多的工作，但对于0停机时间一切都不容易。