oceanbase 物理备库删除租户时存在删除异常，指定 A 集群租户结果删除了 B集群租户

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】observer
【 使用版本 】4.3.5.1
【问题描述】我有两个集群：cluster_102166 和 cluster_10346。我在 102.166 机器上面执行了这个命令：obd cluster tenant drop cluster_102166 -t tenant --igs，但是 obd 把cluster_10346 上面的 tenant 租户删掉了，为什么？
我的操作：以 cluster_10346 上面 tenant 租户为主在 cluster_102166 上面建立了备租户 tenant；然后在cluster_102166 上执行了：
ALTER SYSTEM SET LOG_RESTORE_SOURCE = ‘’;ALTER SYSTEM ACTIVATE STANDBY;"
之后就是执行清理租户操作：
obd cluster tenant drop cluster_102166 -t tenant --igs
然后发现 cluster_10346 上面的 tenant 租户被删除了，cluster_102166 反而还存在。obd log 见附件

@论坛小助手
oceanbase_drop_tenant.log (16.5 KB)

1 个赞
#3

根因分析场景: [未能明确问题的场景]
根因分析命令: (无，因为当前 obdiag 工具未提供针对此问题的具体根因分析场景)
日志采集场景: 数据恢复问题
日志采集命令: obdiag gather scene run --scene=observer.recovery

推荐使用 obdiag 工具进行日志采集，并将采集到的日志提供给我们以便确认问题所在。上述命令会收集与数据恢复相关的日志信息，帮助我们分析误删主库租户的原因。

另外，为了更好地了解问题并提供解决方案，请您提供以下信息：

  1. 在执行 obd cluster tenant drop 命令时，是否确认了目标集群和租户名称？是否有任何提示或警告信息显示？
  2. 被误删的主库租户是否有备份？如果有，请提供备份的时间点及相关配置信息。
  3. 当前 OceanBase 集群的版本号是多少？可以通过 obd cluster display 查看。
  4. 是否有其他类似的误操作发生过？如果有，请描述相关情况。
  5. 是否可以提供完整的 obd cluster tenant drop 执行日志（包括输入参数和输出结果）？

请您根据以上建议执行日志采集命令，并将生成的日志压缩包上传或发送给我们，以便进一步分析问题原因并提供解决方案。

附上敏捷诊断工具 obdiag 使用帮助链接

#4

企业微信截图_6597df66-2aa1-46b5-a1b3-5312ca5408d2
企业微信截图_6597df66-2aa1-46b5-a1b3-5312ca5408d21604×534 98.8 KB

这是执行 alter system activate standby 之后查看 10346 的 inner_config.yaml

#5

根据您提供的信息和上传的图片内容，可以初步分析出问题的原因。以下是详细分析和解决方案：

问题分析

  1. 备租户与主租户的关系配置

    • 在 inner_config.yaml 文件中，可以看到以下配置：
      $_standby_relation:
  tenant :
    - - cluster_102166
      - tenant
      这表明在 cluster_10346 中，租户 tenant 被配置为主租户，并且其备租户位于 cluster_102166 的 tenant。

  2. 执行 ALTER SYSTEM ACTIVATE STANDBY 的影响

    • 当您在 cluster_102166 上执行了以下命令：
      ALTER SYSTEM SET LOG_RESTORE_SOURCE = '';
ALTER SYSTEM ACTIVATE STANDBY;
      这实际上将 cluster_102166 的备租户提升为主租户。
    • 提升备租户为主租户的操作会触发 OceanBase 数据库内部的主备切换逻辑，可能导致原主租户（即 cluster_10346 上的 tenant）被标记为不可用或被清理。

  3. obd cluster tenant drop 的行为

    • 您在 cluster_102166 上执行了以下命令：
      obd cluster tenant drop cluster_102166 -t tenant --igs
      该命令的目的是删除 cluster_102166 上的租户 tenant。
    • 然而，由于主备关系的存在，OceanBase 数据库可能会认为 cluster_10346 上的主租户也需要同步删除，从而导致误删。

问题原因总结

  • 主备关系未正确解除：在执行 ALTER SYSTEM ACTIVATE STANDBY 后，主备关系并未完全解除。此时直接删除备租户可能导致 OceanBase 数据库误删主租户。
  • obd 工具的行为：obd 工具在删除租户时，可能未充分考虑主备关系的状态，导致误删。

解决方案

步骤 1：确认当前主备关系状态

  • 在 cluster_10346 和 cluster_102166 上分别执行以下 SQL 查询，确认主备关系是否仍然存在：
    SELECT * FROM oceanbase.__all_tenant_standby;
    如果查询结果为空，则说明主备关系已解除；否则需要手动解除主备关系。

步骤 2：解除主备关系

  • 如果主备关系仍然存在，可以通过以下步骤解除：
    1. 在主租户（cluster_10346）上执行以下命令：
      ALTER SYSTEM SET LOG_RESTORE_SOURCE = '';
    2. 在备租户（cluster_102166）上执行以下命令：
      ALTER SYSTEM STOP REPLAY;

步骤 3：重新创建主备关系（可选）

  • 如果需要重新建立主备关系，可以按照以下步骤操作：
    1. 在主租户（cluster_10346）上设置日志恢复源：
      ALTER SYSTEM SET LOG_RESTORE_SOURCE = 'IP_LIST=172.36.102.166:2882;USER=standbyro@tenant;PASSWORD=your_password';
    2. 在备租户（cluster_102166）上启动日志回放：
      ALTER SYSTEM START REPLAY;

