TimesTen database Replication learning: 1. TimesTen Replication overview

This article is the first of a series of TimesTen database replication.

What is replication

Replication is the existence of multiple copies of data in multiple databases, with minimal performance impact while ensuring high data availability, balancing workloads in addition to data recovery to maximize performance and enable rolling upgrades and maintenance

TT replication is implemented in both the master and Subscriber databases with replication agents, one responsible for reading, one responsible for loading, and data passing between rep agents

The TT recommended method is ASP (active standby pair), TT supports copying the whole library, some tables, cache group, sequence and so on. ASP is the only scenario that supports replicating the cache group

TT also supports replication DDL

Requirements for replication compatibility

Must be the same as the platform, in the same byte order.

Although you can replicate two libraries on the same host, the best recommendation is two libraries on different hosts

The copied library must have the same character set (Databasecharacterset) and data type mode (Typemode, Oracle by default)

Replication agents

A library can be uniquely identified by hostname and file system pathname, and the rep agent communicates via TCP/IP socket

The replication agent on the master database reads the records from the transaction log and forwards any detected changes To replicated elements to the replication agent on the Subscriber database. The replication agent on the Subscriber database then applies the updates to its database. If The subscriber agent is not running then the updates are forwarded by the Master and the master retains the updates in the Transaction log until they can be transmitted.

Replication Transfer Mode

Supports three modes, by performance impact and data consistency from small to large for:
1. NO RETURN (default, async mode)
2. Return RECEIPT (returned by the other party)
3. Return Twosafe (the other party receives and returns after submission)

Default mode (async)

The default mode provides the best performance, but there is a risk of data loss. After you apply the update main library, you do not have to wait for updates to be delivered and loaded into the subscription library. There is an internal mechanism between the main library and the subscription repository to determine that updates are successfully delivered and loaded, and that the application is completely independent.

A few notes:
* The application can be returned after the transaction is submitted and then written to the log buffer, which is the completion of step 2.
* The replication agent is responsible for flush data from log buffer to disk and passing it to subscriber
* The replication agent can delete unnecessary logs after Subscriber returns to accept success
* Updated delivery is in batch mode to improve efficiency.

Return Receipt (quasi-synchronous)

Apply blocking until the other person receives the update and returns

A few notes:
* The receiver is accepted in memory, and subsequent writes to log buffer and persistence are not counted.
* If the receipt is not returned within 10 seconds, the app can continue and this time-out can be configured.
* The reason for the timeout may be network, replication agent invalidation, etc.

Return Twosafe (full sync)

The app is blocked until the transaction is submitted before it can continue.

A few notes:
* Transactions are submitted at the backup point before the main point
* The replication agent for the primary point does not need to flush the contents of the log buffer to disk until it passes the change to the backup point. This is different from asynchronous and return receipt. This is why the return Twosafe performance is actually faster than the return receipt.
> Transmission of Return Twosafe transactions is nondurable, so the master replication agent does not flush the log Records to disk before sending them to the subscriber, as it does by default when replication was configured for Asynchron ous or return receipt replication.
* Timeout Configurable, default is 10 seconds. Can be set to resubmit or unconditionally commit after a timeout (regardless of the data not received by the spare point)

database replication mode (replication schemes)

Here the replication scheme is called replication pattern better understood.

Active Standby Pair (master-slave group copy)

The Active Standby Pair (hereinafter referred to as ASP) is the most commonly used replication mode for TimesTen.

The ASP contains 3 members, which are two master and a set of read-only subscriber (up to 127).
Where both active and standby are master, but active is read-write and Standby is read-only.

A few notes:
* Since ASP is pair, it shows that active and standby are paired, and 1 active corresponds to multiple standby is not supported.
* If standby fails, active can be copied directly to subscriber, and if standby is restored, it will be synchronized with active and then re-assume responsibility for subscriber replication.

Classic replication (traditional copy)

Master and Subscriber are both readable and writable in classic copy (pending validation)

Full Library and selective replication

The following is a full library copy:

The following are selective replication, where you can copy the same object to multiple targets, or you can copy different objects to the target, such as:

One-way and two-way replication

One-way replication is 1 master for multiple subscriber, while bidirectional replication refers to a database that is both master and Subscriber.

Two-way replication is also used for load sharing, where two library distributions assume different services, such as:

The other is replication equalization, which means that two libraries assume the same services, such as:

Direct replication and brokered replication

This mode is more about the impact of network bandwidth and the sharing of replication load.

For direct replication:

For brokered replication, propagator and subscribers are within a network:

Brokered replication for replication load sharing:

Cache groups and Replication

Replication for a cache group supports only active Standby pair replication mode. Cache groups that support replication include AWT and read-only cache groups.

Replication of AWT cache groups (an Oracle database)

Let's focus on the left active and standby two libraries, which are passed through standby to the Oracle database. The goal is to mitigate the burden of active master.

If master fails, standby will assume the business read and write, and still maintain synchronization with the Oracle database.

If the standby fails, or if the standby is not yet established, then active can concurrently assume responsibility for receiving business read-write and synchronizing data with Oracle.

When standby becomes new active, TimesTen overrides the configuration cache group, allowing the new standby to assume the task of synchronizing with Oracle.

Take a look at the copy on the right from standby to read-only subscriber, where the copy target on the read-only subscriber is not the table in the cache group, but just the normal Non-cache table.

Replication of AWT cache groups (two Oracle databases)

If the previous approach is for HA, because active and master are shared with the Oracle database. The approach here is for D/R, because the primary and the backup have different Oracle databases.

Replication for read-only cache groups

In this replication mode, the active database is automatically synchronized to make Oracle data. In fact, standby also configured the AutoRefresh, but in the pause state.

If master fails, standby takes over while the AutoRefresh state changes to on.

Since TimesTen not only tracks the state of active and Oracle synchronization, it also tracks the synchronization state of both active and standby, so when standby takes over the failed master, it does not need to be synchronized with Oracle from the beginning.

However, for replication of read-only cache groups, if master fails, then configuring the new master should not be easy.

Sequence and Replication

TimesTen supports sequence replication, usually sequence used as the primary key and uniquely identifies a row. In this scenario, sequence is more commonly used than timestamp.

Foreign keys and replication

Choose to replicate all or a subset of tables that has foreign key relationships with one another. However, the method for what replicate the tables involved in the relationship differ according to the type of Replicati On scheme.

Aging and Replication

If the replication table defines the aging policy, whether it is timestamp-based or LRU, then:
* Source and target aging policies must be consistent
* For ASP, only the primary point applies the aging policy, resulting in data deletion through replication to the target
* If it is not ASP, the main point and the backup use their own aging policy.
* If it is an AWT cache group, the data deletion caused by aging is not passed to Oracle, which is really not the case with replication, which is a reasonable behavior for aging.

TimesTen database Replication learning: 1. TimesTen Replication overview