obcdc supports synchronous standby databases

Background

Since obcdc started providing services, it has only supported synchronizing data from the primary database. However, there is a need for customers to consume data from standby databases. Specifically:

• There is a need to consume data from local databases: Applications and databases that consume obcdc data are located in different regions, and businesses prefer to consume incremental transaction data from local standby databases.

• Data consumption capability after primary-standby switch: obcdc can only synchronize data from the primary database, and a single obcdc instance can only synchronize data from one cluster. If the primary and standby databases are not in the same cluster and a primary-standby switch occurs, the data link will be interrupted.

• Although obcdc has a minimal impact on the primary database, some customers still prefer to synchronize data from standby databases to reduce potential impacts on the primary database.

To address these issues, obcdc now provides the capability to directly consume data from standby databases.

Feature description

In online mode, you must configure the tb_white_list parameter to add the current tenant name of the tenant to be synchronized to the synchronization allowlist. In offline mode (where refresh_mode=data_dict and archive_dest are configured), this is not required.

The following restrictions apply to the start point:

• At startup, the source tenant of obcdc must be in the NORMAL state.

• At the start point, the source tenant of obcdc must be in the NORMAL state.

• The start point cannot be less than or equal to the tenant's RESTORE_SCN (the user-specified restore point, which can be queried from the CDB_OB_RESTORE_HISTORY view).

• The start point cannot be greater than RECOVERY_UNTIL_SCN (the maximum recovery point of the current tenant, which can be queried from the DBA_OB_TENANTS view).

• If the start point is greater than the tenant's REPLAYABLE_SCN (the snapshot version that can be replayed by the current tenant, which can be queried from the DBA_OB_TENANTS view), the process will retry until the tenant's REPLAYABLE_SCN is greater than the start point. If the retry times are exceeded, the process will exit.

• If the start point is greater than READABLE_SCN (the snapshot version that can be read by the current tenant, which can be queried from the DBA_OB_TENANTS view), the process will retry until the tenant's READABLE_SCN is greater than the start point. If the retry times are exceeded, the process will exit.

• In dictionary mode, the system retrieves the generation time of the most recent baseline (SNAPSHOT_SCN) by querying the CDB_OB_DATA_DICTIONARY_IN_LOG view from the sys tenant or the DBA_OB_DATA_DICTIONARY_IN_LOG view from a user tenant. The retrieved SNAPSHOT_SCN must also meet all the constraints for the starting point, otherwise, the process will exit.

• If the starting point is within a transaction, obcdc needs to pull back all clog logs of the transaction before the starting point. The earliest clog log of the transaction must also meet all the constraints mentioned above.

Frequently Asked Questions

This section lists common issues related to the OBCDC synchronization standby database feature. General issues of OBCDC are not covered here.

OBCDC fails to start and exits

Key phenomena:

• The OBCDC process exits, and the key log init obcdc succ indicating a successful start is not found in the OBCDC logs.

• One of the following key logs is present:

  • The key log [ADD_TENANT][FAIL][clog_NOT_SERVE] indicating that the clog log at the start point is not available.

  • The key log [ADD_TENANT][FAIL][NOT_READABLE] indicating that the log at the start point is not readable.

  • The key log [ADD_TENANT][DATA_DICT][REFRESH_BASELINE][FAIL][clog_NOT_SERVE][LOG_AT_DICT_SNAPSHOT] indicating that the SNAPSHOT_SCN of the data dictionary is not within the service range.

Cause: The start point of OBCDC does not meet the constraints mentioned in the Features section.

Solution: Adjust the start point to meet the constraints, or switch to synchronizing data from the primary database.

OBCDC starts successfully but exits after running for a while

Key phenomena:

• OBCDC initializes successfully, as indicated by the key log init obcdc succ in the OBCDC logs or the periodic refresh of the HEARTBEAT keyword in the TLOG.COMMITTER module when the logs are not recycled.

• The key log [MISS_LOG][HANDLE_DONE] is present, and the subsequent ret value is not OB_SUCCESS.

Cause: The start point is in the middle of a long transaction. OBCDC needs to roll back this transaction. If the log positions of the earlier logs in this transaction are earlier than RESTORE_SCN, OBCDC will not be able to obtain these logs and will exit after a period of retries.

Solution: Reset (move forward) the start point, or switch to synchronizing data from the primary database.