- For Financial Services
- Dev Center
- About NuoDB
- Download CE
- Watch the Demo ❯
You are here
Continuous Availability: Moving Beyond High Availability
Feb 25 2015
In this short demo video, we demonstrate how NuoDB's distributed SQL database can be configured on-demand to run as a redundant active-active database across multiple server hosts. Later, we show how it gracefully handles machine failures without any downtime.
As you'll see, all of NuoDB's continuous availability features are a result of the unique patented architecture of the product. Continuous availability in NuoDB offers built-in support for redundancy, rolling upgrades, and online schema evolution and backup.
The video features our Storefront demo, where you can see how NuoDB can ensure continuous availability for your applications.
To start with, we run the NuoDB database on a single host on Amazon AWS US East with 520 concurrent Storefront users at approximately 800 transactions per second or “TPS”. Given this workload, the database appears to be under provisioned as indicated by the relatively high latency of around 350 milliseconds per transaction.
You can see from the host’s view that there are two NuoDB processes running on the same machine. The Transaction Engine or “TE” is an in-memory process responsible for processing SQL commands, caching data, and coordinating transactions with other TEs and Storage Managers. If you add one or more TEs to the system, the incoming requests will be distributed across all TEs thereby increasing transaction throughput if needed.
The second process, Storage Manager or SM, is responsible for making transactions durable on disk. Each SM in NuoDB contains a complete copy of all the data on disk and a new SM can be brought online on-demand.
When we add another host to the system, NuoDB brings up a new TE and SM on that host. By doing so, we not only see improved transaction throughput and significantly decreased latency, but we have also made the system redundant as soon as NuoDB completes the initial data replication to the second SM.
If we then think about a common issue that might threaten continuous availability, we'll want to see what would happen to the NuoDB database if there was a host failure -- perhaps caused by a network connection error -- on AWS. In the demo above, we simulate this scenario by shutting down each of the NuoDB processes on one of the hosts.
Now that the NuoDB processes on that AWS host are no longer available, NuoDB transparently reroutes all new transactions to available TEs, in our case to the TE on the remaining host.
And as you would expect, the database has automatically scaled back to the remaining process resources resulting in TPS and latency performance levels of the original single-host scenario.
Now that our unexpected simulated network failure has ended, NuoDB’s built-in template-driven automation capabilities will restart the TE and SM processes on the second host in order to bring the system back to a fully redundant state.
What we see in this demonstration is that NuoDB can provide continuous availability as part of an active-active database operation, using all available database resources. The system can be easily configured and managed on-demand with zero downtime - a far cry from the idea of "acceptable" levels of downtime expected from a high availability system.
Just download NuoDB today and take it for a spin.