RDS/Aurora MySQL8.0 跨区域复制问题的分析与解决
内容提要
本文讨论了Amazon Aurora Mysql 8.0中与lower_case_table_names参数相关的小问题。分析、测试并提供了解决方案。结论是Aurora Mysql 8.0在集群创建后不允许修改lower_case_table_names参数，这在创建跨区域副本时会引起问题。解决方案是使用AWS CLI创建副本并指定所需的参数组。
延伸解读
版本差异：5.7 与 8.0 的参数修改权限
文章测试表明，Aurora MySQL 5.7 允许修改 lower_case_table_names 参数，而 Aurora MySQL 8.0 在集群创建后无法修改。官方文档也确认，在 Aurora MySQL 版本 3（8.0）中，该参数值在创建集群时永久设置。这意味着从 5.7 升级到 8.0 时，如果原集群参数为 1，升级后可能无法调整，为后续跨区域复制等操作埋下隐患。
控制台创建副本的隐藏限制
文章指出，通过控制台创建 Aurora MySQL 8.0 的跨区域副本时，副本集群只能使用默认参数组，而默认参数组中 lower_case_table_names=0。如果主集群该参数为 1，就会因参数不匹配导致创建失败。控制台没有提供指定副本参数组的选项，这是问题的直接原因。
AWS CLI 作为解决方案的关键点
解决方案是使用 AWS CLI 创建跨区域副本，并通过 --db-cluster-parameter-group-name 参数指定预先创建好的、lower_case_table_names=1 的参数组。文章还提醒，--engine 参数在 Aurora MySQL 5.7 及之后应为 aurora-mysql，加密集群需提供目标区域的 KMS Key ID，这些细节对成功创建至关重要。
RDS MySQL 8.0 的类似问题与差异
文章测试发现，RDS MySQL 8.0 也存在 lower_case_table_names 创建后不可修改的问题。当该参数为 1 时，控制台创建跨区域副本会在恢复数据阶段失败，报错提示服务器与数据字典设置不一致。但区域副本创建成功，因为其复用主库参数。解决方案同样是通过 AWS CLI 指定参数组。
Q&A
为什么 Aurora MySQL 8.0 创建跨区域副本时会报 lower_case_table_names 参数错误？
因为 Aurora MySQL 8.0 的跨区域副本默认使用默认参数组，其 lower_case_table_names 值为 0，而主集群该参数值为 1。MySQL 8.0 及以上版本要求主集群与副本的 lower_case_table_names 值必须一致，因此创建失败。
Aurora MySQL 8.0 和 5.7 在修改 lower_case_table_names 参数上有什么不同？
Aurora MySQL 5.7 可以在集群创建后修改 lower_case_table_names 参数；而 Aurora MySQL 8.0 在集群创建后无法修改该参数，其值在创建集群时永久设定。
如何解决 Aurora MySQL 8.0 无法创建跨区域副本的问题？
使用 AWS CLI 创建跨区域副本，并在命令中通过 --db-cluster-parameter-group-name 参数指定一个预先创建好的、lower_case_table_names=1 的自定义参数组。
使用 AWS CLI 创建 Aurora MySQL 8.0 跨区域副本时需要注意哪些参数？
需要在目标区域执行命令；--engine 参数应使用 aurora-mysql（5.7 之后）；如果主集群加密，需指定目标区域的 KMS Key ID；必须通过 --db-cluster-parameter-group-name 指定 lower_case_table_names=1 的参数组。
RDS MySQL 8.0 是否也存在 lower_case_table_names 相关问题？如何解决？
是的，RDS MySQL 8.0 也存在类似问题：创建后不可修改 lower_case_table_names，且控制台创建跨区域副本会失败。解决方案同样是使用 AWS CLI 创建副本，并指定包含正确 lower_case_table_names 值的参数组。
创建跨区域副本时，如果主集群是加密的，需要注意什么？
如果主集群是加密的，创建副本时必须使用 --kms-key-id 参数指定目标区域的 KMS Key ID，否则会报错提示不支持从加密集群复制到未加密集群。
