Overview

The log transmission service synchronizes redo logs between the primary and standby tenants in real time for the physical standby database solution. Specifically, the primary tenant does not actively push logs to the standby tenant. Instead, the standby tenant pulls logs from the primary tenant.

The log transmission service automatically addresses the log location and handles high availability issues such as log lag and node failure in the cluster where the primary tenant is located. The standby tenant can obtain logs either through log archiving from the primary tenant or by directly connecting to the cluster where the primary tenant is located.

The log transmission service provides two different usage modes, which determine the deployment approach for the physical standby database: log archiving-based and network-based.

Log archiving-based physical standby database

In the log archiving-based physical standby database, the redo logs of the standby tenant come from log archiving of the primary tenant or other standby tenants, similar to Oracle database's Far Sync. The standby tenant only interacts with log archiving and does not have any other form of interaction with the upstream primary tenant or other standby tenants.

In this deployment mode, the standby tenant does not require network connectivity with the upstream tenant, but its synchronization performance and availability are affected by the log archiving medium.

The following figure shows the deployment architecture of the log archiving-based physical standby database. In this figure, Log Archive, Log Archive Dest, and Log Restore collectively form the log transmission service in this deployment mode.

Network-based physical standby database

In the network-based physical standby database, the standby tenant directly reads logs from the primary tenant or other standby tenants through a network connection, similar to MySQL database's replication.

In this deployment mode, there is a need for network connectivity between the primary and standby tenants. The standby tenant sends RPC requests over the network to read redo logs from the cluster where the primary tenant is located. Additionally, to support high availability of the standby tenant in scenarios such as primary tenant node failures or log recycling, the standby tenant must have the privilege to query some system views of the primary tenant.

In this deployment mode, the logs read by the standby tenant from the primary tenant can be either online logs or archived logs (provided the primary tenant has enabled log archiving). The two sources of logs support automatic switching without affecting the standby tenant or the business users.

The following figure shows the deployment architecture of the network-based physical standby database. In this figure, Primary Tenant 1 does not have log archiving enabled, and Standby Tenant 1 synchronizes only the online logs of Primary Tenant 1 over the network; Primary Tenant 2 has log archiving enabled, and Standby Tenant 2 can synchronize either the online logs of Primary Tenant 2 or switch to synchronizing the archived logs of Primary Tenant 2 after the online logs are recycled.

Comparison between the two deployment modes

The log archiving-based physical standby database and the network-based physical standby database have some differences in terms of feature usage, as shown in the following table.