1. Replication Overview

The purpose of database replication is to maintain an up-to-date backup of the data on an Active Server and provide an uninterrupted service environment in which a substitute server can be used to resume service in the event that the Active Server unexpectedly goes offline for some reason.

This chapter covers the following subjects::

• Altibase Replication Concepts and Terminology
• Replication Function in Altibase
• Choosing Replication Targets
• Replication mode
• Replication and Data Definition Language (DDL)
• Data Recovery Using Replication

Concepts

The log replay method is the basis of the Altibase replication functionality. First, a local server transfers transaction logs to a remote server when the logs change. Then the remote server "replays" the received logs to its database (that is, it implements the changes that have been recorded in the logs). Altibase also provides the altiComp utility for monitoring and managing the replication status.

For more detailed information, please refer to the Utilities Manual > altiComp.

Terminology

Local Server

In this manual, the term "local server" always refers to the local node (that is, to the server on which the current task is performed), regardless of whehter it is an Active or Standyby Server, or whether it hosts a replication Sender or Receiver thread.

Remote Server

This is a counterpart replication node (i.e., a node that has a 1:1 relationship with a local server to form a replication pair).

Active Server

Among the database servers that are connected in replication, this is a replication node that is actively providing service to users and on which change operations related to master transacitons take place.

Standby Server

This is a replication node on which change transactions are not occurring. (It may be queried using SELECT statements).

Sender

This is a thread that sends information about changes made to data caused by a transaction to a remote server. It changes logs that result from the execution of DML statements on replication target tables on the local server into XLog form so that they contain information about the actual (physical) changes made to the data and sends the resultant XLogs to the remote server.

Receiver

This is a thread that receives XLogs (which contain information about changes to data) from a counterpart server. If there is no applier, the receiver replays the Logs on replication target objects on the local node.

Applier

This term indicates a thread that applies the XLog that the sender sent to the receiver, to the Storage Manager.

If the parallel receiver applier option is omitted, the receiver takes the role of the applier, and the applier is not created.

Ahead Analyzer

If the replication transaction grouping option has been specified and a replication gap occurs, this thread analyzes logs (before the sender does) and creates replication transaction groups. Replication transaction groups help dissolve gaps; the sender references these transaction groups to adjust the amount of XLogs it sends to the receiver.

Sender Thread

This has the same meaning as "Sender" when not using parallel replication (i.e., when performing replication using only one Sender thread and one Receiver thread). When using parallel replication, one Sender consists of multiple Sender threads.

Receiver Thread

This has the same meaning as "Receiver" when not using parallel replication (i.e., when performing replication using only one Sender thread and one Receiver thread). When using parallel replication, one Receiver consists of multiple Receiver threads.

XSN

This stands for "XLog Sequence Number". It is not to be confused with "SN" (the sequence number of a redo log).

Local Commit XSN

This is the sequence number of the committed log record that was most recently read by the Sender. The transaction corresponding to this XSN is not guaranteed to have been committed on the remote server. This value is returned when the COMMIT_XSN column of the V$REPSENDER performance view is queries.

Restart Sequence Number SN

This is the lowest Redo SN (not XSN) corresponding to a transaction for which an XLog for replication has not been sent. It is the position from which the transmission of XLogs will recommence when replication resumes.

XLog

This is a kind of log that results from the transformation of one or more redo logs into logical form for replication. The replication Sender thread on a local server transmits an XLog to the replication Receiver thread on a remote server, which then replays the log so that the remote server contains the same data as the local server

Master Transaction

This is a transaction taht takes place on an Active server when providing service to users. It involves the execution of one of more change (INSERT, UPDATE, or DELETE) operations on on or more replication targe tables.

Replication Transaction

This is a transaction that replicates a master transaction on another server. It replays the execution of one or more change (INSERT, UPDATE, or DELETE) operations on one or more replication target tables. It occurs when the Receiver receives an XLog.

Change Operation

This term indicates an INSERT, UPDATE, or DELETE DML operation. This term is used to distinguish these operations from SELECT operations (which do not change the contents of a database).

Replication

This term indicates the concept and action of replicating, rather than a concrete object or entity.

Synchronization

"Synchronization" is a unidirectional operation in which all data in the replication target tables or partitions on the local server are inserted into the corresponding tables or partitions on the remote server. If any data conflict occurs on the remote server during synchronization, conflict resolution will be applied on the remote server. It is performed by executing the ALTER REPLICATION DDL statement with either the SYNC or SYNC ONLY keyword.

