our setup:
Postgres server is running on CentOS release 6.10 (Final) instance.
Server Version is PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled by
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit

With the following parameters set:

wal_level = ‘logical’ # replica < logical
max_replication_slots = 10
max_wal_senders = 10
track_commit_timestamp = on

We are using decoder_raw module for retrieving/read the WAL data through
the logical decoding mechanism.

Application setup:

The actual TCapture engine is a Java application which runs as a separate
program outside Postgres, and which must be started explicitly.
When TCapture is running, it will scan the transaction log (with TCapt
module) of all primary databases and pick up transactions which must be
Transactions which have been picked up are stored in the “Replication
Database”, a PG user database exclusively used by TCapture.
In the Replication Database, transaction is ‘copied’ to all replicate
databases which have a subscription for this transaction.
Transaction is then applied to the replicate tables by inserting it into
by the dedicated Java application module

2 thoughts on “tcapture-blog

  1. Isabelle

    We would like to use logical replication for implementing multimaster, so all nodes are both sending and receiving changes. But we experience the problem of infinite recursion.

    How prevent it and not to rereplicate replicated data: node receives change set from some other node, applies it within some transaction, it is written to the log and is replicated to other nodes.

    how Tcapture manage this issue?


    1. mktgtcapture Post author

      TCapture trace in tables, stored in replication databases, transactions applied by a slave node caming from the master one.
      IN this way TCapture can unserstand where a change came from and in a mesh topology only send locally-originated tuples to peers.


      Support TCapture

Comments are closed.