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.

Recently, relational databases with their ACID support and static schemas have come under fire, with many believing they have reached their limits. This position is often promoted in the context of public clouds, where relational databases are problematic to say the least. Instead, it is claimed we need new databases, design especially for the cloud. These new databases will support:

• Dynamic resource use, where the database can allocate and deallocate new resources when needed, as a means to optimize costs and scaling.
• Self-healing, which reduces the risk of data loss when part of the system fails.
• Multi-tenancy, which enables the database to support multiple customers simultaneously, without the risk of compromising data.

All of these factors are crucial requirements for cloud databases. However, they do not necessarily imply that new database software is required in order to run in a cloud environment. This is especially important since replacing a database has tremendous implications. Here are a few reasons why:

• Databases have a complete ecosystem around them for monitoring, backup, tuning and so on. Replacing a database requires that system administrators (and DBAs) learn new technology.
• Code modifications and a complete QA cycle would be needed. Each database requires enhancements to the standard SQL language and applications rely on these enhancements. Therefore, they would need to be changed to support the SQL flavor of the new database – if these new databases support the full SQL language at all.

These issues are painful for both new and existing applications. For example, converting a 10 year old application written in Java from Oracle to another database is not an attractive option. Even writing a new application with an ORM that does not support your new database can be a painful task.

This is the key problem we identified when founding ScaleBase. Relational databases are very popular, but they are not truly cloud ready. Their scale and availability in cloud environments is poor, and they require ACID.  However, the reliability and other well-known benefits of existing databases should be promoted and not disregarded.

And this is why we developed the ScaleBase Database Load Balancer – our unique solution that enables any existing relational database to work in cloud environments. Any database can operate in the cloud and enjoy its benefits. All you have to do is to place the ScaleBase solution in front of it!

As you can probably guess, we get many requests for information on how to use caching along with ScaleBase. Well, the answer is very simple – always cache.
This, of course, is not a sufficient answer.
The real question is the architecture of the application, and where the caching layers needs to be implemented.
Consider the following architecture:

This is a really basic architecture, and most applications usually start with something similar. Some logic runs on the browser side (mainly AJAX code, but some UI logic does as well). The Apache layer runs your code (for PHP, and just translates Apache to App Server in Java, IIS in .NET and so on). The MySQL server serves as your database.
However, this solution does not deliver stellar performance. Why? Because, we have not implemented any caching layer. So let’s add it.

This solution can improve performance, but prompts new questions, such as when to use the cache and when to read directly from the database. While this is a simple problem to solve in a standalone machine (all reads are done through the cache, writes occur at the database and the write action also invalidates the relevant area of the cache), it is very difficult to implement with MySQL Clustering. For distributed cache solutions you can check GigaSpaces XTP or Oracle Coherence, and of course – Memcached.
Even when using caching, the database can become a bottleneck, and MySQL Clustering is not enough. This is where ScaleBase comes in. Consider the following architecture –

Now the same business logic can enjoy both a scalable caching infrastructure, and a scalable database infrastructure, to be used for massive writes or reads situations. Do note however, that ScaleBase itself, because of the data splitting that occurs on the database layer, can speed up the performance of writes and most read operations. That said – it does not replace your caching layer in any way.
To summarize, you can add caching to your application when using ScaleBase. We even strongly recommend it. Just make sure to choose a caching layer that scales well ; otherwise, your scaling problems will move – from the database tier, to the caching tier.