Select a Cluster Strategy

You can select a high-availability (HA) strategy that uses either a multi-node cluster or a two-node cluster.

A two-node cluster has a single master with one replica database, as shown below:

The figure displays a two-node cluster that has a single master with one replica database.

A three-node cluster has a single master with two replica databases for a higher level of HA:

The following information describes the characteristics of a two-node or multi-node cluster:

Each host is running a backend server with an embedded-in-memory Berkeley XML database.
In the replicated group, there is only one master database and one or more replicas.
The master database is responsible for distribution of transactional modifications to other replicas in the cluster.
All back end server components interact with the database through a database proxy.
The database proxy determines if the request for service is a transactional modification or a request for data retrieval. All data retrievals are done on the local database irrespective if it is a replica or master database. Requests for transactional modifications (inserts, updates or deletes) are forwarded from the database proxy to the master database in the cluster.
The master database guarantees the transactions on a quorum basis in a cluster. This means that in a two-node cluster, one node must be up, in a three-node cluster two nodes must be up and so on. The majority of active members need to reply that they have received the replicated datasets before the master returns success on the transaction.
User transactional latency is accounted for by detection of the late arrival of replicated data. Best effort replication is provided, which can mean the call might return before the dataset appears on the replicated databases. The database transactional layer offers additional support with latency in replicated data.
For example, a user on Host 3 starts a local transaction with the database proxy to insert content into the database. The database proxy in turn starts a transaction with the master database on Host 1. Each transaction that is started with the master database has a transactional ID associated with it. The master database uses best effort in ensuring that the datasets are replicated to the other members of its replication group.

However, if the best effort time is exceeded and the master database has received replies from quorum (the other replicas); the master database returns success. Returning success guarantees replication will occur at some point. The database Proxy on host 3 waits until the required transactional ID appears in its local replicated database before returning success on the transaction to the user on Host 3. This guarantees that the content inserted on the Master database has reached the replicated database. Users that initiate transactions are guaranteed to see the outcome of those transactions in their local database independent of which host the original transaction was initiated.

Two Node Cluster Database Operations

Operation	Description
Server startup	When an Oracle Communications Session Delivery Manager server is started it joins the cluster as a replica and election is held if there is currently no master. If the member ends up as a replica, then it is synchronized with the master during the initialization phase of the database service startup. With the introduction of Oracle Communications Session Delivery Manager, Release 8.0, use the following steps to start an OCSDM server cluster: Select one server to start in the cluster only. Once the server you selected is started and operational, you can start the other server in the two-node cluster.
Master member failure	When the master fails the remaining replica becomes the new master.
Transactions (Quorum)	Transactions return successfully if a majority of the members in the cluster have replied that they received the replicated datasets. If quorum in replies from replicas is not achieved in a specific time period, the transaction fails.
Network partition	When the master fails the remaining replica becomes the new master.
Elections	An election can be won with a single vote. This allows the replica to be elected master in the case the master fails.
Recovery after a network partition	In a two node cluster it is possible for the network connection between the master and replica to be partitioned or become unresponsive due to network latency. In this situation an election is held and both nodes are elected and act as masters. While in this state, write transactions can occur at both sites. As a result, special handling is required after the partition is resolved and the system recovers from a two master configuration to a single master configuration: Before the partition is resolved both nodes are in the role of master. After the partition is resolved an election is automatically held to elect a master. When the election is complete the node that wins remains the master and the other will become the replica. The node that loses the election and becomes the replica tries to recover itself by restarting automatically if required if it had any write transactions that need to be rolled back to synchronize its database with the new master. Also, if the partition exists for more than 24 hours, Oracle recommends that you to take the cold backup from newly elected master and us it to restore the replica to avoid any data discrepancies.
Rejoining a cluster after graceful shutdown	An election can be won with a single vote. This allows the replica to be elected master in the case the master fails.
Rejoining cluster after shutdown for extended period	Perform a hot backup on the host running the master database before restarting a server that has been down for a long time. This avoids the potentially high cost synchronizing the server with the master during startup.

Multiple Node Cluster Database Operations

Operation	Description
Server startup	When an Oracle Communications Session Delivery Manager server is started it joins the cluster as a replica and an election is held if there is currently no master. If the member ends up as a replica, then it is synchronized with the master during the initialization phase of the database service startup. With the introduction of Oracle Communications Session Delivery Manager, Release 8.0, use the following steps to start an OCSDM server cluster: Select one server to start in the cluster only. Once the server you selected is started and operational, you can start the other server(s) in the cluster.
Master member failure	When the master fails or becomes partitioned from the rest of the members in the cluster, an election is automatically held by the remaining replicas to elect a new master.
Transactions (Quorum)	Transactions return successfully if a majority of the members in the cluster have replied that they received the replicated datasets. If quorum in replies from replicas is not achieved in a specific time period, the transaction fails.
Network partition	When a network partition exists between the members, only the members that can communicate with a majority of the members may elect a new master database. Members that can not communicate with a majority will enter READ-ONLY mode. Upon re-establishing network connectivity, re-elections take place and a master is elected while the other members revert to replicas.
Elections	In a cluster of three or more members, an election is won by the member with the simple majority of votes. The member that wins an election is always the one with the most recent log records. In the case of a tie, the member with the highest priority wins.
Rejoining cluster after shutdown for an extended period	If the server that needs to rejoin the cluster has been down for more than 24 hours, perform a hot backup on the host running the master database and restore the backup to the server that is down before restarting it. This avoids the potentially high cost synchronizing the server with the master during startup.