从 MySQL 迁到 OceanBase，lower_case_table_names 两端不一致还有救吗？建租户时设错了能改吗？

OceanBase 技术问题
,
#1

【使用版本】源端 MySQL 5.7，目标端 OceanBase 社区版 V4.2.x

【环境背景】
做 MySQL 到 OB 的迁移演练，迁移前置检查时发现源端 lower_case_table_names = 0（区分大小写），而目标租户创建时没注意这个参数。

【问题描述】

  1. OB 租户创建之后，lower_case_table_names 还能修改吗？如果源端是 0 而目标租户是 1，迁移后会出现什么具体现象？
  2. 如果租户已经建错了，是只能重建租户重新导，还是有别的补救方式？
  3. 迁移前的兼容性评估清单里，除了这个参数，还有哪些「租户创建时就必须定好、后面改不了」的项？
#3

@论坛小助手

#4

从 MySQL 迁移到 OceanBase 时处理 lower_case_table_names 参数不一致的问题

根据提供的文档信息，关于 lower_case_table_names 参数的设置及其对迁移的影响，有以下几点需要注意：

  1. OB 租户创建之后，lower_case_table_names 是否能修改？

    • 根据文档片段 2中的描述，“该变量仅支持使用 CREATE TENANT 语句创建租户时指定，租户创建后不能通过 SQL 语句修改”。因此，在租户已经创建完成后，无法直接修改此参数。

  2. 如果源端是 0（区分大小写）而目标租户是 1（不区分大小写），迁移后会出现什么具体现象？

    • 当源数据库和目标数据库对于表名或数据库名称的大小写敏感性不同，可能会导致在目标端出现名称冲突。例如，若在源端有两个不同的表名分别为 “User” 和 “user”，由于目标端将所有名字都转换为小写，这两个表的名字在目标端会变成相同的 “user”，从而引发命名冲突问题。这会导致数据迁移失败或者在应用运行过程中报错。

  3. 如果租户已经建错了，是否只能重建租户重新导，还是有别的补救方式？

    • 目前来看，针对已建立但配置错误（如 lower_case_table_names 参数设置不当）的租户，最佳做法确实是重新创建一个新的正确配置了所需参数值的租户，并重新进行数据迁移。尽管这不是最理想的解决方案，但它确保了新旧环境之间的一致性和避免后续可能发生的更多兼容性问题。

  4. 除了 lower_case_table_names 之外，迁移前需要特别注意哪些「租户创建时就必须定好、后面改不了」的项？

    • 依据现有资料没有明确列出其他所有不可更改的具体参数项目，但是可以确定的是与兼容模式相关的选择（即选择 MySQL 或者 Oracle 兼容模式）也属于这类一旦设定就无法再更改的配置。见文档片段 9中提到：“用户在创建租户时，可选择创建 MySQL 兼容模式的租户或 Oracle 兼容模式的租户，租户的兼容模式一经确定就无法更改。”
    • 除了上述内容外，其他关键性的初始设置也可能存在类似限制，建议查阅官方更详细的文档或联系技术支持以获取全面准确的信息。

综上所述，面对当前情况下的最佳实践应该是尽快基于正确的参数配置新建一个 OB 租户，并按照迁移流程重新执行数据迁移任务。同时，请务必提前仔细检查并确认所有涉及长期影响的重要参数选项。

检索到的文档如下:

  1. 使用 OMS 从 MySQL 数据库迁移数据到 OceanBase 数据库 MySQL 租户
  2. lower_case_table_names
  3. 有约束的列修改类型
  4. 使用 OMS 从 OceanBase 数据库 MySQL 租户迁移数据到 MySQL 数据库
  5. JDBC-Sink
  6. 使用 OMS 从 PostgreSQL 数据库迁移数据到 OceanBase 数据库 MySQL 租户
  7. 使用 MySQL 租户做常见数据库开发
  8. 兼容模式
  9. 迁移 MySQL 数据库的数据至 OceanBase 社区版