---
title: "Using PostgreSQL Streaming Replication"
slug: "using-postgresql-streaming-replication-3"
tags: ["8.2", "Portal"]
status: "update"
updated: 2025-12-03T08:36:07Z
published: 2025-12-03T08:36:07Z
canonical: "kb.ctera.com/using-postgresql-streaming-replication-3"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.ctera.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Using PostgreSQL Streaming Replication

Streaming replication enables the continuous streaming and replication of WAL segments from the WAL directory and archived WAL segments from a primary database server to a secondary database server.

The following diagram illustrates streaming replication with continuous archiving and point-in-time recovery: ![image.png](https://cdn.document360.io/30792387-cdcb-4791-aa14-94929bbcd3fe/Images/Documentation/image-ASMMQCDD.png?sv=2026-02-06&spr=https&st=2026-11-11T04%3A17%3A28Z&se=2026-11-11T05%3A17%3A28Z&sr=c&sp=r&sig=lJGZ9j%2F%2BZdatztiRdVNQYyHjcdKbjAvBckxBhD455Qw%3D)

**Note**

Syncing archived WAL segments is done only on the first setup of the replica.

This process is complementary to configuring continuous archiving. It protects against failures occurring on the primary database server, by streaming the WAL directory and synchronizing the database's archived WAL logs to a secondary database server.

**Note**

You can also configure the replication so that the archive pool is on the passive, secondary, database and not the active database server with point-in-time recovery on the secondary. ![image.png](https://cdn.document360.io/30792387-cdcb-4791-aa14-94929bbcd3fe/Images/Documentation/image-XG62P5DI.png?sv=2026-02-06&spr=https&st=2026-11-11T04%3A17%3A28Z&se=2026-11-11T05%3A17%3A28Z&sr=c&sp=r&sig=lJGZ9j%2F%2BZdatztiRdVNQYyHjcdKbjAvBckxBhD455Qw%3D)

### Configuring PostgreSQL Streaming Replication

The secondary server continuously streams the primary server’s WAL segments, and synchronizes the primary database server’s archived WAL segments every 10 minutes. Streaming replication traffic runs on TCP port 5432, which means you must open these ports for communication between the primary and secondary database servers. The secondary CTERA database server acts as a standby/passive server and cannot be used for load balancing purposes.

**Notes**

The allocated disk space for the PostgreSQL archive pool must be at **least** twice the size of the storage space allocated for the CTERA Portal data pool, as described in [Calculating the Minimum Space Required for the Database Backup](/v1/docs/configuring-ctera-portal-database-for-backup-and-restore-1#calculating-the-minimum-space-required-for-the-database-backup).

The locations of the streaming and archived WAL segments are `$pgdatadir/pg_wal` and `$DBarchive` respectively.

**To configure streaming replication:**

- Set up a replication server as described in [Configuring the Replication Server](/v1/docs/installing-and-configuring-additional-ctera-portal-servers-5#configuring-the-replication-server).

**Note**

You configure archiving only on the secondary server when the load on the primary server is very large. In most cases, configure streaming replication, as described above in [Configuring PostgreSQL Streaming Replication](/v1/docs/using-postgresql-streaming-replication-3#configuring-postgresql-streaming-replication). Before configuring streaming replication only on the secondary server, you **must** contact CTERA support.

**To configure archiving only on the secondary server:**

1. Set up streaming replication, as described above in [Configuring PostgreSQL Streaming Replication](/v1/docs/using-postgresql-streaming-replication-3#configuring-postgresql-streaming-replication).
2. Using SSH, log in as root to your CTERA Portal primary database server.
3. Disable archiving on the primary server by editing the `PG_REPLIC_MODE` field in **portal.cfg** file as follows:  

Change `PG_REPLIC_MODE=local_archive_streaming` to `PG_REPLIC_MODE=streaming`  

You do not need to restart the primary server. However, if users or any tomcat process tries to create a base backup, a warning is issued in the image log. You can ignore this warning.
4. Using SSH, log in as root to your secondary server.
5. Enable archiving on the secondary server by editing the **portal.cfg** file on the secondary server, as follows:  

Insert the field `SLAVE_ARCHIVE_FORCE=yes`
6. Restart the server by running the following command: `portal.sh restart`

If `SLAVE_ARCHIVE_FORCE=no,` the secondary server archive mode is the same as the primary server mode. Changing the `SLAVE_ARCHIVE_FORCE` value always requires restarting the server.