Considerations and limitations|V3.2.4|OceanBase Database| docs|Distributed Database

Considerations and limitations

Last Updated：2023-10-27 09:57:43 Updated

This topic describes the usage notes and limitations on the primary/standby cluster configuration.

Considerations

A standby cluster is not allowed to trigger major freezes.

A standby cluster synchronizes major freeze information from the primary cluster. Only the primary cluster can initiate major freezes. The standby cluster schedules major compactions based on the major freeze information of the primary cluster. However, a standby cluster can trigger minor freezes independent of the primary cluster.

If the major freeze information of the standby cluster is out-of-sync, system tenant synchronization of the standby cluster may get stuck.
The synchronization latency of a standby cluster cannot be too high.

If the standby cluster is severely out of sync, it internally performs a rebuild operation to pull full data from the primary cluster, and then starts to synchronize logs from the latest log point. This process results in voids in the internal multiversion data, which further causes failover failure and read failure for the standby cluster. The services can be recovered after data is synchronized from the primary cluster to the standby cluster.

To ensure that a lossy failover can succeed after a rebuild operation is performed on the standby cluster, you can set the undo_retention variable for each normal tenant of the primary cluster to specify the retention period of the multiversion data. For more information about the undo_retention variable, see undo_retention.

For example, you can execute the following statement under a normal tenant of the primary cluster to set undo_retention to 1800. This way, a failover can succeed provided that the synchronization latency of the standby cluster is within 1800s, regardless of whether a rebuild operation is performed.
```
obclient> SET GLOBAL undo_retention = 1800;
```

Limitations

Item	Limitation
Cluster-level synchronization	Data is synchronized from the primary cluster to standby clusters by cluster.
Tenant-level synchronization	Data cannot be synchronized from the primary cluster to standby clusters by tenant.
Maximum number of standby clusters	31
Maximum number of DDL statements for the sys tenant of a standby cluster	Less than 500 per second
Synchronization of parameters	Modifications to parameters in the primary cluster are not synchronized to standby clusters.
Synchronization of system variables of user tenants	Modifications to regular system variables in the primary cluster are synchronized to standby clusters.
Table- or database-level Locality and Primary Zone settings in the primary cluster	Not supported
Tenant-level locality and primary zone settings in the primary cluster	Supported
Replica types	Full-featured, log-only, read-only, and encrypted voting replicas are supported. Hybrid deployment of replicas cannot be configured in Locality.
Upgrade mode	Rolling upgrades are supported starting from OceanBase Database V2.2.60.
GTS	GTS must be enabled for all user tenants.
One-phase commits of distributed transactions	`enable_one_phase_commit` must be set to False for the primary and standby clusters.
Schema objects	Tables can be copied, but Locality cannot be set for tables.
Adding a standby cluster	After an upgrade, a standby cluster can be added only after a major compaction is performed. The standby cluster must be empty. The primary cluster must not contain tables that are being split. The primary cluster can contain only Locality and Primary Zone configurations of tenants. The primary cluster must not be upgrading.* The OBServer version of the standby cluster must be the same as that of the primary cluster. Deleted schema replicas are all garbage-collected. GTS must be enabled for all user tenants. `enable_one_phase_commit` must be set to False for the primary cluster.
Standby cluster operations	DML operations, explicit activation of transactions, `SELECT FOR UPDATE`, and DDL operations on the standby cluster are not allowed.
Switchover	All OBServer nodes in the primary and standby clusters must be online. No major compaction error is allowed. If write is stopped during a switchover, the original primary cluster returns a `4688` error or a timeout error. If the switchover duration exceeds the value of `max_stale_time_for_weak_consistency`, which is 5s by default, the standby cluster stops the weak-consistency read service. `enable_rereplication` must be set to True for the standby cluster. Otherwise, the switchover cannot be performed. When one primary cluster and multiple standby clusters are configured, all standby clusters, except those in `DISABLED` state, must be active. The primary and standby clusters must be of the same version. The primary cluster must not be undergoing a physical backup operation. No replica in the Restore state is allowed. In MAXIMUM PROTECTION mode, the log transfer mode of the primary cluster must be `SYNC`. The primary cluster must not be upgrading.
Failover	Failovers are supported in MAXIMUM PERFORMANCE mode. Failovers are supported in MAXIMUM PROTECTION mode. Failovers are supported in MAXIMUM AVAILABILITY mode. A lossy failover requires that all OBServer nodes be active. After a failover, a standby cluster can be added only after a major compaction is performed.
Protection mode	The MAXIMUM PERFORMANCE, MAXIMUM PROTECTION, and MAXIMUM AVAILABILITY modes are supported. The configurations of standby clusters in MAXIMUM PROTECTION or MAXIMUM AVAILABILITY mode are subject to the following limitations: You have one standby cluster in `SYNC` mode. The standby cluster in `SYNC` mode cannot be modified, deleted, or disabled. The log transfer mode of the standby cluster in `SYNC` mode must not be changed to `ASYNC`. Switchovers in MAXIMUM PROTECTION or MAXIMUM AVAILABILITY mode are subject to the following limitations: Only the standby cluster in `SYNC` mode can be switched to the primary role. The log transfer mode of the primary cluster must be set to `SYNC` to ensure that it is in MAXIMUM PROTECTION mode after a primary/standby switchover.
Physical backup and restore	When standby clusters exist, the primary cluster cannot be restored. Standby clusters do not support backup and log archiving. Standby clusters cannot be physically restored. After a tenant is physically restored in the primary cluster, a standby cluster can be added only after a major compaction is performed.
Disconnecting a standby cluster	The role of the standby cluster is `PHYSICAL STANDBY`. All OBServer nodes in the standby cluster are active. The primary cluster must not be upgrading. You can execute the disconnection statement for the following switchover states: `NOT ALLOWED`, `TO PRIMARY`, and `DISCONNECT`.