用最少的停机时间将中型数据库从一个字符集转换为另一个字符集
我们公司(小企业)最近在APAC地区开始了新业务，这要求我们支持我们的MySQL 5.7DB中的4位字符。
这种要求意味着我们需要将数据库从一个字符集转换为另一个字符集。
数据库表的大小从几行到100 to不等。有些有很多外键和索引。有一个或两个奇怪的存储过程，但这一方面是可以计算的。
我们可以安排停工时间。
我们在AWS RDS中运行，为了获得最佳的转换时间，我们决定拍摄一个快照，转到最大的容量实例，我们可以使用最多的IO。这就像r5.24xsize或50,000 IOPS之类的东西。
不幸的是，当我们测试它时，使用ALTER集字符集转换每个表需要超过8-12个小时。
虽然我们可以安排停机时间，但我们不能因为这段时间而感到沮丧。4小时可能超出了企业认为可以接受的范围。
我们已经开始从几个表中删除旧数据，但这还远远不够。
这里的主要瓶颈是RDS磁盘吞吐量峰值在350 DB /S，无论我们一次运行多少表转换、DB的大小、存储分配还是提供的IOPS。实际上，IOPS从未达到50K，CPU/内存也很少。磁盘队列达到大约10个，我认为这是由于吞吐量的限制。
我们也尝试了Aurora，这实际上对我们的案件来说比较慢。
有没有人知道我们如何进一步提高吞吐量或减少进行此转换所需的时间？
回答 1
Server Fault用户
发布于 2022-07-28 04:13:25
如果您正在使用一个足够新的MySQL版本，并且在任何PRIMARY KEY中都不需要utf8mb4，那么下面的操作可能会有效。(请先对大型桌子进行彻底测试)
每一表：
- 添加与现有utf8列相似的VARCHAR/TEXT列(S)，但使用utf8mb4和适当的排序规则。
- 当新数据进入时，为任何VARCHAR/TEXT列添加一个触发器来执行以下步骤。
- 在表上运行更新，将新列(S)设置为旧列。
稍后，在升级了所有表之后：
- 更改任何涉及列的索引
- 放下旧专栏(S)。
这一机制存在一些潜在的严重问题：
- 不同字符集的JOIN...ON不能使用索引。
- 我不能肯定，如果没有一些无法访问表的重要时刻，这一机制是否能发挥作用。
- 可能还有其他的事情。
pt --在线模式--更改--一次可能会更改一个表，从而导致上述问题。
基于语句的复制(在RDS中可能不可用？)可以提供一种方法来转换副本、继续复制以及(在方便的情况下)故障转移。
https://serverfault.com/questions/1106705
复制相似问题
腾讯云开发者
