5.6 HA in Universal Cache

A system for database caching, like IBM solidDB Universal Cache might be required of some HA characteristics also. In this section, we describe the possibilities and ramifications of Universal Cache HA configurations.

5.6.1 Universal Cache HA architecture

When Universal Cache (UC) is configured for high availability, hardware and software redundancy can be seen both in the front-end and back-end tiers, or in either one. The choice of where to apply the redundancy depends on the required availability level of the total system and expectations of the availability of stand-alone components. For example, if operation breaks (measured as MTTR) in the cache database are not allowed to be longer than it takes to restart a database server (and that might be long, for an in-memory database), the solidDB HSB configuration is needed.

If the UC application load is totally confined within the cache database (the pass-through is not used), the operation breaks of the back end are tolerable as long as the front-end transactions can be buffered in the cache database for later transfer to the back end (catchup). In that case, a stand-alone back-end server might be sufficient. If pass-through is used, an HA solution in the back end can be required.

142 IBM solidDB: Delivering Data with Extreme Speed

The full HA configuration of Universal Cache is shown in Figure 5-18.

Figure 5-18 HA setup for Universal Cache

The front-end tier is configured in the same way as the solidDB-only HSB setup, involving HA controllers and, possibly, an ERE.

Regarding the InfoSphere CDC components, the InfoSphere CDC replication engine for solidDB (InfoSphere CDC for solidDB) is deployed on the back-end system instead of the front-end system, as was the case with the basic Universal Cache configuration. The reason is because the replication engine must survive solidDB server failovers. In some cases, the engine seamlessly continues the operation over the failover.

Chapter 5. IBM solidDB high availability 143

5.6.2 UC failure types and remedies

In a system such as the one shown in Figure 5-18 on page 143, various components can fail. In this section, failure types and recovery methods are described.

solidDB failures

Failures of solidDB servers in the front-end tier are dealt with in the normal ways that are available in the solidDB HSB solution. If the Primary server fails, a server failover is executed. If the Secondary server fails, the Primary continues to operate.

The InfoSphere CDC engine for solidDB has some resiliency to front-end failovers. All the subscriptions that use solidDB as a source continue mirroring normally, over a failover. However the subscriptions that use solidDB as a target stop the mirroring. They must be restarted using the InfoSphere CDC command-line interface. What we describe in the following text, must be implemented on an individual deployment basis. In practice, a shell script restarts the subscription. Also, a failover detection method must be implemented to initiate the script. It might be done with a component similar to the Watchdog that monitors the HSB server states, and act upon a detected failover.

InfoSphere CDC failures, InfoSphere CDC resilience

InfoSphere CDC replication engines can fail, causing the mirroring to stop. InfoSphere CDC does not have any built-in redundancy or failover methods. That means the InfoSphere CDC components must be explicitly restarted. That too can be achieved with shell scripts and a method to detect InfoSphere CDC component failures.

Temporary dysfunction of InfoSphere CDC components does not stop the cache database to serve the applications. Pay attention to restarting the InfoSphere CDC components fast enough for them to be able to catch up with the application load in the cache database. The actual time span allowed for the InfoSphere CDC replication engines to be non-functioning depends on the volume of updates in the cache database and the buffer size settings. The time can vary from minutes to hours.

144 IBM solidDB: Delivering Data with Extreme Speed

Back-end failures

The back-end failures are dealt with in the ways typical for a given DBMS product and configuration. The solidDB Universal Cache product does not include any components to deal with those failures.

If the back-end database runs as a stand-alone system, normal restart and recovery is needed (to be initiated manually or automatically). Additionally, upon restart, the InfoSphere CDC subscriptions (or engines) must also be restarted.

If the back-end database is run in an HA configuration, the corresponding product-specific methods for failovers are used. Additionally, the InfoSphere CDC components have to be migrated, reconfigured, and restarted on a new active site. The process can be done with the InfoSphere CDC command-line interface and shell scripts.

During the unavailability of the back-end database, the cache database serves the applications. For the back-end database to be able to catch up with the load in the cache database, the back-end database and the InfoSphere CDC replication have to be reinstated in due time. If the back-end downtime is too long for catching up to be possible, the refreshing of the subscriptions must be done.

Chapter 5. IBM solidDB high availability 145

6

Chapter 6. Performance and

troubleshooting

Performance and troubleshooting is a vast and widespread topic that is also one of the most important to ensure the system runs as smoothly and as optimally as possible. In this chapter, we describe several valuable tools that can help with analyzing the performance of the solidDB server, InfoSphere Change Data Capture (CDC), and a user’s application. The chapter also covers several tools and methods that can be used to troubleshoot situations such as an abnormal termination or a hang.

Application developers, database administrators, and system administrators can obtain practical and valuable information from this chapter and that can help ease their jobs.