步骤 4：谨慎执行租户删除操作

  • 在确保主备关系已解除的情况下，再执行以下命令删除租户：
    obd cluster tenant drop cluster_102166 -t tenant --igs

预防措施

  1. 明确主备关系状态：在执行任何涉及主备切换或租户删除的操作前，务必确认主备关系的状态。
  2. 使用 obdiag 工具进行诊断：如前所述，可以使用 obdiag gather scene run --scene=observer.recovery 收集日志，以便更好地分析问题。
  3. 备份重要数据：在执行任何高风险操作前，建议对相关租户进行备份，以防止数据丢失。

如果您仍有疑问或需要进一步帮助，请提供以下信息：

  1. 执行 SELECT * FROM oceanbase.__all_tenant_standby; 的查询结果。
  2. 完整的 obd 日志文件。

希望以上解答能帮助您解决问题！

更多信息请查看:

  1. 修改集群配置项
  2. backup_storage_capacity_timeout_or_interrupted 备份恢复目录容量获取超时或线程被中断
  3. 使用 obd 部署主备租户
  4. 查询任务列表

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#6

4.3.5 没有 oceanbase.__all_tenant_standby; 这个表，应该改成什么呢？

#7

还有其他方法确定主备状态么？没有这个表

#8

@论坛小助手 还有其他建议么？

#9

根据您的反馈，oceanbase.__all_tenant_standby 表在 OceanBase 4.3.5 版本中确实不存在。因此，我们需要使用其他方法来确认主备关系的状态。以下是替代方法和建议：

方法 1：通过 DBA_OB_TENANTS 视图确认租户角色

可以查询 DBA_OB_TENANTS 视图中的 TENANT_ROLE 字段，确认租户的角色是 PRIMARY（主租户）还是 STANDBY（备租户）。具体步骤如下：

系统租户下查询：

SELECT TENANT_NAME, TENANT_ROLE FROM oceanbase.DBA_OB_TENANTS;

用户租户下查询：

  • MySQL 模式：
    SELECT TENANT_NAME, TENANT_ROLE FROM oceanbase.DBA_OB_TENANTS;
  • Oracle 模式：
    SELECT TENANT_NAME, TENANT_ROLE FROM SYS.DBA_OB_TENANTS;

如果查询结果显示某个租户的 TENANT_ROLE 为 STANDBY，则说明该租户仍处于备租户状态。

方法 2：检查 LOG_RESTORE_SOURCE 参数

可以通过查询 LOG_RESTORE_SOURCE 参数，确认备租户是否仍在从主租户同步日志。

查询命令：

SHOW PARAMETERS LIKE 'log_restore_source';

结果分析：

  • 如果返回值为空或为 ' '，说明备租户已停止从主租户同步日志。
  • 如果返回值包含主租户的信息（如 IP 地址、用户名等），说明备租户仍在同步日志。

方法 3：检查 inner_config.yaml 文件

您已经提供了 inner_config.yaml 文件的内容，其中的 $_standby_relation 配置项可以反映主备关系。例如：

$_standby_relation:
  tenant:
    - cluster_102166
    - tenant

如果该配置项仍然存在，则说明主备关系尚未解除。

方法 4：尝试手动解除主备关系

如果上述方法确认主备关系仍然存在，可以通过以下步骤手动解除主备关系：

步骤 1：在主租户上设置 LOG_RESTORE_SOURCE 为空

ALTER SYSTEM SET LOG_RESTORE_SOURCE = '';

步骤 2：在备租户上停止日志回放

ALTER SYSTEM STOP REPLAY;

步骤 3：更新 inner_config.yaml

编辑 inner_config.yaml 文件，删除 $_standby_relation 配置项。例如：

$_standby_relation: {}

保存文件后，重新加载配置：

obd cluster reload cluster_10346

方法 5：通过日志确认主备状态

如果以上方法仍无法明确主备状态，可以通过查看 Observer 日志进一步确认。重点关注以下关键字：

  • STANDBY ROLE
  • LOG_RESTORE_SOURCE
  • REPLAY STATUS

日志路径通常为：

${OB_HOME}/log/observer.log

总结

在 OceanBase 4.3.5 版本中，可以通过以下方法确认主备关系状态：

  1. 查询 DBA_OB_TENANTS 视图中的 TENANT_ROLE 字段。
  2. 检查 LOG_RESTORE_SOURCE 参数。
  3. 查看 inner_config.yaml 文件中的 $_standby_relation 配置。
  4. 手动解除主备关系并更新配置。
  5. 分析 Observer 日志以获取更多信息。

如果您仍有疑问，请提供以下信息以便进一步分析：

  • 查询 DBA_OB_TENANTS 的结果。
  • 查询 LOG_RESTORE_SOURCE 的结果。
  • inner_config.yaml 文件的完整内容。

希望以上解答能帮助您解决问题！

详情请参考:

  1. 物理备库同步过程中卡住
  2. 创建服务
  3. 物理备库
  4. ob_compatibility_version
  5. ob_security_version
  6. oceanbase.CDB_OB_DATABASES
  7. obshell 租户命令组
  8. Switchover 或 Failover 相关问题
  9. 负载均衡
  10. oceanbase.DBA_SEQUENCES