Replication Gap

Conceptually, the replication gap is an indicator of how far the replication process has fallen behind the current state of the database. In quantitative terms, it is the difference between the sequence number (not XSN) of the most recent redo log and the sequence number of the redo log for which the corresponding XLog is currently being sent.

Replication Manager

This is the Altibase module that starts and stops the replication Sender and Receiver.

Replication Object

This is an object created with the CREATE REPLICATION statement. It forms a replication pair with a counterpart replication object on another node.

Replication Pair

This is a pair of corresponding replication objects having the same name, one residing on each of the two different nodes.

Replication Target Column

This is a column that exists in corresponding replication target tables on local and remote servers. Replication target columns cannot be explicitly designated; rather, they are determined by the structure of the corresponding replication target tables.

Replication Target Table

This is a table that is designated, using the CREATE REPLICATION or ALTER REPLICATION statement, to be replicated between corresponding replication nodes.

Replication Target Patition

This is a table parition that id designated, using the CREATE REPLICATION or ALTER REPLICATION statement, to be replicated corresponding replication nodes.

EAGER Mode

This is one of two available replication modes which prioritizes data consistency over performance. In this mode, a transaction is not committed on the local server until the local server receives a message from the remote server stating that the task has been performed and the transaction replayed on the remote server.

LAZY Mode

This is the other of the two available replication modes which prioritizes performance over data consistency. In this mode, a transaction is committed on the local server without waiting for confirmation from the remote server.

Parallel Replication

This is the use of multiple Sender and Receiver threads to perform replication in EAGER mode. This is not to be confused with parallel synchronization.

Parallel Synchronization

