In some circumstances, both servers can be in the PRIMARY ALONE state. Having dual primaries can lead to serious, unrecoverable errors.

In the dual primary situation, if each server commits any transactions that the other does not, you cannot resynchronize the servers, because the databases cannot be merged to create a single database that has correct information. In practice, the transactions committed in the “wrong primary” database during the dual primary situation, will be lost. Having dual primaries can also lead to other errors.

The dual primaries problem is most likely to be caused by a network partition. In a network partition situation, some but not all network connections are lost and your single network effectively becomes divided into separate subpieces. Each subpiece can communicate within the piece but not with other pieces. Thus both servers lose connections with each other, but are still up and running, and in some cases can still communicate with some clients.

The dual primaries scenario can be avoided by using a single-instance watchdog in a node that is external to the HSB system. By using such a watchdog, it is easy to decide which server must be set to Primary and to ensure that clients see only one Primary.

Although HAC in composed of two instances that running in the same nodes with HSB servers, the dual primary situation is impossible when HAC is used with ERE.

Even if you have dual primaries, you do not have inconsistent data unless someone is able to perform a write operation on the original Secondary (after it has switched to PRIMARY ALONE). If the original Secondary is cut off from the rest of the network, no one can write to it. The original Primary is a superset of the Secondary, and you can get a single consistent set of data (after you reconnect the servers and allow the Secondary to catch up with the changes made on the original Primary).

Although dual primaries are rare, they are dangerous when they do occur. You must plan you environment so that you can prevent your data from becoming inconsistent. For example, use ERE.

The chances of dual primaries increase if you set the configuration parameter AutoPrimaryAlone to Yes for one or both servers. The AutoPrimaryAlone=Yes parameter setting means that your system can respond to failures quickly, but it also means that the system no longer has any independent observer (HAC, watchdog or human) to prevent dual primaries. If you have any doubts on your network reliability, keep the AutoPrimaryAlone parameter in its factory value, that is, No.