Overview

The log transmission service synchronizes redo logs between the primary and standby tenants in real time for the Physical Standby Database solution. The primary tenant does not push logs to the standby tenants. Instead, the standby tenants pull logs from the primary tenant.

The log transmission service automatically addresses log locations and handles high availability issues such as log lagging and node failures in the cluster where the primary tenant resides. The standby tenants can obtain archive logs from the primary tenant or connect to the cluster where the primary tenant resides to obtain logs.

The log transmission service works in two ways. This allows you to deploy the Physical Standby Database solution in two modes: archive-based and network-based.

Archive-based Physical Standby Database solution

In the archive-based Physical Standby Database solution, redo logs of a standby tenant are sourced from archive logs of the primary tenant or other standby tenants. This is similar to the Far Sync feature of an Oracle database. The standby tenant only synchronizes archive logs, but does not interact with the upstream primary tenant or standby tenants in any other forms.

In this deployment mode, the standby tenant is not connected to upstream tenants, but the synchronization performance and availability of the standby tenant are affected by the log archiving medium.

The following figure shows the deployment architecture of the archive-based Physical Standby Database solution. Log Archive, Log Archive Dest, and Log Restore constitute the log transmission service in this deployment mode.

Network-based Physical Standby Database solution

In the network-based Physical Standby Database solution, a standby tenant connects to the primary tenant or other standby tenants to read logs. This is similar to the replication feature of a MySQL database.

In this deployment mode, the standby tenant must connect to the primary tenant. The standby tenant sends a remote procedure call (RPC) request over the network to read redo logs from the cluster where the primary tenant resides. To support high availability of the standby tenant upon node failures or log recycling of the primary tenant, the standby tenant must have a privilege to query some system views of the primary tenant.

In this deployment mode, the standby tenant can continuously request logs from the log transmission service of the primary tenant, and the log transmission service returns online logs or archive logs (if log archiving is enabled) of the primary tenant. The two log sources support automatic switching without affecting the standby tenant or business users.

The following figure shows the deployment architecture of the network-based Physical Standby Database solution. Log archiving is not enabled for Primary Tenant 1, and Standby Tenant 1 can synchronize only online logs from Primary Tenant 1 through the log transmission service. Log archiving is enabled for Primary Tenant 2, and Standby Tenant 2 can synchronize both online logs and archive logs from Primary Tenant 2 through the log transmission service. After online logs are recycled, the log transmission service automatically switches the log source to archive logs. This way, Standby Tenant 2 can continue to synchronize archive logs from Primary Tenant 2 through the log transmission service, thus ensuring continuity of log synchronization.

Comparison between the two deployment modes

The following table describes the differences between the archive-based Physical Standby Database solution and the network-based Physical Standby Database solution.