Asynchronous Commit Pros and Cons

Reasons to Use Asynchronous Commit

Asynchronous commit provides a fresher view of the database than other forms of backup. Handoff typically loses only a small number of recently committed transactions. The time scale for data loss is comparable to the ping interval. If the ping interval becomes larger than the specified ping timeout, nodes will be evicted and presumably the database administrator will be aware that there is a problem. In contrast, restoring a backup loses all transactions committed after the backup was taken. The time scale for data loss is the interval between backups.

Asynchronous commit allows the database to come back to life after a disaster more quickly than the time needed to restore a large backup. Archives already exist and are already populated. They just need to be reset to the most recent consistent state.

The network latency between geographically remote data centers is necessarily much higher than the network latency between adjacent racks in the same data center. This increased message latency would seriously degrade NuoDB performance if there were active Storage Managers in a remote data center. Asynchronous commit avoids this performance degradation.

Reasons Not to Use Asynchronous Commit

Asynchronous commit is expensive because it requires at least one extra data center. Each passive data center requires at least one AP, at least one SM, and storage for at least one archive+journal. All this hardware must be running continuously to provide full coverage. In contrast, backups only use resources while the backup is being taken, and even then don’t use much extra resources. Use asynchronous commit when the potential cost of losing data in a disaster outweighs the added expense.

High-bandwidth network connections between data centers might be much more expensive than network connections between nodes in the same data center. Thus any multi-data-center deployment might be more expensive than a single data center.

If the passive data center goes down, asynchronous commit does not protect transactions that occur while it is down nor while the asynchronous storage managers are syncing their archives after coming back up. This can be alleviated by running multiple passive data centers, but that multiplies hardware and network expense.

Asynchronous commit does not care about network latency, but it needs sufficient network bandwidth between data centers to carry all replication traffic. If the network cannot keep up, active TEs will buffer replication messages, forcing them to throttle their performance or run out of memory.

There are no special network address requirements so long as nodes in different data centers can communicate. NuoDB requires that every node be able to communicate with every other node and observers are no exception. NuoDB does not tolerate dropped network connections. If a network connection is broken, at least one of the two nodes that are no longer connected will fail and must be restarted. Network connections between data centers might be less reliable than connections within one data center.

Asynchronous commit does not completely protect all committed transactions when a disaster occurs. If total protection is necessary, you must use an active/active configuration with active SMs in a remote data center and safe commit mode. That configuration will protect all committed transactions, but perform more slowly due to network latency.