This is the use of multiple Sender and Receiver threads to accomplish a synchronization task (using "ALTER REPLICATION ... SYN" or "ALTER REPLICATION ... SYNC ONLY). This is not be confused with parallel replication.

How to Perform Replication in Altibase

Replication is conducted in this waythe local server sends information of changes made to the database contents to the remote server, and then the remost server makes the same changes to its database.

Thus,the local and remote servers operate additional threads (apart from the service threads) that are necessary for managing replication.

The replication Sender thread on the local server sends information of changes made to the database contents to the remote server, and then the replication Receiver thread on the remote server makes the same changes to the database on the remote server.

Also, the replication Sender and Receiver threads automatically detect whether or not the corresponding servers shut down normally, and perform the corresponding operation.

Figure [1-1] shows various ways in which replication is supported.

In Altibase, the best of these ways is to transform redo logs into a directly executable logical structure to maximize performance and flexibility.

Figure 1-1 A Review of Replication Methods

1. Performing replication using a client application

   In this case, it downgrades performance and renders data consistency.

   If replication is performed by issuing commands in an application, the repeated execution of the same query or transaciton execution order can disrupt data consistency as Altibase performs replication by replaying logs.

2. Sending queries
   This method increases the load on the QP (Query Processor) and renders validation difficult due to data collisions.

3. Sending execution plans
   This method increases the communication load due to the increased volume of transmissions.

4. Converting logs into query statements
   This method increases high conversion and query processing costs.

5. Converting logs directly into a form that can be executed
   This method requires high conversion cost but improves replication performance.

6. Transmitting logs and performing log-based recovery
   This method is fast but cannot be used in an "Active-Active" environemnt (one in which both servers are providing service).

Choosing a Replication Server

To perform replication in Altibase, the database character sets and the national sets must be the same on both the local and remote servers.

The character sets can be checked by querying the V$NLS_PARAMETERS performance view.

Choosing Replication Targets

Altibase uses object names to specify replication targets.

When creating a replication object, the names of users and tables that are to be designated as replication targets must be directly specified. To replicate only a particular partition of a partitioned table, the name of the partition, the name of the table which contains the partition and the name of the owner of the table must be directly specified. Additionally, only columns that have the same names on both the local and remote servers at the time of replication can be replication targets.

The replication target columns can be checked by querying the V$REPRECEIVER_COLUMN performance view.

Replication Mode

In Altibase, replication can run in one of the following modes:

• LAZY Mode
• EAGER Mode

In Table 1-1, each replication mode has different characteristics in terms of performance, the possibility of delayed replication, and the level of data consistency, as shown in the table below.

[Table 1-1]

Mode	Performance	Delayed Replication	Data Consistency
LAZY	High	Possible	Low
EAGER	Medium	Impossible	High

LAZY Mode

In LAZY mode, when a transaction occurs on a local server ("Master Transaction") and a DML statement is executed on a replication target table, the Sender thread collects logs recorded by the Master Transaction, converts them into XLOGs and sends them out. The Receiver thread on the remote server receives these XLOGs and commits the replication transactions to its database.

Thus, the transcations do no not influence one another and the performance of the local server is excellent because the master transaction and replication transaction occur separately.

However, since the Sender thread always tracks the master transaction, replication may not always be completely up-to-date on very busy sites.

EAGER Mode

In EAGER mode, when a master transaction occurs on a local server, the local server commits the transaction only after it has received confirmation that all of the corresponding logs have been properly applied on the remote server. The remote server commits the replication transaction at the same time. In other words, replication in EAGER mode is a synchronization method¹.

The advantage of EAGER mode is that because it synchronizes transactions, it allows replication to occur in parallel. Therefore, when replication is performed in EAGER mode, multiple sender threads replicate concurrently. The number of parallel threads can be configured using the REPLICATION_EAGER_PARALLEL_FACTOR property.

Although there may be a slight performance degradation due to transaction synchronization, EAGER mode avoids the replication backlog that can occur in high-transaction environments under LAZY mode.

Before using EAGER mode replication, please refer to the Replication Constraints in EAGER Mode.

Replication of Partitioned Tables

As shown in the following figure, a particular partition of a partitioned table can be specified and replicated.

[Figure 1-2] The Structure of a Replicated Partitioned Table

Replication and DDL (Data Definition Language) clone

In Altibase, replication performs based on the column name of the table to be replicated, so that it can be replciated even for tables with different table schemas. For this reason, it allows some DDL to change the schema even if the table is subject to be replicated.

When the table schema is changed by executing DDL, only the data of the column with the same name in both nodes is replicated, and the column in the other name or only one side is not replicated.

If the table schema is replicated in a different state, performance will be deteriorated. Therefore, if the table schema is changed by performing DDL, it is advantageous to perform the same DDL so that both nodes have the same schema.

DDL operation on the table included in the replication can be performed or replicated on a single node based on the user's choice. In the case of replication DDL, the DDL is replicated after synchronizing all the replication data.

When replication DDL, DML except SELECT cannot be performed while synchronizing the replication data, so use it with caution when replicated is performed.

Extra Features

Altibase provides the following additional features. A detaield description of how to use the add-ons and limitations is given in the section on Extra Features.

Recovery Option

If experiencing abnormal server termination during the replication, data recovery option is available for preventing data inconsistency between servers by replications.

Replication Gapless Option

The replication gapless option resolves replication gaps.

Parallel Receiver Applier Option

This option allows receivers to apply XLog received from the sender in parallel.

Replication Transaction Grouping Option

This option sends logs to a sender thread by grouping multiple transaction to a single transaction when replication gap occurs.

Meta Logging Option

This option records the sender meta and Restart SN information into files.

Offline Option

The function that retrieves the untransmitted logs from the Active server and applies the change transactions to the remote server.

Considerations

Tables or partitions are items which can be replicated in Altibase and the corresponding replication target items on both servers must be the same type. Thus, a table can be replicated to a table and a partition can be replicated to a partition, but a crossover replication is impossible.

When dropping a replication target item from a replication object, the item must be specified exactly as it was added. For example, even if every partition of a partitioned table is added as replication targets, it is impossible to specify a partitioned table and exclude it from being a replication target; however, it is possible to specify each partition separately for exclusion.

---

1. Transaction SynchronizationEven if a master transaction is successfully performed on a local server, if a replication conflict occurs on a remote server, it will be impossible to commit the master transaction on the local server. In such cases, the user must explicitly roll back the transaction to execute the next transaction. If the transaction is not rolled back, it will be impossible to apply any changes because a transaction that cannot be committed is continually pending. Under conditions in which the local server is internally required to commit a transaction (e.g., when running in Autocommit mode or when a session is terminated), the conflict causes the master transaction that could not be committed to be automatically rolled back. As a result, the master transaction that experienced the conflict and the replication transaction are both rolled back, thereby ↩