Pros and Cons

The use of ASMs provides a more recent 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 is longer 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 last backup. The time scale for data loss is the interval between backups.

The use of ASMs allows the database to recover 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 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 (SMs) in a remote data center. The use of ASMs avoids this performance degradation.

The use of ASMs 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 do not require a lot of extra resources. Use ASMs 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, the use of ASMs does not protect transactions that occur while it is down nor while the Asynchronous Storage Managers (ASMs) 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.

The use of ASMs 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 ASMs 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.

The use of ASMs 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 performs more slowly due to network latency.