News zu Servicewelten
Dbvisit Standby MP ist eine Komplettlösung für die Hochverfügbarkeit und Disaster Recovery (DR) von Datenbanken. Die Software bietet eine intuitive, grafische Benutzeroberfläche und automatisiert komplexe Aufgaben, um die Ausfallsicherheit deiner Systeme zu gewährleisten.
In unserem Beitrag “Dbvisit Standby MultiPlatform (MP) v11 – We are excited!” haben wir das Produkt bereits umfassend vorgestellt und unsere Testerfahrungen festgehalten.
Von Punkten wie
konnten bisher nur Oracle Database und Microsoft SQL Server Kunden profitieren. Seit Version 11.5 unterstützt Dbvisit Standby MP nun auch PostgreSQL Datenbanken ab der Version 10 aufwärts. Wir haben uns auch hier mit den Themen Installation, Aufbau und Konfiguration sowie mit ausgewählten Funktionen beschäftigt. Tatsächlich fällt unser Fazit diesmal nicht ganz so eindeutig aus.
An der Installation und Architektur der Dbvisit Software hat sich erst einmal nichts geändert. Der empfohlene Aufbau bleibt derselbe, wie er auch in der Oracle- und Microsoft SQL Server Umgebung zur Anwendung kommt. Lies dich hier bei Bedarf noch einmal in unserem Beitrag “Dbvisit Standby MP v11 – Getestet für Oracle Datenbanken” ein.
Der Aufbau besteht aus einem “Dbvisit Control Center” – welches über ein Webinterface die grafische Bedienoberfläche bereitstellt – und jeweils einem “Dbvisit Agent” pro PostgreSQL Host. Es ist dabei empfehlenswert, das Control Center auf einem dedizierten Host zu betreiben.
Kennst du bereits die grafische Oberfläche von Dbvisit Standby MP, fällt die Erweiterung nur durch ein neues Schaltelement unter “New Configuration” auf:
Hast du noch keine Standby-Datenbank in Betrieb, unterstützt dich Dbvisit auch hier. Mittels verschiedener Mechanismen (abhängig vom Recovery Model) wird aus der Primärdatenbank auf dem Zielhost eine Standby-Datenbank erstellt. Du kannst hier zwischen zwei Modi wählen. Der größte Unterschied ist – ganz kurz umrissen – dass die Hot Standby Datenbank für Read-Only Queries zur Verfügung steht.
Bei der Wahl des Recovery Models stehen dir die folgenden drei Optionen zur Verfügung:
Über einen Replikations-Slot wird ein dauerhafter “real-time data stream” aufgebaut. Darüber werden der Standby Datenbank alle Transaktionen, die mit einem commit abgeschlossen wurden, präsentiert. Dieser Ansatz nutzt PostgreSQL interne Mechanismen und wird demnach über die PG-Konfigurationsdatei gesteuert. Jede Änderung zieht in der Regel einen Neustart der Instanz nach sich.
Sobald ein WAL File abgeschlossen ist oder nach einem eingestellten Intervall, wird ein Backup des WAL Files erstellt, zur Standby-Datenbank übertragen und dort wiederhergestellt. Dabei wird auf PostgreSQL-Mechanismen (pg_basebackup) und Konfigurationen zurückgegriffen. Die Orchestrierung wird hierbei von der PG Instanz übernommen. Wie in Option 1 werden Änderungen in der Konfigurationsdatei vorgenommen und mit einem Neustart wirksam.
Die Funktion ähnelt der des WAL file archiving, mit dem Unterschied, dass Dbvisit die volle Kontrolle übernimmt – entkoppelt von PostgreSQL Automatismen. Wie in Option 2 nutzt dieser Mechanismus die Funktionen von pg_basebackup, mit dem Unterschied, dass diese nicht von der Instanz gesteuert werden, sondern von externen Prozessen, welche von Dbvisit getriggert werden. Änderungen werden nicht in den PG Konfigurationen durchgeführt und werden auch ohne Neustart wirksam.
Eine fachlich belegte “beste Option” konnten wir bisher noch nicht ausfindig machen. Es ist wohl eine Frage des persönlichen Geschmacks, für welches Recovery Model du dich entscheidest.
Natürlich bietet Dbvisit dir auch einen Überblick des aktuellen Status deiner Konfigurationen:
Um beim Patchen die Downtime so gering wie möglich zu halten, kannst du über die grafische Oberfläche einen Switchover durchführen.
Darüber hinaus hast du die Möglichkeit, über das Control Center sowohl die Primär- als auch die Standby-Datenbank zu starten, zu stoppen oder neu zu starten.
PostgreSQL Datenbanken erfreuen sich nicht zuletzt wegen ihrem großen Funktionsumfang insbesondere auch in produktionskritischen Umgebungen zunehmender Beliebtheit. Daher ist eine Absicherung kritischer Datenbanken beispielsweise mit Hilfe einer Standby Datenbank absolut essentiell in puncto Verfügbarkeit und Sicherheit.
Neben kostenfreien Tools wie dem kommandozeilenbasierten repmgr (beschrieben in unserem Beitrag » PostgreSQL Cluster verwalten) bietet Dbvisit mit Standby MP for PostgreSQL nun eine weitere Alternative für den Aufbau und das Management von PostgreSQL Standby Datenbanken. Insbesondere für Nutzer, welche Dbvisit Standby MP möglicherweise schon für Oracle und/oder SQL Server Datenbanken im Einsatz haben, kann hier die bestehende Software leicht und verständlich, zentralisiert auf PG erweitert werden. Ebenso ist es sicherlich für Administratoren geeignet, die nicht so gern auf der Kommandozeile arbeiten oder auch schlichtweg einen professionellen Support für ihre Software benötigen. Heißt in der Konsequenz also: Kein zwingendes Must-have, aber auf jeden Fall ein absolutes Nice-to-have.
Hier findest du weitere Posts rund um PostgreSQL Datenbanken oder auch HA Technologien wie Cluster, Failsafe oder Failover.
Share this article