Browse Prior Art Database

Incremental Data Base replication on Cluster using Group Communication

IP.com Disclosure Number: IPCOM000132182D
Original Publication Date: 2005-Dec-05
Included in the Prior Art Database: 2005-Dec-05
Document File: 3 page(s) / 63K

Publishing Venue

IBM

Abstract

Presented here is a solution for a problem that arises in data replication for database systems, a method for collecting all the commands of ongoing transactions executed by the active server and executing them on the passive servers only when commit is executed at the active server.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 3

Incremental Data Base replication on Cluster using Group Communication

Data replication is the core function required for business continuity in the face of disasters. Highly available systems comprise a cluster of nodes, each having its own replica of the data. In a typical architecture, one of the nodes is an active server, whereas the rest of the nodes are passive. The active server receives and manages commands and transactions and propagates them to all the other (passive) nodes.

    A common means for storing data is using a database system. Database systems have the attributes of the ACID model: Atomicity, Consistency, Isolation, and Durability.

    Database systems have mechanisms that enable propagation of data and transactions. Such mechanisms are usually limited to a single passive server (i.e., a cluster of two nodes). Applications that adopt this approach are typically constrained to a specific database system/vendor and to a limited configuration.

    To achieve a higher level of availability, a system may comprise multiple nodes, with a single active server and multiple passive servers.

    The challenge is to update the database at the passive servers without stopping operations on the active server, such that when the active server fails all passive servers have a consistent database, and any one of them can take over the role of active server. This is complicated by the fact that the active server may execute ongoing/open transactions that are not committed immediately.

    In a clustered environment, servers can drop out or join the cluster at random times. It is imperative that newly joined servers be detected and their replica of the data be updated to a consistent state

    The main idea is to collect all the commands of ongoing transactions executed by the active server and execute them on the passive servers only when commit is executed at the active server. This can be accomplished using two alternative approaches.

Collect ongoing transactions at the active server. Complete transactions are


1.


2.

sent to all passive servers when commit is executed on the active server. Collect ongoing transactions at the passive servers. Each part of an ongoing

transaction is immediately sent to all passive servers; the transaction is executed on a passive server when its commit arrives.

A group communication layer is deployed on all servers in order to:

Automatically detect servers joining and/or dropping from the cluster.

Apply a virtual synchrony mechanism for message propagation in the cluster

to ensure that:

All cluster members receive messages in the same order. Messages are sent to and received by all cluster members.

    The methods described here are independent of the database and are applicable to any database that is capable of creating a consistent snapshot of all committed transactions and exporting it to file(s).

    The following data structures and algorithms are used for replication of database information in highly available active/pas...