Skip to content
≡

Administrator

Developer

Tools

External Tools

6. Database Replication#

Replication is the copying feature and transaction-log-based data in each other database setting an Active-Standby or Active-Active relationship between databases.

During operating the Altibase Replication function, a user can operate a system without shutting down the service when unexpected system interruption occurred.

This chapter introduces an overview of the replication features and how they operate.

Introduction to Replication#

The Altibase database replication function maintains an up-to-date backup of the database on an active server, and in the event that the server is unexpected terminated, immediately resumes service again from an identical database on an alternative server, so as to realize an operating environment in which uninterruptible service is provided.

For the appropriate operation of the database replication, We will explain the following order:

  • How Databases Are Replicated In Altibase

  • How To Use the Replication Function

For more detailed information of Replication, please refer to the Replication Manual.


How to Operate the Replication Function#

To use the replication function, a table must be defined first in order to be replicated. After determining replication properties such as a replication name, a primary and a port number, create a replication object between a local server and a remote server.

It then the replication with the remote server.

In both directions, replication can be done in both directions when the replication is started in the remote server.


How to Replicate a Database#

After performing the Altibase replication function, a local server transfers changed data logs in the system to a remote server, and a remote server commits corresponding logs in its own database.

The local server and the remote server run a thread of the managed Replication configuration without using the server thread.

These threads are distinct from the data service threads.

The replication Sender thread on the local server transmits the log of a changed database to the remote server. In addition, the Replication Receiver thread on the remote server receives the log of changed database and implements them in its database.

The replication Sender and Receiver threads automatically detect whether the corresponding servers were shut down normally or abnormally and take appropriate action.

Creating Replication Objects#

Replication to synchronize a local server with a remote server is defined as follows:

CREATE [LAZY|EAGER] REPLICATION replication_name [AS MASTER|AS SLAVE] 
       [OPTIONS options_name [option_name ... ] ] 
  WITH { 'remote_host_ip', remote_host_ port_no } 
       ...
  FROM user_name.table_name TO user_name.table_name
[,FROM user_name.table_name TO user_name.table_name]
       ...;

Starting Replication#

Replication is started in this way:

ALTER REPLICATION replication_name SYNC [PARALLEL parallel_factor] 
[TABLE user_name.table_name, … , user_name.table_name];

ALTER REPLICATION replication_name SYNC ONLY [PARALLEL parallel_factor] 
[TABLE user_name.table_name, … , user_name.table_name];

ALTER REPLICATION replication_name START [RETRY];

ALTER REPLICATION replication_name QUICKSTART [RETRY];

Stopping Replication#

Replication is stopped in this way:

ALTER REPLICATION replication_name STOP;

Resetting Replication#

This is how replication information is reset. Replication must be stopped before this is done: 

ALTER REPLICATION replication_name RESET;

Dropping Replication Tables#

This is how tables are dropped (deregistered) from a replication object. Replication must be stopped before this is done:

ALTER REPLICATION replication_name STOP;

ALTER REPLICATION replication_name 
DROP TABLE FROM user_name.table_name TO user_name.table_name;

Adding Replication Tables#

This is how tables are added to (registered with) a replication object. Replication must be stopped before this is done:

ALTER REPLICATION replication_name STOP;

ALTER REPLICATION replication_name 
ADD TABLE FROM user_name.table_name TO user_name.table_name;

Dropping a Replication Object#

This is how a replication object is dropped. If replication has been started, it must first be stopped before the replication object can be dropped:

ALTER REPLICATION replication_name STOP;

DROP REPLICATION replication_name;


Executing DDL Statements in a Replication Environment#

If the REPLICATION_DDL_ENABLE property is set to 1 on a replication server, the following DDL statements can be executed:

  • ALTER TABLE table_name ADD COLUMN;

  • ALTER TABLE table_name DROP COLUMN;

  • ALTER TABLE table_name ALTER COLUMN column_name SET DEFAULT;

  • ALTER TABLE table_name ALTER COLUMN column_name DROP DEFAULT;

  • ALTER TABLE table_name TRUNCATE PARTITION;

  • ALTER TABLE table_name ALTER PARTITION;

  • ALTER TABLE table_name SPLIT PARTITION partition_name(condition) INTO
    ( PARTITION partition_name, PARTITION partition_name);

  • ALTER TABLE table_name MERGE PARTITIONS partition_name, partition_name INTO PARTITION partition_name;

  • ALTER TABLE table_name ALTER TABLESPACE;

  • ALTER TABLE table_name ALTER PARTITION;

  • ALTER TABLE table_name DROP PARTITION partiton_name;

  • TRUNCATE TABLE;

  • CREATE INDEX;

  • DROP INDEX;

Please refer to Replication Manual for a complete list of the DDL statements that may be executed, as well as more information about restrictions pertaining to replication.

However, DDL statements that are not allowed in replication should be used after suspending or deleting replication according to the procedure. That is, in order to execute DDL statements that are not allowed during the replication operation for the tables included in the replication object, it is necessary to stop replication in two servers, delete the corresponding tables from replication, and execute DDL statements on the respective server. Then if the DDL statement is executed successfully, the table re-register in the replication and the replication is resumed.