Streaming Replication with the WAL Sender Process v6.2

The changeset stream is accessible to the xDB publication server by the WAL sender process (walsender) using the streaming replication protocol.

The xDB publication server connects using the walsender interface through which changes are streamed on a continual basis. The continuous streaming eliminates the need for explicitly polling for changes.

The following are the basic synchronization steps using the log-based method:

1. A streaming replication connection to the database server is opened using libpq to establish a walsender communication channel.
2. A separate thread is used to monitor data changes streamed through the walsender interface.
3. As the data changes become available, they are transformed to populate an in-memory cache.
4. On the next scheduled interval, the in-memory cached data changes are applied to each of the target databases in JDBC batches of SQL statements (referred to as transaction sets) in the same manner as described in Synchronization Replication with the Trigger-Based Method for the trigger-based method. If one or more target database servers are not accessible, the data changes are saved in a local file on the host running the publication server. See In-Memory Caching and Persistence for information on in-memory caching and data persistence.
5. The value of the WAL segment’s log sequence number (LSN) identifying the last set of applied changes based on the last replicated transaction is updated. The update is confirmed to the database server.
6. The applied data changes are cleared from the in-memory cache.
7. Steps 3 through 6 are repeated.