In synchronous mode, committed transactions are guaranteed to be recorded on the mirror server. Should a failure occur on the primary server, no committed transactions are lost when the mirror server takes over. In this mode, the primary server sends transaction log pages to the mirror when a transaction is committed. The mirror server acknowledges that transmission when it has written those pages to its copy of the transaction log. The primary server does not reply to the application until it receives this acknowledgement.

Using synchronous mode provides transaction safety because the partner servers are in a synchronized state, and changes sent to the mirror must be acknowledged before the primary can proceed.

Asynchronous and asyncfullpage mode are faster than synchronous mode, but are less reliable. By default, if the primary server stops unexpectedly, then the mirror server does not automatically take over as the primary.

In asynchronous or asyncfullpage mode, failover from the primary server to the mirror server is not automatic because the mirror server may not have all committed transactions that were applied on the primary server. For this reason, when using one of the asynchronous modes, a mirror server, by default, cannot take ownership of a database when the primary fails. If automatic failover is desirable in this situation (despite the likelihood of lost transactions), set the auto_failover option to on using the SET MIRROR OPTION statement. Otherwise, when the failed server is restarted, it detects whether transactions were lost. If transactions were lost, it writes a message to the database server message log and shuts down the database. The current database and transaction log must then be replaced using a backup before mirroring can continue.

For information about bringing up a server after it fails in asynchronous or asyncfullpage mode, see Troubleshooting: How to recover from primary server failure.

The synchronize_mirror_on_commit database option controls when database changes are guaranteed to have been sent to a mirror server when running in asynchronous or asyncfullpage mode. When you set this option to On, each COMMIT causes any changes recorded in the transaction log to be sent to the mirror server and an acknowledgement to be sent by the mirror server to the primary server once the changes are received by the mirror server. The option can be set for specific transactions by using SET TEMPORARY OPTION. It may also be useful to set the option for specific applications by examining the APPINFO string in a login procedure.

SQL Anywhere supports system events that fire when failover occurs in a database mirroring system, regardless of which mode you are using. You can use these events for such tasks as notifying the administrator when failover occurs.

When running in asynchronous or asyncfullpage mode, you must determine what happens when failover occurs and transactions are not committed to the database.

A mirroring system running in either asynchronous or asyncfullpage mode requires the primary server to wait in fewer cases than when running in synchronous mode. But, even in asynchronous or asyncfullpage mode, some of the messages sent from the primary server to the mirror server wait for an acknowledgement from the mirror, potentially introducing delays. In addition, there is a small amount of overhead in sending packets to the mirror. Asynchronous and asyncfullpage modes are not recommended because transactions can be lost.

• synchronize_mirror_on_commit option
• SET OPTION statement
• SET MIRROR OPTION statement
• Using database mirroring system events to send notification email when failover occurs
• Troubleshooting: How to recover from primary server failure