Verwenden Sie die Aktion createstandby , um zunächst eine Primär-/Standby-Umgebung einzurichten. Die folgenden Schritte müssen als Benutzer root durchgeführt werden:

Die Aktion createstandby kann einen kurzen Ausfall des SKOOR-Systems aufgrund eines Neustarts der Datenbank verursachen (mögliche automatische Konfigurationsänderung). Danach ist sie wieder voll funktionsfähig und zugänglich.

Bitte beachten Sie Folgendes:

Datenbanken mit einer Größe von 100 GB oder mehr benötigen in der Regel mehr WAL-Dateien als die Standardeinstellung von 2048. Der Parameter wal_keep_size muss erhöht werden, bevor die Replikation initialisiert werden kann:
```
vi /var/lib/pgsql/data/postgresql.skoor.conf
```
Ändern Sie den Parameter (der Wert kann größer als 4096 sein, beachten Sie den freien Speicherplatz auf der Festplatte):
```
wal_keep_size = 4096
```
Das Skript synchronisiert die DB-Tabellen von der primären mit der Standby-Datenbank. Überprüfen Sie die Größe der gesamten DB mit:
```
du -sh /var/lib/pgsql
```
Es ist sehr wahrscheinlich, dass mehrere Gigabytes an Daten zu übertragen sind. In diesem Fall wird die Initialisierung der Replikation am besten am Abend durchgeführt.
Bei einer Neuinitialisierung werden nicht alle Dateien übernommen. Wenn eine Initialisierung bereits einmal mit createstandby durchgeführt wurde, sie aber wiederholt werden muss, weil die Replikation aus irgendeinem Grund unterbrochen ist, werden viel weniger Daten von der Primär- auf die Standby-Datenbank übertragen.
Allerdings muss jede Datenbankdatei auf beiden Seiten mit einer Prüfsumme verglichen werden, damit der Replikationsmechanismus feststellen kann, welche Dateien übertragen werden müssen. Die Synchronisierung allein auf der Grundlage der Größe der Datenbankdateien und ihrer Änderungszeiten ist nicht zuverlässig genug. Bevor die eigentliche Synchronisierung beginnt, muss daher die gesamte Datenbank auf beiden Seiten mit Prüfsummen versehen werden, was je nach Leistung des Hosts und Größe der Datenbank mehrere Stunden dauern kann.
Es ist ratsam, vor der Initialisierung eine vollständige Sicherung auf dem aktiven System durchzuführen. Dies kann mit dem Befehl:
```
cd /var/lib/pgsql
```
```
sudo -u postgres bash -l -c '/opt/eranger/bin/eranger-server-backup.sh full'
```
Dadurch wird eine vollständige Sicherung in /opt/eranger/server/backups/ gespeichert.

Um die Initialisierung zu starten, muss der Befehl createstandby auf dem Primärsystem ausgeführt werden. Da dieser Befehl je nach der Menge der zu übertragenden Daten und der Netzwerkbandbreite zwischen Primär- und Standby-System mehrere Stunden dauern kann, empfiehlt es sich, den Befehl in einer Bildschirmsitzung auszuführen. Der Bildschirmbefehl ermöglicht die Ausführung eines Befehls aus der Ferne, ohne dass der Befehl abgebrochen wird, wenn die Verbindung zum Remote-Host aus irgendeinem Grund unterbrochen wird. Eröffnen Sie auf dem primären Rechner als root eine neue Bildschirmsitzung (mit einem ausreichend großen Puffer für den Verlaufsrücklauf) mit dem folgenden Befehl:

screen -h 10000

Führen Sie dann innerhalb dieser Bildschirmsitzung den folgenden Befehl aus, um den Standby-Initialisierungsprozess zu starten:

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

Nachfolgend sehen Sie eine Beispielausgabe des obigen Befehls:

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 >

Drücken Sie die Eingabetaste, um fortzufahren. Es wird die folgende Ausgabe angezeigt:

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

Der Befehl createstandby kann auch im nicht-interaktiven Modus mit dem Parameter -f ausgeführt werden. In diesem Fall wird die Ausgabe kürzer sein:

Bitte beachten Sie, dass dieser Befehl dieses System zum primären Server macht und die Datenbank auf dem anderen Knoten sofort vernichtet

# 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

Die Bildschirmsitzung kann jederzeit verlassen werden, indem Sie zuerst "Strg-a" und dann "d" drücken. Um die Bildschirmsitzung wieder zu betreten, geben Sie den folgenden Befehl re-attach ein:

screen -h 10000 -r

Das Skript führt folgende Schritte aus:

Vergleichen Sie die Prüfsumme jeder Datenbankdatei zwischen Primär- und Standby-System.
Stoppen des Dienstes eranger-server auf dem Standby, falls er läuft
Die Dateien /var/lib/pgsql/data/recovery.signal und skoor-replication.conf (die in postgresql.skoor.conf enthalten ist) werden auf dem Standby angelegt. Diese ermöglichen es dem Standby, die IP-Adresse des primären Systems, den Replikationsport, die Anmeldedaten und den Pfad zur Triggerdatei zu kennen. Im Folgenden wird ein Beispiel für eine skoor-replication.con-Datei auf dem Standby-Server gezeigt:
```
primary_conninfo = 'host=10.1.0.88 port=5432 user=replication password=replication'
promote_trigger_file = '/tmp/postgresql.trigger.5432'
```
Die Datei promote_trigger_file existiert nicht, wenn die Replikation läuft. Wenn sie erstellt wird, wird die Replikation beendet (z. B. im Falle eines Switch/Failover).
recovery.signal ist nur eine Markierungsdatei und daher leer.
Die Teile der Datenbank, die sich zwischen den beiden Hosts unterscheiden, werden mit einem rsync over ssh-Prozess übertragen. Die folgenden Pfade sind vom Sync-Prozess ausgeschlossen:
- /var/lib/pgsql/data/pg_xlog/ (die binären Logs, d.h. die WAL-Dateien, werden während createstandby nicht synchronisiert, ihr Inhalt wird erst repliziert, nachdem der createstandby-Prozess gestartet wurde)
- /var/lib/pgsql/data/recovery.signal
- /var/lib/pgsql/data/skoor-replication.conf
- /var/lib/pgsql/data/postmaster.pid
Die Replikation wird gestartet

Während der Erstellung des Standby-Systems kann der Primärserver normal verwendet werden, um Messdaten von den Kollektoren entgegenzunehmen. Auch die SKOOR-Webschnittstelle kann verwendet werden, allerdings kann die Leistung aufgrund der Prüfsummenberechnungen und der Übertragung großer Dateien über das Netzwerk beeinträchtigt sein.
Die Zeit, die benötigt wird, um eine Replikation zum ersten Mal zu initialisieren, hängt hauptsächlich von der Größe der Datenbank, der Netzwerkgeschwindigkeit und der Leistung des Hosts ab.

Jedem Kommentar zu den Aufgaben des Skripts ist die IP-Adresse des Rechners vorangestellt, auf dem die Aufgabe ausgeführt wird.

Nachdem der Befehl ausgeführt wurde, überprüfen Sie seinen Exit-Code. Er sollte Null sein:

...
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

Die Replikation ist nun gestartet und von nun an werden alle Datenbankabfragen, die auf dem primären Rechner ausgeführt werden, sofort auf den Standby-Rechner repliziert.

Modi