md5-hash:c5c0618c62b70d44e0f6fdc51d75528f weight:-14 depth:2 Overview One of the RDBMS is an Interbase. The Interbase is powerful transaction SQL database engine that implements many advanced features - views, triggers, stored procedures, generators, etc. Interbase was developed by Borland as commercial database but version 6.0 was released as open-source. It means that it's possible use it for-free for any purposes. On the open-source database was founded new branch named Firebird. Even Borland released next Interbase v7 as non open-source, the Firebird clone remains open-source.

Even the Interbase architecture is robust and powerful, comparable to other concurrent, one feature limits it - there is not implemented replication engine such as in Oracle, MSSQL or even MSAccess.

In many cases data of an enterprise are not stored in one database but they are distributed to more locations. Replication engine try to maintain data in each of databases as synchronous as possible. To be replication efficient, the engine catches only data changes and passes them to the other databases.

There are many reasons why to split data:

There are many replication models because two enterprises will have probably different requirements.

Lets see several examples.

There are main database and shadow (read-only) database that serves as backup. When the main database crashes, shadow database is activated as main one.

There are more equivalent databases. Data should be the same in each of them.

Enterprise maintains net of agents that have database at personal laptops. They can change records (make orders, update information). And because they are competitors they can see only own data.

Enterprise must consolidate data daily from subsidiaries.

So there are many questions:

Because replicator must meet all contradictory requirements, changes fire triggers that log them in source database and then they are replicated to targets. It means that are transferred only changes. Due to referential integrity it's necessary replicate in the same sequential order as the changes occurred. If new records may be inserted in more locations, primary keys must be unique - every record must be identifiable by unique primary key. The logging brings overhead and the source database growths, so replication log records are deleted when are successfully replicated. You can configure what fields values log - generally primary key values must be logged mandatory, NOT NULL and foreign key fields recommended and remaining values optionally.

Let's suppose that the replicator connects to the source database, looks to change log and if there are some records connects to the target database and transfers the changes. One replicator is connected to both databases in one time, hence it's online replication. But what happen if connection is broken before transfer is finished? Nothing dangerous, change log record is removed when change is committed in target database - it simulates two phase commit. But when an constraint problem occurs record is moved to other log where are stored conflicting records. The replicator cannot solve such problem automatically, it must be solved manually, hence the log is named manual log.

How is possible replicate when one of databases is unavailable from opposite location? It is hidden behind the firewall, machine where is running connects via dial-up or connection is unreliable. The solution is offline replication. In this case the first replicator is connected to source database and prepares packages containing replication data and passes them to a shared drop-off location where are left untouched until the second replicator reads the packages from the shared location and applies data to the target database. The offline replication uses robust four-phase acknowledge protocol and stores package transfer history if transfer log.

In ideal world all data are correctly replicated. But in real world from time to time happen an exception or an accident (hard disk crashes, replication integrity corrupts, etc.). Even no crash happen there is one exception - start of replication, because you must setup data to be synchronous before replication is done. Who can manage databases to be ready for replication? Answer is a synchronization. The replication transfers only changes whereas the synchronization compares databases, table to table, record to record. This process is of course much more time consuming especially for large databases. Note that synchronization is always online.

Now let's suppose that there is an table containing very important data and somebody intentionally rewrites it. This problem solves history - replicator keep record history in history log. Unlike the replication the history is not replicated to other database.

Another possibility how to keep record history is incremental SQL log. It's a plain text file containing sequential list of SQL commands. Note even Interbase data manipulation language does not support BLOB values, the incremental log contains also BLOB metadata. Since it is plain SQL text file it can be used to feed changes to any SQL database, e.g. you can replicate changes to MySQL. Both the online and the offline methods are supported.

If data are changed at both sides data inconsistency can occur, when corresponding record is changed in the source database and the target database. A field/record conflict happened. The replicator is able to recover conflict automatically according or to pass conflict to the manual log. The recovery is configurable for every relation.

All the configuration data, i.e. schemes are stored to a separate configuration database. You can prepare it once and use for all locations, does not matter if you access it online or make physical copy. It simplifies administration significantly.

Features

Features not yet implemented

Requirements

]]>