Datenbank-Replikationskonzept

Die Architektur

Die SKOOR Engine verwendet eine PostgreSQL-Datenbank, um ihre Konfigurationsdaten sowie ihre historischen Werte und Verlaufsdaten zu speichern. Es unterstützt die Verwendung eines Master / Slave -Setups, um die Datenbankinhalte kontinuierlich zu replizieren. Es werden die eigenen Replikationsmethoden von PostgreSQL verwendet, was bedeutet, dass eine exakte Kopie der Datenbank auf dem Master auf dem Slave gehalten wird und alle Aktualisierungen der Datenbank auf dem Master - Server sofort auf den Slave repliziert werden. Der Master - Server puffert die SQL-Statements in einem Binärlog, der Slave - Server fordert diese Statements vom Server an.

Dies gewährleistet kurze Ausfallzeiten bei Hardwareausfällen. Es schützt jedoch NICHT vor Pilotfehlern wie fehlerhaften Löschanweisungen, die sofort mit dem Slave synchronisiert werden. Die Replikation ersetzt keine regelmäßigen Backups.

Die folgende Abbildung zeigt ein Beispiel für ein standardmäßiges Replikationslayout.

Im Standardmodus trägt der Master die gesamte Last, alle Benutzeranfragen werden vom Apache-Webserver auf dem Master beantwortet, Messdaten werden von den Kollektoren an den aktuellen Master - Server geliefert und in der Datenbank gespeichert. Die Dienste eranger- Server , Kollektor -Kollektor und eranger-report laufen NICHT auf dem Slave - Server .

Hauptmerkmale des Replikations-Setups

  • Die Replikation kann sogar mit externen Kollektoren .
  • Wenn zuvor eine Replikation durchgeführt wurde, ist ein großer Teil der Datenbankdateien wahrscheinlich bereits synchronisiert. Das Skript überträgt KEINE alten Tabellen, die bereits synchronisiert sind. Dies spart Netzwerkbandbreite, wenn eine Neuinitialisierung durchgeführt werden muss.
  • Es gibt kein automatisches Failover vom Master zum Slave . Es wurde entwickelt, um diese Entscheidung einem Menschen zu überlassen. Das Skript unterstützt jedoch einen nicht interaktiven Modus, der das Ausgeben eines Failovers durch ein Skript ermöglichen würde. (Option -f ).
  • Möglichkeit, den Master vom Slave (unabhängig von SKOOR) zu überwachen, indem eine E-Mail gesendet wird, sobald festgestellt wird, dass die SKOOR Engine nicht mehr auf dem aktuellen Master läuft.
  • Möglichkeit, benutzerdefinierte Skripte oder Befehle vor und/oder nach dem Umschalten der Server auszuführen ( Slave zu Master und umgekehrt).

Anforderungen

Zur Einrichtung der Datenbankreplikation wird ein zweiter SKOOR Server mit den gleichen Leistungsdaten wie der erste benötigt. Obwohl sich dieser Slave die meiste Zeit im Standby-Modus befindet, muss er in der Lage sein, die volle Last zu tragen, wenn seine Funktion von Slave zu Master wechselt.

Folgende Voraussetzungen müssen erfüllt sein:

  • Dieselbe Version von SKOOR ist auf Master und Slave installiert.
  • (Optional) externe Kollektoren sind korrekt eingerichtet und funktionieren.
  • Die Datei Server ist auf Master , Slave und allen Kollektoren . Das bedeutet, dass auf allen beteiligten Hosts dieselbe SKOOR-Version installiert sein muss.
  • Die Datei /etc/opt/eranger/eranger-replication.cfg ist korrekt konfiguriert und auf Master , Slave und allen Kollektoren .
  • Netzwerkkonnektivität
    • TCP-Port 5432 (PostgreSQL) zwischen Master und Slave muss offen sein.
    • TCP Port 22 (ssh) von Master zu Slave , umgekehrt und von Master und Slave zu allen externen Kollektoren .
    • TCP Port 50001 ( Kollektor Datenlieferung) von allen externen Kollektoren an Master und Slave .