As ScaleBase moves closer to its public beta stage, it is an opportune time to explain more about how the ScaleBase High Availability solution works. Many customers are already using this solution. I have summarized its main capabilities below.

Database High Availability

Let’s begin by describing ScaleBase’s database high availability options. Database availability in public cloud environments is not a common topic of discussion. Probably since it is very difficult to configure an acceptable high availability solution.

Solutions already exist for data replication between two databases, such as MySQL, and even though MySQL currently only supports asynchronous replication, Most database replication installations around the world are asynchronous, even those involving non-MySQL databases.

So, if we have replication, does that mean that everything works just fine? No. There is a problem with the failover process itself. How do you recognize when a database crashes? And, once such a situation is identified, how do you perform a failover to the backup database? This requires coding applications correctly, so that when specific types of exceptions occur, the connection is closed and then reopened. During that process, running transactions should be closed and rolled back, which is very difficult to implement at the application level.

Another important issue regarding database high availability failover is that failover itself is a destructive action that should not be taken lightly. Database failover typically implies the loss of data, which makes the primary (former) database unusable. After a failover, when the backup database is updated, these updates are often not populated back to the primary database, thereby making the database unusable. In this case, such updates must be manually recreated.

How does ScaleBase handle this scenario?The first problem involves immediate failover, which is quite simple to handle. The ScaleBase Database Load Balancer gets the database exceptions and redirects the commands to the backup database. Transactions can continue running after the lag is handled.

The second problem, which involves consistency lag, is handled by storing a small transaction log in a distributed cache. When a database crashes, the ScaleBase Database Load Balancer detects it and moves all the requests to the backup database. Before doing so, it ensures that all INSERT and UPDATE operations are re-synched to the backup database. Although this may affect performance for a very short period of time, it does ensure data consistency.

Load Balancer High Availability

Simply placing a piece of software in front of the database is not sufficient. This software itself must be highly available. Because the ScaleBase Database Load Balancer uses a share-nothing architecture, except for configuration and a small transaction log, it is easy to add additional load balancers to the Database Load Balancer cluster. However, this requires that the customer know each load balancer, which is not what we at ScaleBase envisioned when trying to build a transparent database high availability SQL Server solution.

Running multiple share-nothing servers on the cloud is simple. Cloud infrastructure providers offer that exact capability. For example, Amazon offers the Elastic Load Balancer solution, which supports both HTTP and TCP/IP. It is a great tool (you can read more about it here http://aws.amazon.com/elasticloadbalancing/), and is totally transparent to the user.

The diagram below shows the architecture of the ScaleBase high availability SQL Server solution:

ScaleBase High Availability Architecture

The Elastic Load Balancer by Amazon, shown in the center of the diagram above, ensures that the ScaleBase Database Load Balancer is highly available. The Database Load Balancer ensures that the databases are highly available.

For more information, you can write a comment here, or reach us via the Contact us link at the top of this page.