Use the action createstandby to initially setup a primary/standby environment. The following steps must be performed as user root:

The createstandby action can cause a short outage of the SKOOR system due to a restart of the database (possible automatic configuration change). It will be fully functional and accessible afterwards.

Be aware of the following:

Databases with a size of 100GB or larger normally need more WAL files than the default of 2048. The parameter wal_keep_size must be increased before the replication can be initialized:
```
vi /var/lib/pgsql/data/postgresql.skoor.conf
```
Change the parameter (the value can be larger than 4096, consider the free space on the disk):
```
wal_keep_size = 4096
```
The script will sync DB tables from the primary to the standby. Check the size of the whole DB using:
```
du -sh /var/lib/pgsql
```
It is very likely that there will be several gigabytes of data to transfer. In this case, initializing the replication is best done in the evening.
Reinitialization does not copy over all files. If an initialization was already done once with createstandby, but it has to be repeated because for some reason the replication is broken, much less data will be transferred from the primary to the standby.
However, each database file must be compared by checksum on both sides so the replication mechanisms is able to determine which files need to be transferred. Syncing based solely on database file sizes and their modification times is not reliable enough. Therefore, before the actual syncing starts, the whole database needs to be checksummed on both sides, which can take several hours, depending on host performance and database size.
It is a good idea to complete a full backup on the current active system before starting the initialization. This can be done with the command:
```
cd /var/lib/pgsql
```
```
sudo -u postgres bash -l -c '/opt/eranger/bin/eranger-server-backup.sh full'
```
which will save a full backup to /opt/eranger/server/backups/.

To start the initialization, the createstandby command must be issued on the primary. Since this command can run for several hours, depending on the amount of data that needs to be transferred and the network bandwidth between primary and standby, it is recommended to run the command within a screen session. The screen command allows running a command remotely without the command being terminated if the connection to the remote host is disconnected for some reason. Issue a new screen session (with a large enough history scrollback buffer) on the primary as root using the following command:

screen -h 10000

Then within this screen session run the following command to start the standby initialization process:

/opt/eranger/bin/eranger-server-replication.pl createstandby

The following is an example output of the above command:

192.168.56.221 prepare standby system 192.168.56.222 (primary system 192.168.56.221)..
192.168.56.221
192.168.56.221
192.168.56.221 ============================================================
192.168.56.221 == Setting up standby system on 192.168.56.222
192.168.56.221 == THIS WILL DESTROY DATABASE on 192.168.56.222
192.168.56.221 == make sure you have a backup
192.168.56.221 ============================================================
192.168.56.221
192.168.56.221 if you continue, we will call above command with ssh
press ENTER to continue, Ctrl-C to abort >

Press Enter to continue. The following output will be shown:

192.168.56.221 checking ssh for user reranger
192.168.56.222 stopped skoor syncfs
Removed symlink /etc/systemd/system/multi-user.target.wants/eranger-server.service.
Removed symlink /etc/systemd/system/multi-user.target.wants/eranger-report.service.
192.168.56.221 restart postgresql-13.service..
192.168.56.221 SKOOR Engine start httpd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 httpd already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-report at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-report already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-server at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-server already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ethd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ethd (service eranger-ethd )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-eth-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-eth-alerter (service eranger-eth-alerter )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-collector at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-collector already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-agent at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-agent already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ic-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ic-alerter (service eranger-ic-alerter )..
192.168.56.221 done
192.168.56.221 copied file to /var/lib/pgsql/13/data/
192.168.56.221 copied file to /var/lib/pgsql/data/ng_tblspc/
192.168.56.221 rsync done
NOTICE:  all required WAL segments have been archived
192.168.56.222 stopped skoor syncfs
192.168.56.222 Enable and start eranger-replication-tunnel.service at /opt/eranger/bin/eranger-server-replication.pl line 1751.
192.168.56.221 started skoor syncfs

The createstandby command can also be run in non-interactive mode using the -f parameter. The output will be shorter in this case:

Please be aware that this command makes this system to the primary server and immediately destroys the database on the other node

# eranger-server-replication.pl -f createstandby
192.168.56.221 prepare standby system 192.168.56.222 (primary system 192.168.56.221)..
192.168.56.221
192.168.56.221 checking ssh for user reranger
192.168.56.222 stopped skoor syncfs
192.168.56.221 restart postgresql-13.service..
192.168.56.221 SKOOR Engine start httpd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 httpd already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-report at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-report already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-server at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-server already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ethd at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ethd (service eranger-ethd )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-eth-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-eth-alerter (service eranger-eth-alerter )..
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-collector at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-collector already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-agent at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 eranger-agent already running (not starting)
192.168.56.221 done
192.168.56.221 SKOOR Engine start eranger-ic-alerter at /opt/eranger/bin/eranger-server-replication.pl line 1818.
192.168.56.221 start eranger-ic-alerter (service eranger-ic-alerter )..
192.168.56.221 done
192.168.56.221 copied file to /var/lib/pgsql/13/data/
192.168.56.221 copied file to /var/lib/pgsql/data/ng_tblspc/
192.168.56.221 rsync done
NOTICE:  all required WAL segments have been archived
192.168.56.222 stopped skoor syncfs
192.168.56.222 Enable and start eranger-replication-tunnel.service at /opt/eranger/bin/eranger-server-replication.pl line 1751.
192.168.56.221 started skoor syncfs

The screen session can be left anytime by pressing first "Ctrl-a" and then "d". To re-enter the screen session, enter the following re-attach command:

screen -h 10000 -r

The script does the following:

Compare the checksum of every database file between primary and standby.
Stop the eranger-server service on the standby if it is running
The files /var/lib/pgsql/data/recovery.signal and skoor-replication.conf (which is included by postgresql.skoor.conf) are created on the standby. Those allow the standby to know its primary's IP address, the replication port, credentials, and the path to the trigger file. The following shows an example of a skoor-replication.con file on the standby:
```
primary_conninfo = 'host=10.1.0.88 port=5432 user=replication password=replication'
promote_trigger_file = '/tmp/postgresql.trigger.5432'
```
The promote_trigger_file does not exist if the replication is running. Creating it causes the replication to end (i.e. in case of a switch/failover).
recovery.signal is only a marker file and hence empty.
The parts of the database that differ between the two hosts are transferred using an rsync over ssh process. The following paths are excluded from the sync process:
- /var/lib/pgsql/data/pg_xlog/ (the binary logs, i.e. the WAL files are not synced during createstandby, their content is only replicated after the createstandby process has started)
- /var/lib/pgsql/data/recovery.signal
- /var/lib/pgsql/data/skoor-replication.conf
- /var/lib/pgsql/data/postmaster.pid
The replication is started

During the createstandby process, the primary can be used normally to accept measurement data from collectors. Also the SKOOR web interface can be used, however, the performance may be degraded due to the checksum calculations and the transfer of large files across the network.
The time it takes to initialize a replication for the first time mainly depends upon the size of the database, the network speed and the host's performance.

Each comment about what the script does is prefixed by the IP address of the host on which the task is being processed.

After the command has finished running, check its exit code. It should be zero:

...
10.1.0.88 done
10.1.0.88 copied file to /var/lib/pgsql/data/
NOTICE:  pg_stop_backup complete, all required WAL segments have been archived
# echo $?
0

The replication is now started and from now on all database queries that are executed on the primary are replicated to the standby immediately.

Modes