Tibero Standby Cluster provides high availability, data protection, and disaster recovery as a core function of Tibero.

A Tibero standby server maintains copies of source data with a transaction unit in a physically independent location. The database that has the source data is called the Primary DB (hereafter Primary) and a database where the copied data is saved is called a Standby DB (hereafter Standby).

A background process transmits the Redo logs created by Primary to Standby databases, and each Standby uses the Redo logs to apply all changes of Primary to itself.

The following figure shows how Tibero Standby Cluster operates:

[Figure 8.1] Tibero Standby Cluster's Operation

When the Primary fails to handle data that was requested by a service, Tibero uses Standby databases to quickly restart the service. Even if one of the Primary's disks is damaged and it is difficult to recover, Tibero protects the corrupted data with Standby databases.

Tibero Standby Cluster has the following processes:

Log transmission from Primary to Standby databases is performed as follows:

Primary's operation modes are as follows:

Primary's operation mode, Standby databases that will connect to Primary, and the log transmission method for each Standby can be specified with the following file:

<$TB_SID.tip>

LOG_REPLICATION_MODE   = {PROTECTION|AVAILABILITY|PERFORMANCE}
LOG_REPLICATION_DEST_1 = "hostname_1:port_1 {LGWR SYNC|LGWR ASYNC|ARCH ASYNC}"
LOG_REPLICATION_DEST_2 = "hostname_2:port_2 {LGWR SYNC|LGWR ASYNC|ARCH ASYNC}"
...
LOG_REPLICATION_DEST_N = "hostname_N:port_N {LGWR SYNC|LGWR ASYNC|ARCH ASYNC}"

The initialization parameters specified in the above file are as follows:

When Primary starts in NORMAL mode, it connects to each Standby specified in $TB_SID.tip, and data replication is automatically performed by a background process. For example, if Primary starts in PROTECTION or AVAILABILITY mode and no Standby that was specified with LGWR SYNC can be connected to, Standby databases must be started first because Primary cannot function. In other situations, Primary can start even though each Standby starts later as they connect automatically.

The followings tasks should be completed to operate a Standby:

SQL> alter database open read only continue recovery;

SQL> ALTER DATABASE Standby;

The Standby is operable even when the Primary is TAC, not single. The following is the procedure for configuring TAC-TSC.

In TAC-TSC configuration, if there is a node stopped on the Primary side, the Standby node will not receive the node's redo log and will not be able to recover normally.

By enabling below parameter on the Primary, another node of the Primary sends the redo log on behalf of the stopped node and perform the recovery normally. These parameters are required to continue synchronization even if part of the Primary node is down.

<$TB_SID.tip>

STANDBY_ENABLE_LOG_RECOVERY=Y

The method of sending logs from shut-down nodes instead is called LGWR PROXY. If the Primary is activated by applying the above parameters, LNWs will be allocated as many nodes as LGWR PROXY LNW, excluding its own node. Up to 9 LNWs can be used in a single node. In 2-node TAC-TSC configuration, 8 LGWR PROXY LNWs are created and one of them are allocated. If one of the nodes is shut down, the other node changes the status of the LGWR PROXY LNW for the shut-down node to CONNECTED, and sends the log of the shut-down node instead.

SQL> select * from v$standby_dest;
STANDBY_ADDR
--------------------------------------------------------------------------------
TYPE                THREAD# FLAGS                              SENT_SEQ
---------------- ---------- -------------------------------- ----------
SENT_BLKNO  ACKED_SEQ ACKED_BLKNO      DELAY
---------- ---------- ----------- ----------
127.0.0.1:11004
LGWR ASYNC                0 CONNECTED                                11
       894         11         894          0

127.0.0.1:11004
LGWR PROXY                1 CONNECTED                                 7
       880          7         880          0

Not Assigned:0
LGWR PROXY            65535 NOT CONNECTED                            -1
        -1         -1          -1          0

(omitted)

Not Assigned:0
LGWR PROXY            65535 NOT CONNECTED                            -1
        -1         -1          -1          0


9 rows selected.

When using the above parameter, if the log transmission method is ASYNC mode, it may be necessary to read the archive log of the shut-down node instead. To do this, LOG_ARCHIVE_DEST on each primary node must be identical, which is impossible in a typical shared disk environment. TAS-TAC-TSC configuration options; cold backup with TASCMD's cptolocal and cpfromlocal commands, hot backup with tbrmgr's --for-standby option.

There are two scenarios in which a Standby can become Primary.

To access both Primary and Standby, specify the access information of each DB in the tbdsn.tbr file as shown below:

<tbdsn.tbr>

PrimaryDB_SID=(
               (INSTANCE=(HOST=primaryDB_hostname)
                         (PORT=primaryDB_port)
                         (DB_NAME=cluster_DB_NAME)
               )
)

StandbyDB_SID=(
               (INSTANCE=(HOST=StandbyDB_hostname)
                         (PORT=StandbyDB_port)
                         (DB_NAME=cluster_DB_NAME)
               )
)

For each SID, write the DB_NAME that was used when configuring the $TB_SID.tip file for Primary and each Standby.

A standby Redo log group is an online log group that can be used only for standby databases. When log switch occurs, checkpoints of logs to reuse are not checked, and only whether to archive the logs is checked.

Restore a backup set, and then perform the following to use standby Redo log groups.

Tibero provides the dynamic views shown below to view the data about a Tibero Standby Cluster's status.

Because Tibero Standby Cluster transfers Redo logs created by Primary to Standby databases without any changes, the system environment, such as the CPU bus size, endianness, OS, and the size of database blocks in the $TB_SID.tip files in Primary and the Standby must be the same.

As a property of a Standby Cluster that applies Redo logs, some DDL that modify the state of a tablespace or database file are not allowed. These operations must be performed without Standby. In other words, a database must be backed up before applying it to Standby.

The following operations are not supported by Standby clusters. DPL and DPI are not supported in previous versions because they do not leave logs, but now they are supported because they leave logs when connecting to Standby.