Since hardware components may fail and be replaced on the fly by other components, there must be a way of preserving application state, so that the newly activated applications can take up where the downed applications left off. In the past, this was achieved by what is called "application checkpointing." In this technique, applications frequently copied their state to standby applications on a spare node so that they would be ready to take over in case of failure. See Figure 5.

Figure 5: Application Checkpointing
Several problems arise with this technique. The first is that it requires the applications to have a detailed knowledge of the system architecture. They must know how to find the standby applications and how to communicate with them, even after nodes have failed and been replaced. This makes the architecture rather fragile, since changes must propagate through all the applications, and increases the complexity of the applications. It also means that commercial off-the-shelf (COTS) applications cannot be used in such systems. Additionally, since each application is writing its own state checkpoint at its own intervals, it is very difficult to guarantee that a restarted node will be in a consistent state.
These problems have driven application developers to record application state in a high availability database instead of in individual applications, as shown in Figure 6.

Figure 6: Preserving Application State in a Database
In this technique, applications use standard ODBC/JDBC calls to write their state to a SQL database. The database management system (DBMS) takes care of copying the state continuously to a standby node. Using this technique, applications need only know the location of their local database - the DBMS takes care of finding the standby node, offloading this complexity from the applications, and improving system robustness. Because of this reduced complexity, COTS applications can take advantage of this technique with little or no modification. If applications write their state as a routine part of each transaction that they perform, the DBMS can guarantee global state consistency within the standby node.
This technique removes from the applications the need to do any data synchronization and places that onus on the DBMS. The modern DBMS offers a variety of options in setting up this synchronization between active and hot-standby databases.


