文档里对SET LOG_RESTORE_SOURCE部分有这么句话
使用限制及注意事项
在级联备库场景中,可以将当前备租户的日志恢复源设置为主租户或其他备租户。例如,假设当前环境中,已有一个主租户 A 和一个备租户 B,新创建了一个备租户 C 后,您可以将备租户 C 的日志恢复源设置为主租户 A,也可以设置为备租户 B。
。。。略过
在将备租户的日志源从一种日志恢复源修改为另一种日志恢复源时,必须保证修改前后其日志恢复源与创建备租户时所指定的源租户一致,即要么使用源租户的日志归档,要么直接指向源租户。
请教各位大佬,这两句话应该如何理解,第一条说C的参数可以修改为A或者B,第三条说要求源租户一直,我测试的C租户,指向A或者B均是可以同步的,是只要是同一个主租户关联的主备租户都可以,不可以指向其他和这个主租户不相关的或者从这个主租户复制、failover出去生产的新的主租户?
论坛小助手
2025 年6 月 4 日 17:57
#5
根据文档库中的信息,以下是对您问题的详细解答:
关于 SET LOG_RESTORE_SOURCE
的理解
第一句话的理解
文档中提到:“在级联备库场景中,可以将当前备租户的日志恢复源设置为主租户或其他备租户。” 这意味着,在一个主租户 A 和其备租户 B 的环境中,如果新创建了一个备租户 C,那么 C 的日志恢复源既可以设置为 A(主租户),也可以设置为 B(备租户)。这是合理的,因为 B 本身是 A 的备租户,C 通过 B 获取日志间接等同于从 A 获取日志。
第二句话的理解
文档中还提到:“在将备租户的日志源从一种日志恢复源修改为另一种日志恢复源时,必须保证修改前后其日志恢复源与创建备租户时所指定的源租户一致。” 这意味着,无论备租户的日志恢复源如何切换,最终都必须指向最初创建备租户时指定的源租户或其直接关联的备租户。
综合理解
根据上述两点,可以得出以下结论:
在同一个主租户 A 的主备体系中,所有备租户(如 B 和 C)都可以相互作为日志恢复源,只要它们之间存在直接或间接的主备关系。
如果备租户 C 指向了与主租户 A 不相关的其他主租户(例如另一个独立的主租户 D),或者指向了从 A 复制、failover 出来的新的主租户(例如 E),这种情况下会违反“日志恢复源与创建备租户时所指定的源租户一致”的原则,因此是不允许的。
测试结果的解释
您提到测试中发现 C 租户可以指向 A 或 B 均可同步。这是因为 A 和 B 属于同一个主备体系,C 无论是直接从 A 获取日志还是通过 B 获取日志,都符合 OceanBase 的设计逻辑。但如果尝试让 C 指向与 A 不相关的其他主租户,则会导致同步失败。
总结
允许的情况 :在同一主租户 A 的主备体系中,备租户 C 的日志恢复源可以设置为主租户 A 或其直接关联的备租户 B。
不允许的情况 :备租户 C 的日志恢复源不能指向与主租户 A 不相关的其他主租户,或者从 A 复制、failover 出来的新的主租户。
如果您还有进一步的疑问,请提供更多具体场景或测试细节,我们将尽力为您解答!
具体信息可参考以下文档:
SET LOG_ARCHIVE_DEST
SET LOG_RESTORE_SOURCE
其他问题
Redo 日志
oceanbase.CDB_OB_LOG_RESTORE_SOURCE
oceanbase.DBA_OB_LOG_RESTORE_SOURCE
物理备库同步过程中卡住
RESTORE