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

In the case of dual primary servers if both servers commit 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 will be lost. Having dual primary servers can also lead to other errors.

Dual primary servers are 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 connection with the other, but are still running, and might be able to communicate with some clients.

Even if you have dual primary servers, you do not have inconsistent data unless someone is able to perform a write operation on the original secondary server (after it has switched to PRIMARY ALONE state).

Although dual primary servers are rare, you should plan your environment so that you can prevent your data from becoming inconsistent. For example, by using a High Availability Controller (HAC) with an External Reference Entity (ERE), see External Reference Entity (ERE)..

The chances of dual primary servers increase if you set the configuration parameter AutoPrimaryAlone to yes for one or both servers. This 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 primary servers from occurring.