DBRE - User's manual

/ English / Russian /

Table of contens:

1. Description of application
2. How it works
3. Command line options
4. Configuration file
5. Extensions of source database

Description of application

The DBRE system is aimed at point-in-time database replication. The system can be used for separated in space, at different hosts databases, and for the database in a single host. A classic example of its use a distributed network of branches. Once a 24-hours period affiliates "drain" your data to head office. The office can send new branches and service directory information.

How it works

The system reads the configuration XML file that shows all the necessary data for the work. Then connection to the database and opening data files follow. In accordance with the configuration of the source-database or data-file entries are selected, which are then passed to the destination-database or data-file.
Entries in one transaction, thus, provide a guarantee that it will be fully implemented or not implemented at all.
The system allows you to monitor uploaded records to avoid re-unloading. To do this, unloaded and trigger an event update, nulled it should be added the service field in the unloaded table.
You can specify the names of different fields to the source and the receiver, enter the index field (for the renewal of record), as well as to indicate that the field at the receiver is auto-increment to exclude recording recurring key. You also can upload information about deleted records in the source with subsequent removal of the receiver.

Command line options

-p or --params - path to config file (example: /etc/dbre/enterprise_database.xml), you must set this parameter
-l or --log - path to log file (example: /var/log/dbre.log), if the parameter is omitted, information (when verbose is one) will be outed to stdout
-v or --verbose - the level of output more information. It can take values of 1, 2 or 3. Designed for the verbosity of replication. Useful for debugging.
-h or --help - concludes brief hints and exit

Configuration file

The configuration file is XML format and contains the following sections:
<replication> - base section

<input> - section of the input data source. On the whole configuration file should be in the singular..
It has a parameter type which can primat value file or db
Depending on the parametr value the section <input> should contain the following subsections:
For file:
<name> - path to file. Example: /var/dbre/exchange/enterprise_database.lre
For db:
<type> - RDBMS type. It can take values: fb, mysql, oracle, odbc, postgre, sqlite
<server> - IP address or dns name of the server database
<database> - database name
<user> - database user
<password> - user password
<role> - The role of the user. Only RDBMS fb
<charset> - Charset. In accordance with the agreement for the selected database.

<output> - section of the output data source. Similarly <input>

<deleted> - section - the key. It may contain 1 or 0, and also absent. It is designed to activate unloading / loading of information on the deleted data. When the setting, the source database should contain a table deletedfields (More see
Extensions of source database)

<table> - section containing parameters unloading table. It may be present in any quantity (number needed to replicate the tables). It shall contain the following subsections:
<input_name> - table name in data source
<output_name> - table name in destination
<unloaded> - section - the key. It may contain 1 or 0 and also absent. Includes control regime unloading. When the regime in the source-database table must be present field unloaded (More see Extensions of source database). Unloaded only record the value NULL in this field. After discharge, they shall be 1.

<field> - section contains the parameters of table fields. It may be present in the section <table> in any quantity.
<input_name> - field name in the table data source
<output_name> - field name in the table data destination
<type> - type of field. It may take the following values:
string - by default
<index> - pointer that field is the key. It can take values 1, 0 or missing. To identify the records in the destination-database, for its renewal.
<autoinc> - pointer that field is the autoincrement. It can take values 1, 0 or missing. When enabled a field is not entered in the table of the receiver.

Example of configuration file

<?xml version="1.0" ?>
    <input type="file">
    <output type="db">

Extensions of source database

For additional features such as control unloaded and deleted records in the source-database the following additions should be made:
1. All table entries are to be monitored for unloading, should be added field unloaded:
alter table TABLE1 add UNLOADED char(1);
To reset the field at the time of recording the changes in the table you want to add a trigger for an event update:
create trigger TABLE1_BU0 for TABLE1
active before update position 0
    if (new.UNLOADED = old.UNLOADED) then
	new.UNLOADED = null;
2. For unloading information on deleted records in the database you want to add table deletedfields:
create table DELETEDFIELDS (TEXT varchar(255));
For the record, its data in each table must be controlled by adding a trigger to an event before delete:
create trigger TABLE1_BD0 for TABLE1
active before delete position 0
    insert into DELETEDFIELDS (TEXT) values ('TABLE1;ID:'||cast(old.ID as varchar(10))||';');
Trigger must enter the line to read: TABLE_NAME;KEY_FIELD_NAME1:VALUE;KEY_FIELD_NAMEN:VALUE;