Download the eXtremeDB High Availability data sheet (PDF)
eXtremeDB High Availability Edition embedded database is a fault-tolerant version of eXtremeDB™ designed to answer the challenge, “How can a RAM database survive the failure of the software or hardware environment in which it operates?” Designed to power embedded systems that cannot afford to fail, eXtremeDB-HA delivers the highest degree of reliability, along with its unsurpassed performance and exceptionally small footprint.
In addition to the in-memory database system (IMDS) version, the eXtremeDB High Availability database is available as a hybrid embedded database, called eXtremeDB HA Fusion, that enables developers to combine all-in-memory with on-disk data storage in the same application. For details on the hybrid capabilities of eXtremeDB HA Fusion, see this site’s page for the eXtremeDB Fusion product.
Process control, telecom and network gear, and other embedded systems with demanding “five-nines” reliability (99.999% up-time) requirements comprise a fast-growing segment of real-time applications. These systems are managing greater volumes of more complex data—creating a need for a fast, lightweight commercial off-the-shelf (COTS) database that can meet their reliability imperative
Typically, existing fault-tolerant systems use replication schemes to create backup embedded database copies. But replication entails latency from the moment a primary data store is updated, until these changes are propagated to the replica database. Such latency is often unacceptable in time-critical embedded systems (check out the article in Embedded Systems Europe, that highlights different approaches to database replication).
The eXtremeDB-HA runtime maintains multiple identical embedded database instances within separate address spaces. Typical hardware configurations include:
Multiple processes or threads within the same hardware instance
Two or more boards in a chassis with a high-speed bus for communication
Separate address spaces on boards connected via industry standard communication media and protocol such as RS-485/RS-232, Control Area Network (CAN) or Ethernet
Two or more controllers connected via a proprietary communication media and/or protocol
Separate computers on a LAN
McObject’s eXtremeDB High Availability database solution is based on a rugged, time-cognizant two-phase commit protocol that ensures changes to the main instance database and identical standby instances succeed or fail together. A High Availability control interface exported by the eXtremeDB-HA runtime provides the means for the application to configure, establish, maintain and terminate eXtremeDB-HA connections. A time cognizant HA transport protocol enables communication as well as detection of timeout situations.
Master side |
Replica Side |
|
|
eXtremeDB - High Availability uses a communication channel abstraction to allow master and replica applications to use user-defined communication channels to exchange data and communication messages during transaction processing. This is a flexible approach that allows the eXtremeDB embedded database to stay independent of the underlying communication media and the operating system.
At the same time, this approach requires an application to implement the actual communication layer. To facilitate faster development and deployment of fault-tolerant database solutions, the High Availability database package includes the eXtremeDB-HA Application Framework that demonstrates how to build HA-aware applications. The HA Framework includes working examples of communication channels built over various transports. The framework also includes a HA-aware application example that can be configured to use any of the channels provided in the Framework (currently TCP/IP, UDP, Named Pipes and Qnet). In addition, the sample application can be configured to use either the Standard Memory or Shared Memory version of eXtremeDB.
The High Availability subsystem exports an API that isolates the application from platform dependencies and the communication media. The communication protocol API used by the HA subsystem is divided into two layers:
A low layer that is referred to as the protocol layer. The protocol layer provides the means for guaranteed data transfer between the master and the replicas, isolating the application and the HA subsystem from platform dependencies and the communication media. The protocol layer implements an independent point-to-point channel between the master embedded database and each replica.
A higher layer that is called the interface layer and presents a simplified API that isolates an application from the protocol layer implementation details. In general, you only need to use the protocol layer for user-defined channel implementations. If an application is using one of the channels provided by McObject in the Application Framework, it only needs to use the interface layer API
The HA Application Framework implements a number of channels over the mostly commonly used transports:
TCP/IP
UDP/IP
Named Pipes
Qnet™ (QNX Neutrino)