JADE Environment Development Ideas

Overview

SDS transaction level synchronicity is aimed at providing a software alternative to an equivalent hardware mirroring solution with zero RPO capability.

Recovery Objectives

The main Disaster Recovery (D/R) objective is to support a zero Recovery Point Objective (RPO). In a JADE database context, zero RPO equates to zero transaction loss. Improving the D/R Recovery Time Objective (RTO) is not a goal of this proposal, which means there is no requirement for the secondary replay process to participate in the transaction commit protocol and replay can remain asynchronous.

Summary

Transaction level synchronicity would be enabled on the primary database and one or more secondary database servers operating in block transfer mode. When enabled, transactions will not be acknowledged as committed by the primary database until the audit records required to ensure transaction durability have been made stable by at least one secondary database. In practice this means that the journal block containing the transaction commit audit record has been persisted in storage by the secondary database.

Synchronous mode could be configured at more than one secondary database, thus offering multiple site failure protection.

Transaction versus I/O level synchronicity

This is the area that offers real cost and performance benefits over a hardware remote mirroring solution. As stated previously, in the hardware solution both the data and audit volumes must be mirrored and in a database scenario every I/O must be synchronous to ensure database consistency and transaction durability in the event of a fail over and recovery at a D/R site. Ironically, even the I/O penalty on every audit write is generally an overkill in a database scenario because it is necessary to ensure only those transactions that successfully completed on the primary are recovered at the remote database and all incomplete transactions are backed out. Since SDS is closely integrated with database auditing and recovery, only selected audit writes need to be made synchronous, which means the impact on primary database transaction response time and throughput can be much lower for the equivalent degree of transaction protection.

Dealing with the no secondary scenario

Given transaction level synchronicity, two further operating modes are possible that deal with the situation when network connectivity to participating secondary databases is lost for some length of time. The first mode is biased towards maximising database availability; the second is biased towards maximising data protection.

Maximum Availability (Default)

This mode of operation offers zero transaction loss and protection against a single system failure. In this mode when the primary loses contact with all its participating secondary databases, processing on the primary system can continue. Participating secondaries can temporarily fall behind the primary database, but once connectivity is restored the databases will automatically resynchronise and no transactions will be lost. The risks of having no standby database for a period and database divergence may be acceptable to some institutions if no data is lost in the event of a fail-over. In this mode, there is a risk of data loss in the case of multiple failures including a network outage followed by complete loss of the primary database.

Maximum Protection (Mandatory Secondary Commit)

In this mode, if the primary loses contact with the last participating secondary database, then transaction processing on the primary will be halted. This is required to ensure that no transactions will be lost when the primary database loses contact with all participating secondary databases.

Selective Synchronicity

When the primary database is required to wait for an acknowledgment from one or more secondary databases before committing a transaction, transaction response time will be impacted to some extent. On the other hand, there may be applications processing transactions that are not all critical to the business.

Consider:

Providing application developers the ability to specify the transactions that are critical and require protection. This will provide additional flexibility to make trade-off performance and risk were appropriate. This capability could be achieved with an appropriate extension to the JADE commitTransaction instruction by adding an optional synch or protected keyword, for example. It may also be desirable to provide the means to override application-selected synchronicity by allowing the degree of synchronicity to be configured externally.

Configurable Protection Modes

The addition of a block level transfer mode together with the ability to synchronise secondary databases at a transaction level can be combined in various ways that will enable an organisation to balance cost, availability, performance and transaction protection.

A range of possible configuration options with their main performance, protection and availability characteristics are depicted in the following table.