How TCapture RepServer works

[tcapturesupport]

• TCapture RepSrv replicates committed database transactions.

A Java engine continuously monitors the database transaction log for newly committed transactions that have been marked for replication. When it finds one, the replication sends it to the RepServer process that runs somewhere outside primary db.

• TCapture RepSrv will then forward the transaction to the designated replicate database and apply it.

IIt should be noted that that replicate database does have to be Postgresql.

• TCapture RepSrv uses a publish-subscribe model.

On the primary side, the entity to be replicated is published, and this can be subscribed to by one or more replicate databases.
Such an entity can be an individual database table, or an entire database. The latter is often used for ‘warm standby’ configurations where all changes in a database are replicated to a standby.

• TCapture RepSrv performs asynchronous replication.

This means that when the database transaction in the primary database commits, it will be picked up and applied to the replicate database shortly afterwards, decoupled from the primary transaction.

Consequently, when using asynchronous replication, there is always some latency: some time will pass before a primary transaction gets been applied to the replicate side.

The challenge is to keep this latency as short as possible.
In a well-designed and well-tuned replication system, latencies of no more than single-digit seconds are typical, even when the replicate database is on a WAN.

An unwillingness to accept latency is sometimes used as an argument in favor of a synchronous replication approach. Here, the idea is that the primary transaction does not commit until the transaction has committed in the replicate database as well. The big downside is that the replicate site must always be available: if it is not, transactions cannot commit at the primary site. In practice, this makes the overall system more vulnerable, since there are now two points of failure.

• TCapture RepServer’s asynchronous replication offers an optimal compromise between latency and availability. Another aspect worth discussing briefly is that a typical replication system operates in a networked environment. For example, let’s assume the primary database runs on an server in New York; the TCapture RepSrv runs on a Linux box in the same data center; one replicate database run on an server in Houston, Texas; and another replicate database runs on Linux in London, UK.

TCapture RepServer is designed under the assumption that it is normal for network connections to temporarily fail, and then come back into service.
Once a connection fails, RepServer will automatically keep retrying until the connection is back, and then proceed replication where it left off.