The Invisible Database

In my post on January 24, I described my belief that the first step for an ISV who is considering how to offer a cloud version of their application is to choose the most appropriate database infrastructure. One key concern I didn’t mention in that post was that ISVs need to consider what options their DBMS offers for high availability (HA) Often, an ISV’s application will be mission critical to their end-user customers, and needs to be available 7×24.

While many end-users may be reluctant to spend extra money for onsite HA solutions, ISVs implementing a cloud environment have the unique opportunity, perhaps even the mandate, to ensure their system is protected against hardware failure. There are certainly many aspects of a high availability system that are beyond the database software; including storage infrastructure, networking, and server hardware. Even taking all these items into account, there still needs to be support in the DBMS for high availability.

SQL Anywhere is an example of one such DBMS that offers full support for high availability. In a running SQL Anywhere HA environment, 3 machines are utilized:

• 1 system to act as the primary database server
• 1 system to act as the standby mirror server
• 1 system to act as the arbiter

In this setup, if anything happens to the primary database server, the standby mirror server automatically takes over, becomes the primary server and begins to handle new connections and requests. The database is guaranteed to have all committed transactions from the primary. Any uncommitted transactions are automatically rolled-back. When the other machine restarts, it is automatically updated to the current state, and it assumes its new role as the standby mirror.

There are several nice characteristics of SQL Anywhere’s HA solution:

• Any supported platform and operating system can be used. For example, one of the machines could be running Windows while the other 2 machines are running Linux.
• There are no special hardware requirements. Each of the machines could be a standard off-the-shelf system.
• Systems that are acting as the standby mirror server or arbiter for one database could be acting in another capacity for a different database. As an example, in an multi-tenant ISV cloud setup, one of the servers could be acting as a mirror for one tenant, and as the primary for another tenant.
• Applications can connect to the mirror server in read-only mode, offloading read-only reporting queries from the primary server.

You can read the complete details of SQL Anywhere’s High Availability implementation on DCX here.