日志传输服务概述

物理备库通过日志传输服务在主租户和备租户之间实时同步 Redo 日志。特别地，主租户不会主动给备租户推送日志，仅依赖备租户从主租户拉取日志。

日志传输服务会自动寻址日志位置信息，并处理日志落后及主租户所在集群节点故障等高可用问题。备租户既可以通过主租户的日志归档来获取日志，也可以通过网络直连主租户所在的集群来获取日志。

日志传输服务提供了两种不同的使用模式，这两种使用模式决定了物理备库的两种不同的部署方案：基于日志归档的物理备库和基于网络的物理备库。

基于日志归档的物理备库

基于日志归档的物理备库中，物理备库的 Redo 日志来源于主租户或其他备租户的日志归档，类似于 Oracle 数据库的 Far Sync，备租户仅与日志归档交互，而不会和上游的主租户或备租户有任何其他形式的交互。

在该部署模式下，备租户与上游租户不需要网络联通，但其同步性能和可用性会受到日志归档介质的影响。

基于日志归档的物理备库模式的部署架构图如下所示。图中，Log Archive（日志归档）、Log Archive Dest（日志归档目的端） 以及 Log Restore（日志恢复） 共同构成了该部署模式下的日志传输服务。

基于网络的物理备库

基于网络的物理备库中，备租户直接通过网络连接主租户或其他备租户读取日志，类似于 MySQL 数据库的 Replication。

在该部署模式下，备租户和主租户的网络需要联通。备租户会通过网络发送 RPC 请求读取主租户集群中的 Redo 日志，同时为了支持在主租户节点故障、日志回收等场景下备租户的高可用，备租户也需要少量主租户系统视图的查询权限。

特别地，该部署模式下，备租户会向主租户的日志传输服务不断请求日志，日志传输服务返回的日志既可以是主租户的在线日志，也可以是主租户的归档日志（主租户开启了日志归档模式的场景下），两种日志来源支持自动切换，对备租户以及业务的使用者透明。

基于网络的物理备库模式的部署架构图如下所示。图中，Primary Tenant1 未开启日志归档，Standby Tenant1 仅能通过日志传输服务同步 Primary Tenant1 的在线日志；Primary Tenant2 开启了日志归档，Standby Tenant2 通过日志传输服务可以同步 Primary Tenant2 的在线日志，待在线日志回收后，日志传输服务会自动切换日志源到归档日志，备租户便能够通过日志传输服务继续同步 Primary Tenant2 的归档日志，从而尽可能保证日志同步不中断。

两种部署模式对比

基于日志归档的物理备库与基于网络的物理备库在功能的使用上会有一些差异，具体差异如下表所示。