Overview

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

The log transfer 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 archived logs from the primary tenant or connect to the cluster where the primary tenant resides to obtain logs.

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

Physical Standby Database solution based on log archiving

In the Physical Standby Database solution based on log archiving, redo logs of the standby tenants are sourced from archived 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 archived 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 Physical Standby Database solution based on log archiving. Log Archive, Log Archive Dest, and Log Restore constitute the log transfer service in this deployment mode.

Network-based Physical Standby Database solution

In the network-based Physical Standby Database solution, a standby tenant connects to a 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 an 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 read online logs from the primary tenant, or archived logs from the primary tenant if archivelog is enabled for 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. Archivelog is not enabled for Primary Tenant 1. Standby Tenant 1 synchronizes only online logs from Primary Tenant 1 over the network. Archivelog is enabled for Primary Tenant 2. Standby Tenant 2 can synchronize online logs from Primary Tenant 2 or, after online logs of the primary tenant are recycled, automatically switch to synchronizing archived logs from Primary Tenant 2.

Comparison between two deployment modes

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