OB的物理备库：
1 日志传输服务只存在于主库段？ 备库端没有日志传输服务？
2 日志传输服务仅存在于 基于网络的物理备库 的主库端 ？
在OceanBase的物理备库架构中，日志传输服务并非只存在于主库端，其逻辑实现主要体现在备库端主动拉取日志的行为上。以下是详细分析：
1. 日志传输服务的工作机制
-
备库端主导日志拉取
物理备库通过日志传输服务在主租户和备租户之间实时同步 Redo 日志。关键点是：主租户不会主动向备租户推送日志，而是完全依赖备租户从主租户拉取日志。这表明日志传输的核心控制逻辑位于备库端 物理备库。 -
自动处理高可用问题
日志传输服务具备自动寻址日志位置、处理日志落后（lagging）、应对主租户所在集群节点故障等能力，这些功能由备租户侧的服务组件负责协调完成 日志传输服务概述。
2. 日志传输的两种部署模式
日志传输服务支持两种使用模式，对应不同的物理备库部署方案：
（1）基于网络的物理备库
- 备租户通过网络直接连接主租户所在的集群，发送 RPC 请求读取 Redo 日志。
- 要求主备之间的网络联通。
- 备租户需要具备查询主租户系统视图的权限，以支持故障切换等高可用场景 日志传输服务概述。
（2）基于日志归档的物理备库
- 备租户从主租户或其他备租户的日志归档中获取 Redo 日志。
- 不与主租户进行实时网络交互，类似于 Oracle 的 Far Sync 架构。
- 适用于跨地域、弱网络连接或异步容灾场景 日志传输服务概述。
3. 是否仅存在于基于网络的物理备库的主库端？
答案是否定的，原因如下：
- 主库端无“推送”服务：主库并不运行专门的日志传输“服务”来推送日志；它只是作为日志的提供方，响应备库的拉取请求。
- 服务主体在备库端：无论是基于网络还是基于归档的模式，日志拉取、恢复进度管理、断点续传、故障重试等行为均由备库端驱动。
- 因此，日志传输服务本质上是一个运行在备库侧的客户端角色服务，而非主库端的服务进程。
结论
| 问题 | 回答 |
|---|---|
| 日志传输服务是否只存在于主库端？ |
 否，核心服务逻辑运行在备库端，主库仅作为日志源响应请求。 |
| 备库端是否存在日志传输服务？ |
 是，备库负责发起日志拉取并处理同步过程中的各类异常。 |
| 是否仅存在于基于网络的物理备库的主库端？ |
否，该说法不成立。即使在基于网络的模式下，也没有主库端的“日志传输服务”存在，且该模式下的拉取行为仍由备库驱动。 |
更多信息可参考：物理备库 - OceanBase 官方文档
1 个赞
AI不靠谱 。 你多问几次，把AI都问糊涂了，他就会乱说了。
官文：
特别地，该部署模式下，备租户会向主租户的日志传输服务不断请求日志，日志传输服务返回的日志既可以是主租户的在线日志，也可以是主租户的归档日志（主租户开启了日志归档模式的场景下），两种日志来源支持自动切换，对备租户以及业务的使用者透明。
1 个赞
我记得我们之前和企业版技术支持沟通过，这个不是从主拉取得，不然主的压力太大了。
不过我们是企业版3.2.3，只有1种同步模式，网络模式，没有备份日志的方式。但是逻辑上应该没啥大问题的
- 日志传输服务主要存在于主库端，备库端没有日志传输服务。主租户不会主动给备租户推送日志，而是备租户通过网络连接主租户来拉取日志。
- 日志传输服务不仅存在于基于网络的物理备库的主库端，也存在于基于日志归档的物理备库中。但在基于日志归档的物理备库中，备租户通过日志归档来获取日志，而不是直接从主租户拉取。
检索到的文档如下: