Docs

Initialisierung / Standby erstellen

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

Die Aktion createstandby kann aufgrund eines Neustarts der Datenbank (mögliche automatische Konfigurationsänderung) zu einem kurzzeitigen Ausfall des SKOOR-Systems führen. Es ist danach voll funktionsfähig und zugänglich.

Beachten Sie Folgendes:

  • Datenbanken mit einer Größe von 100 GB oder mehr benötigen normalerweise mehr WAL-Dateien als der Standardwert 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, berücksichtigen Sie den freien Speicherplatz auf der Festplatte): 

    wal_keep_size = 4096

  • Das Skript synchronisiert DB - Tabellen von der primären zur Standby - Tabelle . Überprüfen Sie die Größe der gesamten DB mit: 

    du -sh /var/lib/pgsql

    Es ist sehr wahrscheinlich, dass mehrere Gigabyte an Daten zu übertragen sind. In diesem Fall erfolgt die Initialisierung der Replikation am besten abends.

  • Bei der Neuinitialisierung werden nicht alle Dateien kopiert. Wenn mit createstandby schon einmal eine Initialisierung durchgeführt wurde, diese aber wiederholt werden muss, weil aus irgendeinem Grund die Replikation kaputt geht, werden wesentlich weniger Daten vom Primary zum Standby übertragen.

  • Jede Datenbankdatei muss jedoch auf beiden Seiten anhand der Prüfsumme verglichen werden, damit die Replikationsmechanismen feststellen können, welche Dateien übertragen werden müssen. Eine ausschließlich auf Datenbankdateigrößen und deren Änderungszeiten basierende Synchronisierung ist nicht zuverlässig genug. Daher muss vor Beginn der eigentlichen Synchronisierung die gesamte Datenbank auf beiden Seiten einer Prüfsumme unterzogen werden, was je nach Hostleistung und Datenbankgröße mehrere Stunden dauern kann.

  • Es empfiehlt sich, vor Beginn der Initialisierung eine vollständige Sicherung des aktuell aktiven Systems durchzuführen. Dies kann mit dem Befehl erfolgen: 

    cd /var/lib/pgsql
    sudo -u postgres bash -l -c '/opt/eranger/bin/eranger-server-backup.sh full'

    wodurch ein vollständiges Backup auf /opt/eranger/ Server /backups/ gespeichert wird.

Um die Initialisierung zu starten, muss der Befehl createstandby auf der primären . Da dieser Befehl je nach zu übertragender Datenmenge und Netzwerkbandbreite zwischen Primary und Standby mehrere Stunden laufen kann, empfiehlt es sich, den Befehl innerhalb einer Bildschirmsitzung auszuführen. Der Bildschirmbefehl ermöglicht die Ausführung eines Befehls aus der Ferne, ohne dass der Befehl beendet wird, wenn die Verbindung zum Remote-Host aus irgendeinem Grund getrennt wird. Führen Sie eine neue Bildschirmsitzung (mit einem ausreichend großen Verlaufs-Scrollback-Puffer) auf dem Primärserver als Root aus, indem Sie den folgenden Befehl verwenden: 

screen -h 10000

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

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

Das Folgende ist 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. Die folgende Ausgabe wird 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. Die Ausgabe wird in diesem Fall kürzer:

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

# 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 zuerst „Strg-a“ und dann „d“ gedrückt wird. Um erneut in die Bildschirmsitzung einzutreten, geben Sie den folgenden Befehl zum erneuten Anhängen ein: 

screen -h 10000 -r

Das Skript macht folgendes:

  • Vergleichen Sie die Prüfsumme jeder Datenbankdatei zwischen primärer und Standby- Datei.

  • Stoppen Sie den eranger- Server Dienst auf dem Standby-Server, falls er ausgeführt wird

  • Die Dateien /var/lib/pgsql/data/recovery.signal und skoor-replication.conf (die in postgresql.skoor.conf enthalten sind) werden auf dem Standby erstellt. Diese ermöglichen dem Standby , die IP-Adresse des primären , den Replikationsport, die Anmeldeinformationen und den Pfad zur Triggerdatei zu kennen. Das Folgende zeigt ein Beispiel einer skoor-replication.con-Datei auf dem Standby: 

    primary_conninfo = 'host=10.1.0.88 port=5432 user=replication password=replication'
promote_trigger_file = '/tmp/postgresql.trigger.5432'

    Die promote_trigger_file ist nicht vorhanden, wenn die Replikation ausgeführt wird. Wenn Sie es erstellen, wird die Replikation beendet (z. B. im Falle eines Wechsels/Failovers).
    recovery.signal ist nur eine Markierungsdatei und daher leer.

  • Die zwischen den beiden Hosts unterschiedlichen Teile der Datenbank werden mit einem rsync- über -ssh- Prozess übertragen. Die folgenden Pfade sind vom Synchronisierungsprozess ausgeschlossen:

    • /var/lib/pgsql/data/pg_xlog/ (die Binärlogs, dh 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 des createstandby-Vorgangs kann der Primary normal verwendet werden, um Messdaten von Kollektoren zu übernehmen. Auch die SKOOR-Weboberfläche kann verwendet werden, jedoch kann die Leistung aufgrund der Prüfsummenberechnungen und der Übertragung großer Dateien über das Netzwerk beeinträchtigt werden.
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 zur Funktionsweise des Skripts wird die IP-Adresse des Hosts vorangestellt, auf dem die Aufgabe verarbeitet wird.

Nachdem der Befehl ausgeführt wurde, überprüfen Sie seinen Beendigungscode. Es 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 wird nun gestartet und ab sofort werden alle Datenbankabfragen, die auf dem Primary ausgeführt werden, sofort auf den Standby repliziert.

Zurück
Modi
Weiter
Nutzung / Hilfe