3.Deploying Replication#

Considerations#

There are several conditions apply when establishing replication. If these conditions are not met, replication cannot be deployed.

Prerequisites#

If a conflict occurs during an INSERT, UPDATE, or DELETE operation, the operation is skipped, and a message is written to an error file.
If an error occurs during replication, partial rollback is performed. For example, if a duplicate row is found while inserting rows into a table, only the insertion of the duplicate row is canceled, while the remainder of the task is completed as usual.
Replication is much slower than the main data provision service

Connection Constraints#

The maximum number of replication connections possible from one Altibase database is determined by the REPLICATION_MAX_COUNT property.
The database character sets and the national character sets must be the same on both servers in order for replication to be possible. Which character set is currently in use can be checked by viewing the values of NLS_CHARACTERSET and NLS_NCHAR_CHARACTERSET in the V$NLS_PARAMETERS performance view.

Replication Target Column Constraints#

When an INSERT transaction is replicated, columns that are not replication targets will be filled with NULL values.
When configuring unique indexes and function-based indexes of a replicated column and a non-replicated column, it operates in the SQL apply mode.

Replication Constraints in EAGER Mode#

The following constraints apply to replication in EAGER mode.

To ensure data consistency, replication in EAGER mode is not recommended for more than three nodes.
Data is not synchronized unless replication is performed in EAGER mode on both the remote and local servers.
If a network failure occurs while replication is being performed in EAGER mode (and even if the server manages to service properly), data consistency cannot be guaranteed. This is because when a network failure occurs, each node interprets the failure as an error on the other node, and both nodes update data.
A table can only be replicated as a single corresponding table when replication is performed in EAGER mode. If a table is replicated into two or more tables in EAGER mode, data will be inconsistent and incremental synchronization will fail.
Servers on which replication is being performed must have their time synchronized. If an error occurs and the time has not been synchronized, replication can be defective due to the time difference at error detection.
Data can be lost if the server abnormally terminates before a committed XLog is applied on disk in EAGER mode. To prevent data loss, specify the recovery option or adjust the values for commit-related properties (COMMIT_WRITE_WAIT_MODE, REPLICATION_COMMIT_WRITE_WAIT_MODE, and REPLICATION_SYNC_LOG)
SQL apply mode is not available for replication in the EAGER mode.

Partitioned Table Constraints#

The following conditions must be met in order to successfully replicate partitioned tables.

The partitioning method must be the same on both the remote server and the local server.
For range or list partitions, the partitioning conditions must be the same. If only some partitions are to be replicated, the constraints on only those partitions need to be the same. The same applies to default partitions.
For hash partitions, the number of partitions must be the same.

Constraints on Using Replication for Data Recovery#

In order to use replication to perform data recovery, the following restrictions apply:
1. If both the local server and the remote server shut down abnormally, recovery using replication will not be possible.
2. Conflicting data cannot be recovered.
3. A single table cannot be recovered using two or more replication objects.
4. If transactions that have not been transferred are lost, the data cannot be recovered.

Additional Considerations when Using Replication for Data Recovery#

If different update operations are performed on the same record on two replicated systems in an Active-Active replication environment, data may be mismatched between the systems.
If a network error occurs or replication is stopped according to the setting of the REPLICATION_RECOVERY_MAX_TIME property by the user, data might not be recovered.

Allowed DDL Statements#

Normally, DDL statements cannot be executed on replication target tables. However, the following DDL statements can be executed on replication target tables.

ALTER INDEX REBUILD PARTITION
GRANT OBJECT
REVOKE OBJECT
CREATE TRIGGER
DROP TRIGGER

Note:#

When DDL statements that are allowed for use with replication are executed on tables, those tables are locked. If the Sender thread transfers a replication log at this time, the Receiver thread won’t be able to properly implement the log’s changes.

CREATE REPLICATION#

Before starting replication, corresponding replication objects must be created on two servers first.

Syntax#

CREATE [LAZY|EAGER] REPLICATION replication_name 
[FOR ANALYSIS | FOR PROPAGABLE LOGGING | FOR PROPAGATION | FOR ANALYSIS PROPAGATION] 
[AS MASTER|AS SLAVE] 
[OPTIONS options_name [option_name ... ] ] 
WITH { ‘remote_host_ip’, remote_host_ port_no [USING conn_type [ib_latency]]} 
...
FROM user_name.table_name [PARTITION partition_name] TO user_name.table_name [PARTITION partition_name]
[,FROM user_name.table_name [PARTITION partition_name] TO user_name.table_name [PARTITION partition_name]
...;

Prerequisites#

Only the SYS user can execute replication-related statements.

Description#

Before replication can be performed, a so-called "replication pair", comprising of a pair of replication objects between which a connection is established, must be set up.

Replication is conducted on a table-by-table or a partition-by-partition basis. Tables or partitions are matched one-to-one.

When creating a replication object, one of the LAZY and EAGER modes can be selected as the default mode. If the replication mode is not specified for a session, this default mode will be used. If no default mode is specified, replication will be performed in LAZY mode.

replication_name
This specifies the name of the replication object to be created. The same name must be used on both the local server and the remote server.
FOR ANALYSIS | FOR ANALYSIS PROPAGATION
This creates the Xlog Sender. For more detailed information about properties, please refer to the Log Analyzer User’s Manual.
FOR PROPAGABLE LOGGING | FOR PROPAGATION
Replication receiver writes the logs received with FOR PROPAGABLE LOGGING. FOR PROPAGATION is used to send propagable logs to other target server.

This function cannot be used with recovery option.

as master or as slave
This specifies whether the server is the Master or the Slave. If not specified, the value specified using the REPLICATION_INSERT_REPLACE or REPLICATION_UPDATE_REPLACE property will be used. When attempting to perform handshaking, the following combinations of values will be successful: 0 with 0, 1 with 2, and 2 with 1. Other combinations will fail. (0 = not set; 1 = Master; 2 = Slave)
remote_host_ip
This is the IP address of the remote server.
remote_host_port_no
This is the port number at which the remote server Receiver thread listens. More specifically, this is the port number specified in REPLICATION_PORT_NO in the altibase.properties file on the remote server.
conn_type
This is the communication method with a remote server (TCP/InfiniBand). The default value is TCP.
ib_latency
This is the RDMA_LATENCY option value for rsocket. It can be only inserted when conn_type is IB
user_name
This is the name of the owner of the table to be replicated.
table_name
This is the name of the table to be replicated.
partition_name
This is the name of the partition to be replicated.
option_name
This is the name of the additional functions pertaining to the replication object. For more detailed information, please refer to Extra Features

Error Codes#

Please refer to the Altibase Error Message Reference.

Example#

Suppose that the IP address and port number of the local server are 192.168.1.60 and 25524, and that the IP address and port number of the remote server are 192.168.1.12 and 35524. To replicate a table called employees and one called departments between the two servers, the required replication definition would be as follows:

Local server (IP: 192.168.1.60)

iSQL> CREATE REPLICATION rep1
    WITH '192.168.1.12', 35524
    FROM sys.employees TO sys.employees,
    FROM sys.departments TO sys.departments;
Create success.

Remote Server (IP: 192.168.1.12)

iSQL> CREATE REPLICATION rep1
    WITH '192.168.1.60', 25524
    FROM sys.employees TO sys.employees,
    FROM sys.departments TO sys.departments;
Create success.

Starting, Stopping and Modifying Replication using “ALTER REPLICATION”#

Syntax#

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

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

ALTER REPLICATION replication_name START [RETRY];

ALTER REPLICATION replication_name QUICKSTART [RETRY];

ALTER REPLICATION replication_name STOP; 

ALTER REPLICATION replication_name RESET;

ALTER REPLICATION replication_name DROP TABLE 
FROM user_name.table_name [PARTITION partition_name] TO user_name.table_name [PARTITION partition_name];

ALTER REPLICATION replication_name ADD TABLE 
FROM user_name.table_name [PARTITION partition_name] TO user_name.table_name [PARTITION partition_name]

ALTER REPLICATION replication_name FLUSH [ALL] [WAIT timeout_sec];

Prerequisites#

Only the SYS user can execute replication-related statements.

Description#

SYNC
After all of the records in the table to be replicated have been transmitted from the local server to the remote server, replication starts from the current position in the log. In order to prevent another transaction from changing data in the table on which synchronization is to be performed right at the time of determination of the log from which replication will start after synchronization, the Replication Sender Thread obtains an S Lock on the table on which synchronization is to be performed for a short time before synchronization. Therefore, if a synchronization attempt is made while another transaction is updating data in the table to be synchronized, the Replication Sender Thread will wait for the amount of time specified in the REPLICATION_SYNC_LOCK_TIMEOUT property, and will then start replication at the time at which the change transaction ends. If the change transaction is not completed within the amount of time specified in the REPLICATION_SYNC_LOCK_TIMEOUT property, synchronization will fail. If, during synchronization, records on the local server are found to have the same primary key values as records on the remote server, any conflicts are eliminated according to the rules for conflict resolution.
TABLE
This specifies the table that is the target for SYNC replication.
PARTITION
This specifies the partition that is the target for SYNC replication.
PARALLEL
Parallel_factor may be omitted, in which case a value of 1 is used by default. The maximum possible value of parallel_factor is the number of CPUs * 2. If it is set higher than this number, the maximum number of threads that can be created is still equal to the number of CPUs * 2. If it is set to 0 or a negative number, an error message results.
SYNC ONLY
All records in replication target tables are sent from the local server to the remote server. (In this case the Sender thread is not created.) If the same records exist on both the local server and the remote server, sources of conflict are eliminated according to the rules for conflict resolution.

Because only a single thread is responsible for handling SYNC or SYNC ONLY on disk tables, when some of the tables on which SYNC replication is to be performed are disk tables, setting parallel_factor higher than the number of disk tables confers a performance advantage.
START
Replication will start from the time point of the most recent replication.
QUICKSTART
Replication will start from the current position in the log.
START/QUICKSTART RETRY
When starting or quickstarting replication with the RETRY option, even if handshaking fails, a Sender Thread is created on the local server. Afterwards, once handshaking between the local server and the remote server is successful, replication starts.

iSQL shows a success message even if the first handshake attempt fails. Therefore, the user must check the result of execution of this command by checking the trace logs or the V$REPSENDER performance view.

When starting replication without the RETRY option, if the first handshake attempt fails, an error is raised and execution is stopped.
STOP
This stops replication. If a SYNC task is stopped, the transmission of all data to be replicated to the remote server cannot be guaranteed. If a SYNC replication that is underway is stopped, in order to perform SYNC again, all records must be deleted from all replication target tables, and then the SYNC is performed again.
RESET
This command resets replication information (such as the restart SN (Sequence Number)). It can only be executed while replication is stopped, and can be used instead of executing DROP REPLICATION followed by CREATE REPLICATION.
DROP TABLE
This command excludes a table or a partition from a replication object. It can only be executed while replication is stopped. Because regular DDL statements cannot be executed on replication target tables, after a table is excluded from a replication object, DDL statements can be executed on the table or a partition.
ADD TABLE
This command adds a table or a partition to a replication object. It can only be executed while replication is stopped.
FLUSH
The current session waits for the number of seconds specified by timeout_sec so that the replication Sender thread can send logs up to the log at the time at which the FLUSH statement is executed to the other server. If used together with the ALL keyword, the current session waits until the most recent log, rather than the log at the time at which the FLUSH statement is executed, is sent to the other server

Error Codes#

Please refer to the Error Message Reference.

Example#

Assuming that the name of a replication is rep1, replication can be started in one of the following three ways:

Replication is started after the data on the local server are transferred to the remote server.

iSQL> ALTER REPLICATION rep1 SYNC;
Alter success.

Replication is started from the time point at which the replication rep1 was most recently executed.

iSQL> ALTER REPLICATION rep1 START;
Alter success.

Replication is started from the current time point.

iSQL> ALTER REPLICATION rep1 QUICKSTART;
Alter success.

Use the following commands to check the status of replication after it has started.

(Executing on a local server)

iSQL> SELECT rep_name, status, net_error_flag, sender_ip, sender_port,
             peer_ip, peer_port 
      FROM V$REPSENDER;
REP_NAME                                  STATUS               
------------------------------------------------------------------
NET_ERROR_FLAG       
-----------------------
SENDER_IP                                                         SENDER_PORT
---------------------------------------------------------------------------
PEER_IP                                                           PEER_PORT   
---------------------------------------------------------------------------
REP1                                      1                    
0                    
192.168.1.33                                                      11477       
192.168.1.34                                                      21300       
1 row selected.

(Executing on a remote server)

iSQL> SELECT rep_name, my_ip, my_port, peer_ip, peer_port 
      FROM V$REPRECEIVER;
REP_NAME                                  
--------------------------------------------
MY_IP                                                             MY_PORT     
---------------------------------------------------------------------------
PEER_IP                                                           PEER_PORT   
---------------------------------------------------------------------------
REP1                                      
192.168.1.33                                                      21300       
192.168.1.34                                                      7988        
1 row selected.

Assuming that the name of a replication is rep1, use the following command to stop replication.

iSQL> ALTER REPLICATION rep1 STOP;
Alter success.

Assuming that the name of a replication is rep1, use the following commands to drop a table from a replication object.

iSQL> ALTER REPLICATION rep1 STOP;
Alter success.
iSQL> ALTER REPLICATION rep1 DROP TABLE FROM sys.employees TO sys.employees;
Alter success.

Assuming that the name of a replication is rep1, use the following commands to add a table to a replication object.

iSQL> ALTER REPLICATION rep1 STOP;
Alter success.
iSQL> ALTER REPLICATION rep1 ADD TABLE FROM sys.employees TO sys.employees;
Alter success.

If it is desired to check the cumulative time that each Sender replication object has spent waiting for WAIT_NEW_LOG events, execute the following query. This example assumes that the TIMER_THREAD_RESOLUTION property has been set to 1,000,000 microseconds.

select rep_name, avg(WAIT_NEW_LOG)/1000000 from x$repsender_statistics where wait_new_log > 0 group by rep_name order by rep_name;

If it is desired to check the cumulative time that each Receiver replication object has spent waiting for INSERT_ROW events, execute the following query. This example assumes that the TIMER_THREAD_RESOLUTION property has been set to 1,000,000 microseconds

select rep_name, avg(INSERT_ROW)/1000000 from x$repreceiver_statistics where recv_xlog > 0 group by rep_name order by rep_name;

DROP REPLICATION#

Syntax#

DROP REPLICATION replication_name;

Prerequisites#

Only the SYS user can execute replication-related statements.

Description#

This command is used to remove a replication object.

However, once a replication has been dropped, it cannot be executed using ALTER REPLICATION START. Additionally, in order to drop a replication object, it is first necessary to stop it using ALTER REPLICATION STOP.

Error Codes#

Please refer to the Error Message Reference.

Example#

In the following example, a replication object named rep1 is removed.

iSQL> ALTER REPLICATION rep1 STOP;
Alter success.
iSQL> DROP REPLICATION rep1;
Drop success.

If an attempt is made to remove a replication object without first stopping it, the following error message appears.

iSQL> DROP REPLICATION rep1;
[ERR-610FE : Replication has already started.]

Executing DDL Statements on Replication Target Tables#

Allowed DDL Statements#

Altibase supports three types of DDL statements for replication target tables.

DDL statements without REPLICATION_DDL_ENABLE/REPLICATION_DDL_ENABLE_LEVEL settings.#

ALTER INDEX index_name AGING;
ALTER TABLE table_name COMPACT;

DDL statements with REPLICATION_DDL_ENABLE_LEVEL = 0#
Columns including NOT NULL/NULL, Unique constraints, or function-based index cannot be added/deleted.
A unique/function-based index cannot be deleted.

ALTER TABLE table_name ADD COLUMN ( column_name DATA_TYPE ); 
// Columns including NOT NULL,NULL,Unique or function-based index cannot be added
ALTER TABLE table_name DROP COLUMN column_name; 
// Columns including NOT NULL,NULL,Unique or function-based index cannot be deleted
ALTER TABLE table_name ALTER COLUMN column_name SET DEFAULT;
ALTER TABLE table_name ALTER COLUMN column_name DROP DEFAULT;

ALTER TABLE table_name ALTER TABLESPACE tablespace_name;
ALTER TABLE table_name ALTER PARTITION partition_name TABLESPACE;
ALTER TABLE table_name TRUNCATE PARTITION partition_name;

TRUNCATE TABLE table_name;

CREATE INDEX index_name ON table_name ( column_name );
DROP INDEX index_name; //Unique or function-based index cannot be deleted.

DDL statements with REPLICATION_DDL_ENABLE_LEVEL = 1 #

ALTER TABLE table_name ADD COLUMN ( column_name DATA_TYPE NOT NULL );
ALTER TABLE table_name ADD COLUMN ( column_name DATA_TYPE UNIQUE );
ALTER TABLE table_name ADD COLUMN ( column_name DATA_TYPE LOCALUNIQUE );
ALTER TABLE table_name ALTER COLUMN ( column_name NOT NULL );
ALTER TABLE table_name ALTER COLUMN ( column_name NULL );
ALTER TABLE table_name MODIFY COLUMN ( column_name DATA_TYPE );
ALTER TABLE table_name MODIFY COLUMN ( column_name NULL );
ALTER TABLE table_name MODIFY COLUMN ( column_name NOT NULL );
ALTER TABLE table_name DROP COLUMN column_name; // Columns including NOT NULL,NULL,Unique or function-base index can be deleted

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 DROP PARTITION partiton_name; 

ALTER TABLE table_name ADD CONSTRAINT constraint_name UNIQUE ( column_name );
ALTER TABLE table_name ADD CONSTRAINT constraint_name UNIQUE ( column_name ) LOCAL;
ALTER TABLE table_name RENAME CONSTRAINT constraint_name TO constraint_name;
ALTER TABLE table_name DROP CONSTRAINT constraint_name; // Constraints including Unique or Local Unique can be deleted 

CREATE UNIQUE INDEX index_name ON table_name ( column_name );
CREATE INDEX index_name ON table_name ( expression );
DROP INDEX index_name; //Unique or function-base index can be deleted

Description#

Altibase supports the execution of DDL statements on replication target tables. However, the following property settings must be set

The REPLICATION_DDL_ENABLE property must be set to 1.
The REPLICATION_DDL_ENABLE_LEVEL to the desired level.
ALTER SESSION SET REPLICATION as DEFAULT.
The target table should be locked by the LOCK TABLE...UNTIL NEXT DDL statement in order to execute SPLIT PARTITION, MERGE PARTITION, and DROP PARTITION on a replication target table. Moreover, the data should be checked to identify since there would be a replication gap between the local and remote server.

If users execute the SPLIT, MERGE, or DROP PARTITION on a replication target partition, users must execute the same DDL statements on remote servers. And, newly created or deleted partitions are automatically added or removed as a replication target partition.

Restrictions#

DDL statements cannot be executed on tables for which the replication recovery option has been specified. To execute DDL statements in such a case, drop the tables from the replication object and execute the DDL statements. Furthermore, DDL statements cannot be executed while replication is running in EAGER mode. To execute DDL statements in such a case, stop replication, execute the DDL statements, and start replication again.

The restrictions that govern the use of particular DDL statements are as follows:

ALTER TABLE table_name ADD COLUMN
-A unique index cannot be added.
-A compressed column cannot be added.
ALTER TABLE table_name DROP COLUMN
-A primary key cannot be dropped.
-A compressed column cannot be dropped.
ALTER TABLE table_name [SPLIT | MERGE | DROP] PARTITION...
-Replication cannot be executed during the operation.
-LOCK TABLE is executed on a target table.
-The replication target should identify the replication gap between the local and remote server. In order to relieve the replication gap, the FLUSH ALL option of replication should be executed before executing a DDL statement.
-MERGE target partition should exists in all the replication target objects. There should be more than two partitions or tables in the replication object in order for DROP PARTITION to be executed.
TRUNCATE TABLE -This is supported only for tables without compressed columns.

Example#

Supposing that the name of a replication target table is t1, DDL statements can be executed on the replication target table as follows

Execute the TRUNCATE TABLE statement

(SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 1;
Alter success.
(Table Owner)
iSQL> ALTER SESSION SET REPLICATION = DEFAULT;
Alter success.
iSQL> TRUNCATE TABLE t1;
Truncate success.
(SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 0;
Alter success.

(SPLIT TABLE) Create a table T1 by splitting partition P3 and P4 in partition P2.

iSQL> LOCK TABLE T1 UNTIL NEXT DDL;
iSQL> ALTER REPLICATION REP1 FLUSH ALL;
iSQL> ALTER REPLICATION REP1 STOP;
iSQL> ALTER TABLE T1 SPLIT PARTITION P2 
       INTO (PARTITION P3, PARTITION P4 );

(MERGE TABLE) Create a table T1 by merging partition 2 and 3 in partition P2 and P3.

iSQL> LOCK TABLE T1 UNTIL NEXT DDL;
iSQL> ALTER REPLICATION REP1 FLUSH ALL;
iSQL> ALTER REPLICATION REP1 STOP;
iSQL> ALTER TABLE T1 MERGE PARTITIONS P2, P3 INTO PARTITION P23;

(DROP TABLE). Drop the partition P1.

iSQL> LOCK TABLE T1 UNTIL NEXT DDL;
iSQL> ALTER REPLICATION REP1 FLUSH ALL;
iSQL> ALTER REPLICATION REP1 STOP;
iSQL> ALTER TABLE T1 DROP PARTITIONS P1;

Executing DDL Synchronization on Replication Target Tables#

Altibase supports the DDL synchronization feature. DDL synchronization means replicating the execution of DDL statements. With this feature, DDL statements that run on one node are automatically executed on the other nodes as well. The following prerequisites and property configurations are required. The detailed procedure is explained below.

Restrictions of DDL Synchronization#

The following conditions must be satisfied for DDL synchronization.

To replicate DDL statements, the replication protocol versions of local and remote servers should be identical.
To replicate DDL statements, replication of local and remote servers should be started in advance.
The name of the DDL statements replication target table(partition), and user name must be the same on both local and remote servers.
The DDL statements replication target table must be part of the LAZY mode replication.
When the DDL statements replication target is a partitioned table, DDL synchronization cannot be executed if the table has a Global Non-Partitioned index.
When using the propagation option, DDL synchronization is not allowed.
For the table with a replication recovery option, DDL synchronization is not allowed.

How to Use#

This section describes how to use DDL synchronization. DDL statement is executed on the local server, and DDL synchronization is automatically executed on the remote server.

Prerequisites on the User Environment#

Move operating services

Services that manipulate (Insert/Delete/Update) data during active operations should be moved to the local server, where DDL statements are executed to prevent potential data inconsistency.

Notes

If services that manipulate (Insert/Delete/Update) are executed on the remote server, data inconsistency may occur.

Remove the replication gap of the remote server

Users can remove the replication gap with statements below:

ALTER REPLICATION Replication_name1 FLUSH;
ALTER REPLICATION Replication_name2 FLUSH;
ALTER REPLICATION Replication_name... FLUSH;

Prerequisites on the Local Server#

Only the SYS user can set the properties for DDL statement execution. SYS user should run the following property configuration statements on the local server that executes DDL statements. About the REPLICATION_DDL_ENABLE_LEVEL property, please refer to "Allowed DDL statements" for a more specific configuration.

ALTER SYSTEM SET REPLICATION_DDL_ENABLE=1;
ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL=1;

// Execute the following statements as SYS user or Table Owner.
ALTER SESSION SET REPLICATION_DDL_SYNC=1;
ALTER SESSION SET REPLICATION=DEFAULT;

Prerequisites on the Remote Server#

For the remote server where DDL replication will be (automatically) executed, perform the following property configuration statements. If REPLICATION_DDL_ENABLE_LEVEL is set to 1, REPLICATION_SQL_APPLY_ENABLE must also be set to 1.

ALTER SYSTEM SET REPLICATION_DDL_ENABLE=1;
ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL=1;
ALTER SYSTEM SET REPLICATION_DDL_SYNC=1;
// The below statement can be omitted if REPLICATION_DDL_ENABLE_LEVEL is 0.
ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE=1;

Execute DDL statements#

To remove the replication gap on the local server, run the following statements before the execution of DDL statements. Replication_name1 and Replication_name2 refer to all replication objects related to DDL statement execution.

ALTER REPLICATION Replication_name1 FLUSH;
ALTER REPLICATION Replication_name2 FLUSH;
ALTER REPLICATION Replication_name... FLUSH;

Allowed DDL statements#

Please refer to "Allowed DDL statements".

Disallowed DDL Statements#

DDL statement that deletes a primary key.
DDL statement that adds a foreign key.
DDL statement that adds or deletes a compressed column.
DDL statement that truncates the table which has a compressed column.

Notes

During the progress of DDL replication, updates to the table undergoing DDL statements might be temporarily restricted. In such cases, try the update again after the completion of DDL statements replication, then the process will succeed.

For example, if users try to a DML statement such as 'INSERT INTO t1 VALUES ...' while the DDL replication is running on table t1, the system shows the error message as below:

[ERR-313D6 : Unable to update table or partition T1].

Post-Action(Properties Restoration)#

When the execution of DDL statements is completed, and there are no more DDL statements to be executed, users need to restore the previously changed property configurations. At this point, there might be replication gaps related to DDL processing on the local server. To address this, it is essential to perform a FLUSH operation.

Local server
To remove the replication gap related to DDL processing, run FLUSH as follows:

ALTER REPLICATION Replication_name1 FLUSH;
ALTER REPLICATION Replication_name2 FLUSH;
ALTER REPLICATION Replication_name... FLUSH;

After FLUSH operations, restore the property configurations as follows:

ALTER SYSTEM SET REPLICATION_DDL_ENABLE=0;
ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL=0;
ALTER SESSION SET REPLICATION_DDL_SYNC=0;

Remote server

ALTER SYSTEM SET REPLICATION_DDL_ENABLE=0;
ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL=0;
ALTER SYSTEM SET REPLICATION_DDL_SYNC=0;
// The below statement can be omitted if REPLICATION_DDL_ENABLE_LEVEL is 0.
ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE=0;

Examples#

Suppose that the table t1 is the replication target and the REPLICATION_DDL_ENABLE_LEVEL is set to 0. The following example shows how the DDL statements replication is executed.
Run TRUNCATE TABLE

// Change the prerequisite properties
(Remote SYS User)
iSQL> ALTER REPLICATION rep1 FLUSH;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 1;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_SYNC = 1;

(Local SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 1;
iSQL> ALTER SESSION SET REPLICATION_DDL_SYNC = 1;
iSQL> ALTER REPLICATION rep1 FLUSH;

// Execute DDL statements
(Local Table Owner)
iSQL> ALTER SESSION SET REPLICATION = DEFAULT;
iSQL> TRUNCATE TABLE t1;

// Restore the changed properties
(Local SYS User)
iSQL> ALTER REPLICATION rep1 FLUSH;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 0;
iSQL> ALTER SESSION SET REPLICATION_DDL_SYNC = 0;

(Remote SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 0;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_SYNC = 0;

In a triple-replication environment where the replication target table is t1 and t1 has a column c1, refer to the following example. (Assuming replication between the local server and remote server 1, between the local server and remote server 2, and between remote server 1 and remote server 2 as rep1, rep2, and rep3, respectively.)
Run ALTER TABLE t1 ALTER COLUMN ( c1 NOT NULL )

// Change the prerequisite properties
(Remote1 SYS User)
iSQL> ALTER REPLICATION Rep1 FLUSH;
iSQL> ALTER REPLICATION Rep3 FLUSH;
(Remote2 SYS User)
iSQL> ALTER REPLICATION Rep2 FLUSH;
iSQL> ALTER REPLICATION Rep3 FLUSH;

(Local SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 1;
iSQL> ALTER SESSION SET REPLICATION_DDL_SYNC = 1;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL = 1;
(Remote1 SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 1;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_SYNC = 1;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL = 1;
iSQL> ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE = 1;
(Remote2 SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 1;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_SYNC = 1;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL = 1;
iSQL> ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE = 1;

(local SYS User)
iSQL> ALTER REPLICATION Rep1 FLUSH;
iSQL> ALTER REPLICATION Rep2 FLUSH;

// Execute DDL statements
(Local Table Owner)
iSQL> ALTER SESSION SET REPLICATION = DEFAULT;
iSQL> ALTER TABLE t1 ALTER COLUMN ( c1 NOT NULL );

// Restore the changed properties
(local SYS User)
iSQL> ALTER REPLICATION Rep1 FLUSH;
iSQL> ALTER REPLICATION Rep2 FLUSH;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 0;
iSQL> ALTER SESSION SET REPLICATION_DDL_SYNC = 0;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL = 0;

(Remote1 SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 0;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_SYNC = 0;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL = 0;
iSQL> ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE = 0;

(Remote2 SYS User)
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE = 0;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_SYNC = 0;
iSQL> ALTER SYSTEM SET REPLICATION_DDL_ENABLE_LEVEL = 0;
iSQL> ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE = 0;

SQL Apply Mode#

When the information of meta of local server and remote is different. Log can be converted to SQL and reflected on a remote server. When reflecting to a remote server in SQL mode, the following conditions are possible:

REPLICATION_SQL_APPLY_ENABLE : 1
Column information
If the data types are different
If size, precision, and scale are different
Constraints
if the check constraints are different
if the not null constraints are different
Indexes
When a unique index or a function-based index consists of columns to be replicated and columns not to be replicated
If the configuration information for the unique index is different
If the configuration information for the function-based index is different

Restriction#

SQL apply mode only works in LAZY mode
If there is a security column in the table, it will not operate SQL apply mode.

Note*:#

Since converting XLog to SQL to reflect is slow, it is recommended to use it only temporarily.

Extra Features#

Altibase provides the following extra replication features:

Recovery Option
Offline Option
Replication Gapless Option
Parallel Applier Option
Replicated Transaction Grouping Option
Meta Logging Option

The status of replication option can be confirmed by the value of the OPTIONS column in SYS_REPLICATIONS_meta table. Please refer to the General Reference for in-depth information.

Recovery Option#

Syntax#

ALTER REPLICATION replication_name SET RECOVERY {ENABLE|DISABLE};

Description#

If abnormal server termination occurs during the replication, the user can recover data by using the main transaction which was executed in normally operating server or replicated transaction logs.

This feature is highly efficient if transaction logs are specified not to be written to disk in COMMIT_WRITE_WAIT_MODE or REPLICATION_COMMIT_WRITE_WAIT_MODE property. For example, a committed transaction can be lost if the system is abnormally shut down. However, in that case, the lost data can be consistent by the replication recovery option.

However, the recovery option cannot be changed while the replication is being processed. In case of not using the recovery option, the recovery related materials the system retains are all released.

Please refer to the General Reference for in-depth information on properties.

Restriction#

The recovery option cannot be used at the same time with the offline option.

Example#

Assuming that the name of a replication object is rep1, the replication recovery option is used as follows:

To enable the replication recovery option:

iSQL> ALTER REPLICATION rep1 SET RECOVERY ENABLE;
Alter success.

To disable the replication recovery option:

iSQL> ALTER REPLICATION rep1 SET RECOVERY DISABLE;
Alter success.

Offline Option#

Syntax#

ALTER REPLICATION replication_name 
SET OFFLINE ENABLE WITH 'log_dir';
ALTER REPLICATION replication_name SET OFFLINE DISABLE;
ALTER REPLICATION replication_name START WITH OFFLINE;

Description#

One of the other extra replication features provided with Altibase is the offline option. In an Active-Passive replication environment, when a server providing service (the “Active“ server) develops a fault, the logs cannot be sent to the remote (“Standby“) server. The use of offline replication allows the logs that could not be sent to the Standby Server before the fault occurred to be accessed by and implemented in the Standby Server afterwards. If the Standby Server directly accesses the log files on the Active Server by copying the files via FTP or using a shared disk file system, a network file system, etc, the logs that could not be sent can be processed using the OFFLINE option. However, the Standby Server can use the offline option only if the Active Server has performed replication on the Standby Server side.

log_dir
This enables the Standby Server to access the log files directly by specifying the log path on the Active Server.
START WITH OFFLINE
This allows replication to take place using the specified offline path. Offline replication is a one-time operation which is terminated as soon as all the unsent logs are applied. The replication Sender and Receiver threads that were being executed on the Standby Server are automatically terminated when this command is issued. Replication can be restarted once offline replication is terminated.
SET OFFLINE DISABLE
This disables the offline replication option. This statement can only be executed while replication is stopped.

The below figure is an example of the offline option in use.

[Figure 3-1] Data Accordance Between Both Servers

Offline Option Restrictions#

This option can only be used when executing replication in LAZY mode.
Offline replication is not supported for replication objects which designate compressed tables as replication targets.
The offline option cannot be used at the same time as the recovery option.
At the moment that offline replication starts, any replication Receiver thread having the same replication_name must be in a stopped state. If such a thread is still running, offline replication will terminate.
If the log file directory on the Active Server cannot be accessed due to a disk error, offline replication will fail.
The size of the log files on the Active and Standby Servers must be the same. Before the offline option is used, it must be ensured that the size of the log files is the same as the size that was specified at the time that the database was created.
If the user changes log files arbitrarily (i.e. renames or deletes them, or copies log files from another system), abnormal shutdown or some other problem may occur.
The Standby Server should not be restarted before starting offline replication, because the information used to analyze the logs that could not be received will disappear when starting up the Standby Server.
If the unsent logs contain DDL statements with REPLICATION_DDL_ENABLE_LEVEL = 1, the user must set the REPLICATION_SQL_APPLY_ENABLE property to 1 so that Altibase operates in SQL apply mode.
Option compatibility between different Altibase versions or Altibase and heterogeneous database

Offline replication or creating replication object with offline option fails if it does not meet the compatibility condition

All three digits of the binary DB version (Major, Minor, Patch) should be the same.

Binary DB version can be found in two ways.
1. SELECT SM_VERSION FROM V$VERSION;
2. altibase -v
LOG_FILE_SIZE should be the same.

Log file size can be found by this following syntax. SELECT NAME, VALUE1 FROM V$PROPERTY WHERE NAME = 'LOG_FILE_SIZE';
Offline replication between heterogeneous databases is not supported. Operating system, CPU type and CPU bit should be the same.

Example#

Assuming that the name of a replication object is rep1 and that the path of Active Server logs is active_server/altibase_home/logs, the offline option is used as follows:

Set the offline option when creating a replication object:

iSQL>CREATE REPLICATION REP1 OPTIONS OFFLINE 'actiive_server/altibase_home/logs'
WITH '127.0.0.1',20300 FROM SYS.A TO SYS.B;

Set the offline option for an existing replication object:

iSQL>ALTER REPLICATION REP1 SET OFFLINE ENABLE WITH 'active_server/altibase_home/logs';

Set the property to enable Altibase to operate in SQL apply mode:

iSQL>ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE = 1;

Execute offline replication using the specified path:

iSQL>ALTER REPLICATION REP1 START WITH OFFLINE;

Restore the property settings to disable Altibase to operate in SQL apply mode:

iSQL>ALTER SYSTEM SET REPLICATION_SQL_APPLY_ENABLE = 0;

Specify that the offline option is not to be used:

iSQL>ALTER REPLICATION REP1 SET OFFLINE DISABLE;

Replication Gapless Option#

Syntax#

CREATE REPLICATION replication_name OPTIONS GAPLESS ...;
ALTER REPLICATION replication_name SET GAPLESS [ENABLE|DISABLE};

Description#

The replication gapless option dissolves replication gaps. If this option is specified and the sender expects the replication gap to still exist after the amount of time set for the REPLICATION_GAPLESS_ALLOW_TIME property, the transaction commit is delayed to buy time for the replication gap to dissolve. The user can set an appropriate value for the REPLICATION_GAPLESS_MAX_WAIT_TIME property to prevent too much time being spent waiting for the replication gap to dissolve before committing the transaction. However, the user should be reminded that delaying transaction commits can degrade service performance.

For more detailed information about properties, please refer to the General Reference.

Restriction#

The replication gapless option can only be specified when replication is being performed in LAZY mode.

Example#

Assume that there is a replication object named rep1. Specify the replication gapless option to dissolve the replication gap for rep1.

Specify the replication gapless option.

iSQL> CREATE REPLICATION rep1 OPTION GAPLESS;
WITH '192.168.1.12', 35524
FROM sys.employees TO sys.employees,
FROM sys.departments TO sys.departments;;
CREATE success.

Enable the gapless option.

iSQL> ALTER REPLICATION rep1 SET GAPLESS ENABLE;
Alter success.

Parallel Applier Option#

Syntax#

CREATE REPLICATION replication_name OPTIONS PARALLEL receiver_applier_count [buffer_size]...;
ALTER REPLICATION replication_name SET PARALLEL receiver_applier_count [buffer_size];

Description#

The parallel applier creates several appliers that are to apply XLogs to the Storage Manager. The parallel receiver applier option enhances replication performance.

XLogs that the sender sends to the receiver are distributed to the applier in the unit of transactions, so that the XLogs can be applied in parallel. DML statements are executed in parallel and this enhances replication performance.

Parallel execution requires the synchronization of transaction commits among the parallel appliers to ensure data consistency. During this synchronization process, all threads other than the appliers that are committing transactions wait; the user can anticipate more performance enhancement with a shorter synchronization process. Likewise, the user can anticipate performance degradation if the number of concurrently running transactions is smaller than the number of appliers, because appliers can only execute DML statements under concurrently running transactions, and this would incur unnecessary applier management.

The parallel receiver applier option is suitable for replications with long-running transactions. Replications with short-running transactions encounter frequent synchronization processes for transaction commits; specifying this option would naturally degrade performance.

receiver_applier_count indicates the number of parallel appliers and can take a value between 0~512. If this value is set to 0, there will be no parallel appliers; in this case, receivers will do the appliers’ job.

Receivers and appliers use queues to pass XLogs. The REPLICATION_RECEIVER_APPLIER_QUEUE_SIZE property determines the maximum number of XLogs that can be sent. If no value is entered, the value is set according to the following property.

The buffer_size property specifies the initial size of the queue. Values range from 0 to 1 TB. If this value is not specified or if the number of parallel applier queues is less than the property REPLICATION_RECEIVER_APPLIER_QUEUE_SIZE value, the number of parallel applier queues is set to the value specified in the property REPLICATION_RECEIVER_APPLIER_QUEUE_SIZE.

If the unit (K, M, G) is not input, it is recognized in units of Megabytes.

For more detailed information about properties, please refer to the General Reference.

Example#

iSQL> CREATE REPLICATION replication_name OPTIONS PARALLEL receiver_applier_count 100M...;
iSQL> ALTER REPLICATION replication_name SET PARALLEL receiver_applier_count 100;

Restriction#

The parallel receiver applier option can only be specified when replication is being performed in LAZY mode.

Replicated Transaction Grouping Option#

Syntax#

CREATE REPLICATION replication_name OPTIONS GROUPING...;
ALTER REPLICATION replication_name SET GROUPING [ENABLE|DISABLE];

Description#

The replication transaction grouping option accumulates multiple transactions into single groups to reduce the number of transactions to be replayed.

If the replication transaction grouping option has been specified and a replication gap occurs, the Ahead Analyzer which analyzes logs (before the sender does) and creates replication transaction groups, is created. The Ahead Analyzer analyzes as many XLogs as the value set for the REPLICATION_GROUPING_AHEAD_READ_NEXT_LOG_FILE property and starts with the file of the second largest number to the log file being analyzed by the sender. The REPLICATION_GROUPING_TRANSACTION_MAX_COUNT property determines the maximum number of transactions that can be accumulated into single replication transaction groups.

Replication transactions are accumulated into two types of groups: committed transactions and rolled back transactions. The sender converts groups of committed transactions into a single transaction, whereas the sender does not send the XLogs for rolled-back transactions.

For more detailed information about properties, please refer to the General Reference.

Restriction#

The replication transaction grouping option can only be specified when replication is being performed in LAZY mode.

Meta Logging Option#

Syntax#

CREATE REPLICATION replication_name FOR ANALYSIS OPTIONS META_LOGGING...;

Description#

The meta logging option records the sender meta and Restart SN information into files created within the ala_meta_files folder in the log file path. These files are needed when the offline option of Adapter for JDBC and Adapter for Oracle utilities is executed.

Offline Option of Adapter for JDBC and Adapter for Oracle The offline option helps the Standby server access the unsent log files in the Altibase server where the failure occurs directly, and apply them to the other databases. For more detailed information, please refer to the Adapter for JDBC User’s Manual, and the Adapter for Oracle User’s Manual.

To specify this option, the replication object should be created with the Log Analyzer role.

Replication in a Multiple IP Network Environment#

Replication is supported in a multiple IP network environment. In other words, it is possible to perform replication between two hosts having two or more physical network connections.

Syntax#

CREATE REPLICATION replication_name {as master|as slave} 
WITH 'remotehostip', remoteportno 'remotehostip', remoteportno …
FROM user.localtableA TO user.remotetableA,
FROM user.localtableB TO user.remotetableB, …, 
FROM user.localtableC TO user.remotetableC;

ALTER REPLICATION replication_name
ADD HOST ‘remote_host_ip‘, remote_port_no [USING conn_type [ib_latency]];

ALTER REPLICATION replication_name
DROP HOST ‘remotehostip‘, remoteportno;

ALTER REPLICATION replication_name
SET HOST ‘remotehostip‘, remoteportno;

Description#

In order to ensure high system performance and quickly overcome faults, systems can have multiple physical IP addresses assigned to them when a replication object is created. In such an environment, the Sender thread uses the first IP address to access peers and perform replication tasks when replication starts, but if a problem occurs while this task is underway, the Sender thread stops using this connection, connects using another IP address, and tries again.

CREATE REPLICATION
The name of the replication object is first specified, and then in the WITH clause, the IP addresses and reception ports of multiple remote servers are specified, with commas between each IP address and port, and with spaces between address/port pairs defining each host. The owner and name of the target table(s) on the local server are specified in the FROM clause and the owner and name of the corresponding target table(s) on the remote server are specified in the TO clause, with commas between multiple table specifications.
ALTER REPLICATION (ADD HOST):
This adds a host. A host can be added to a replication object after the replication object has been stopped. When ADD HOST is executed, before the Sender thread actually adds the host, the connection must be re-established using the IP address that was previously being used
conn_type
This is the communication method with a remote server (TCP/InfiniBand). The default is TCP.
ib_latency
This is the RDMA_LATENCY option value for rsocket. It can only be entered when conn_type is IB.
ALTER REPLICATION (DROP HOST) :
This drops a host. A host can be dropped from a replication object after the replication object has been stopped. When DROP HOST is executed, the Sender thread attempts to reconnect using the very first IP address.
ALTER REPLICATION (SET HOST) :
This means setting a particular host as the current host. The current host can be specified after the replication object has been stopped. After execution, the Sender thread attempts to connect using the currently designated IP address.

Examples#

In the following double-IP network environment, a replication object having a table called employees and one called departments as its target objects is created, and then replication in Active-Standby mode is executed on the local server (IP: 192.168.1.51, PORT NO: 30570) and the remote server (‘IP: 192.168.1.154, PORT NO: 30570’, ‘IP: 192.168.2.154, PORT NO: 30570’).

On the remote (standby) server:

iSQL> CREATE REPLICATION rep1   
WITH '192.168.1.51', 30570  
FROM sys.employees TO sys.employees,
FROM sys.departments TO sys.departments;
Create success.

On the local (active) server:

iSQL> CREATE REPLICATION rep1
       WITH '192.168.1.154',30570 '192.168.2.154',30570
FROM sys.employees TO sys.employees,
FROM sys.departments TO sys.departments;
Create success.                               

iSQL> SELECT * FROM system_.sys_replications_;

<- The meta table enables the user to view the number of registered hosts, the number of replication target tables, and other related information.

REPLICATION_NAME        LAST_USED_HOST_NO    HOST_COUNT  
------------------------------------------------------------------------
IS_STARTED  XSN         ITEM_COUNT  CONFLICT_RESOLUTION REPL_MODE   
------------------------------------------------------------------------
ROLE        OPTIONS     INVALID_RECOVERY REMOTE_FAULT_DETECT_TIME
-----------------------------------------------------------------------
REP1                    2                    2           
0           -1          2           0                   0           
0           0           0                        
1 row selected.

iSQL> SELECT * FROM system_.sys_repl_hosts_;
SYS_REPL_HOSTS_.HOST_NO SYS_REPL_HOSTS_.REPLICATION_NAME          
-----------------------------------------------
SYS_REPL_HOSTS_.HOST_IP                   SYS_REPL_HOSTS_.PORT_NO 
-----------------------------------------------
2           REP1                                      
192.168.1.154                             30570       
3           REP1                                      
192.168.2.154                             30570       
2 rows selected.

<- Information about remote server by using meta table.

iSQL> ALTER REPLICATION rep1 START;
Alter success.

\<- Replication starts.

iSQL> SELECT rep_name, status, net_error_flag, sender_ip, sender_port,
             peer_ip, peer_port
FROM V$REPSENDER;
REP_NAME                                  STATUS               
------------------------------------------------------------------
NET_ERROR_FLAG       
-----------------------
SENDER_IP                                                         SENDER_PORT
------------------------------------------------------------------------PEER_IP                                                           PEER_PORT   
------------------------------------------------------------------------REP1                                      1                    
0                    
192.168.1.51                                                      13718       
192.168.1.154                                                     30570       
1 row selected.

<- The status of replication is checked after replication starts. The Sender thread connects to the peer using the first IP and PORT.

!!!!!!!!!!!!! Network line disconnection !!!!!!!!!!!!!!!

<- The status of replication is checked after replication starts. The Sender thread connects to the peer using the first IP and PORT.iSQL> SELECT rep_name, status, net_error_flag, sender_ip, sender_port,
             peer_ip, peer_port 
FROM V$REPSENDER;
REP_NAME                                  STATUS               
------------------------------------------------------------------
NET_ERROR_FLAG       
-----------------------
SENDER_IP                                                         SENDER_PORT
-----------------------------------------------------------------------
PEER_IP                                                           PEER_PORT   
-----------------------------------------------------------------------
REP1                                      1                    
0                    
192.168.1.51                                                      40009       
192.168.1.154                                                     30570       
1 row selected.

\<- The status of replication is checked after network failure occurs. This verifies reconnection using the second IP and PORT.

iSQL> ALTER REPLICATION rep1 STOP;
Alter success.

\<- Replication is stopped.

iSQL> ALTER REPLICATION rep1 START;
Alter success.

\<- Replication starts.

iSQL> SELECT rep_name, status, net_error_flag, sender_ip, sender_port,
             peer_ip, peer_port 
FROM V$REPSENDER;
REP_NAME                                  STATUS               
------------------------------------------------------------------
NET_ERROR_FLAG       
-----------------------
SENDER_IP                                                         SENDER_PORT
-----------------------------------------------------------------------
PEER_IP                                                           PEER_PORT   
-----------------------------------------------------------------------
REP1                                      1                    
0                    
192.168.1.51                                                      64351       
192.168.1.154                                                     30570       
1 row selected.

\<- When replication is started again after having been stopped, it can be verified to have been reconnected to the same IP and PORT to which it was connected before being stopped.

iSQL> ALTER REPLICATION rep1 ADD HOST '192.168.3.154',30570;
Alter success.

\<- Add host: Can be executed after replication.

iSQL> ALTER REPLICATION rep1 DROP HOST '192.168.3.154',30570;
Alter success.

\<- remove host: Can be executed after replication.

iSQL> ALTER REPLICATION rep1 SET HOST '192.168.1.154',30570;
Alter success.

\<- Designate the host: Can be executed after replication.

iSQL> ALTER REPLICATION rep1 START;
Alter success.

\<- Replication is restarted after setting the new host. The replication operation first attempts to connect using the currently designated IP and PORT.

iSQL> SELECT rep_name, status, net_error_flag, sender_ip, sender_port, 
             peer_ip, peer_port 
FROM V$REPSENDER;
REP_NAME                                  STATUS               
------------------------------------------------------------------
NET_ERROR_FLAG       
-----------------------
SENDER_IP                                                         SENDER_PORT
-----------------------------------------------------------------------
PEER_IP                                                           PEER_PORT   -----------------------------------------------------------------------
REP1                                      1                    
0                    
192.168.1.51                                                      11477       
192.168.1.154                                                     30570       
1 row selected.

<- Connection to the peer using the newly designated IP 192.168.1.154 and PORT number 30570 can be confirmed.

To use replication, the Altibase properties file should be modified to suit the purposes of the user. The following properties are described in the General Reference Manual.

REPLICATION_ACK_XLOG_COUNT
REPLICATION_ALLOW_DUPLICATE_HOSTS
REPLICATION_BEFORE_IMAGE_LOG_ENABLE
REPLICATION_COMMIT_WRITE_WAIT_MODE
REPLICATION_CONNECT_RECEIVE_TIMEOUT
REPLICATION_CONNECT_TIMEOUT
REPLICATION_DDL_ENABLE
REPLICATION_DDL_ENABLE_LEVEL
REPLICATION_DDL_SYNC
REPLICATION_DDL_SYNC_TIMEOUT
REPLICATION_EAGER_PARALLEL_FACTOR
REPLICATION_EAGER_RECEIVER_MAX_ERROR_COUNT
REPLICATION_FAILBACK_INCREMENTAL_SYNC
REPLICATION_GAP_UNIT
REPLICATION_GAPLESS_ALLOW_TIME
REPLICATION_GAPLESS_MAX_WAIT_TIME
REPLICATION_GROUPING_TRANSACTION_MAX_COUNT
REPLICATION_GROUPING_AHEAD_READ_NEXT_LOG_FILE
REPLICATION_HBT_DETECT_HIGHWATER_MARK
REPLICATION_HBT_DETECT_TIME
REPLICATION_IB_LATENCY
REPLICATION_IB_PORT_NO
REPLICATION_INSERT_REPLACE
REPLICATION_KEEP_ALIVE_CNT
REPLICATION_LOCK_TIMEOUT
REPLICATION_LOG_BUFFER_SIZE
REPLICATION_MAX_COUNT
REPLICATION_MAX_LISTEN
REPLICATION_MAX_LOGFILE
REPLICATION_POOL_ELEMENT_COUNT
REPLICATION_POOL_ELEMENT_SIZE
REPLICATION_PORT_NO
REPLICATION_PREFETCH_LOGFILE_COUNT
REPLICATION_RECEIVE_TIMEOUT
REPLICATION_RECEIVER_APPLIER_ASSIGN_MODE
REPLICATION_RECEIVER_APPLIER_QUEUE_SIZE
REPLICATION_RECOVERY_MAX_LOGFILE
REPLICATION_RECOVERY_MAX_TIME
REPLICATION_SENDER_AUTO_START
REPLICATION_SENDER_COMPRESS_XLOG
REPLICATION_SENDER_ENCRYPT_XLOG
REPLICATION_SENDER_SEND_TIMEOUT
REPLICATION_SENDER_SLEEP_TIME
REPLICATION_SENDER_SLEEP_TIMEOUT
REPLICATION_SENDER_START_AFTER_GIVING_UP
REPLICATION_SERVER_FAILBACK_MAX_TIME
REPLICATION_SQL_APPLY_ENABLE
REPLICATION_SYNC_APPLY_METHOD
REPLICATION_SYNC_LOCK_TIMEOUT
REPLICATION_SYNC_LOG
REPLICATION_SYNC_TUPLE_COUNT
REPLICATION_TIMESTAMP_RESOLUTION
REPLICATION_TRANSACTION_POOL_SIZE
REPLICATION_UPDATE_REPLACE

3.Deploying Replication#

Considerations#

Prerequisites#

Connection Constraints#

Replication Target Column Constraints#

Replication Constraints in EAGER Mode#

Partitioned Table Constraints#

Constraints on Using Replication for Data Recovery#

Additional Considerations when Using Replication for Data Recovery#

Allowed DDL Statements#

Note:#

CREATE REPLICATION#

Syntax#

Prerequisites#

Description#

Error Codes#

Example#

Starting, Stopping and Modifying Replication using “ALTER REPLICATION”#

Syntax#

Prerequisites#

Description#

Error Codes#

Example#

DROP REPLICATION#

Syntax#

Prerequisites#

Description#

Error Codes#

Example#

Executing DDL Statements on Replication Target Tables#

Allowed DDL Statements#

DDL statements without REPLICATION_DDL_ENABLE/REPLICATION_DDL_ENABLE_LEVEL settings.#

DDL statements with REPLICATION_DDL_ENABLE_LEVEL = 0#

DDL statements with REPLICATION_DDL_ENABLE_LEVEL = 1#

Description#

Restrictions#

Example#

Executing DDL Synchronization on Replication Target Tables#

Restrictions of DDL Synchronization#

How to Use#

Prerequisites on the User Environment#

Prerequisites on the Local Server#

Prerequisites on the Remote Server#

Execute DDL statements#

Allowed DDL statements#

Disallowed DDL Statements#

Post-Action(Properties Restoration)#

Examples#

SQL Apply Mode#

Restriction#

Note*:#

Extra Features#

Recovery Option#

Syntax#

Description#

Restriction#

Example#

Offline Option#

Syntax#

Description#

Offline Option Restrictions#

Example#

Replication Gapless Option#

Syntax#

Description#

Restriction#

Example#

Parallel Applier Option#

Syntax#

Description#

Example#

Restriction#

Replicated Transaction Grouping Option#

Syntax#

Description#

Restriction#

Meta Logging Option#

Syntax#

Description#

Replication in a Multiple IP Network Environment#

DDL statements with REPLICATION_DDL_ENABLE_LEVEL = 1 #