In diesem Abschnitt wird die Datenbank-Failover-Funktionalität für Appliances mit Version 9.0.0 oder höher beschrieben. Bei diesen Appliances ist der Failover vollständig automatisiert, es sei denn, eine Dienstanbieter-Appliance wird unerwartet heruntergefahren. In diesem Fall besteht weiterhin ein manueller Vorgang.

Hinweis: Dieser Abschnitt gilt nur für Appliances, auf denen Version 9.0.0 oder höher ausgeführt wird. Weitere Informationen zu älteren Appliances finden Sie unter Datenbank-Failover – Legacy-Appliances.

Automatisierter Failover

Die Funktionalität des automatisierten Failovers umfasst Folgendes.
  • Einzelne Datenquellenverbindung: Alle Appliances verwenden jetzt eine einzelne Datenquellenverbindung, die über den neuen Dienst „pgbouncer“ geproxyt wird. pgbouncer ist ein Verbindungspooler, der Verbindungen zu den zugrunde liegenden Postgres-Datenbanken aufrechterhält und gleichzeitig einen einzigen Verbindungspunkt für die Appliance-Dienste bereitstellt. Dieser Dienst verarbeitet außerdem alle Failover- und Mastermigrationen. Er wird automatisch aktualisiert, um auf die neue Masterdatenbank zu verweisen und so einen nahtlosen Übergang zwischen den Mastern zu ermöglichen.
  • Kontrollierter Switchover der Masterdatenbank beim Herunterfahren oder Neustarten: Bei jedem vom Gast initiierten Herunterfahren oder Neustart des aktuellen Datenbankmaster wird die Masterrolle kontrolliert auf die andere Appliance im HV-Paar migriert. Dies führt nur zu einer geringfügigen Unterbrechung der Funktionsweise der Appliances, die hauptsächlich Desktopverbindungen über das Blast-Portal (Web) beeinträchtigt. Die über die Horizon Client vorgenommenen Desktopverbindungen sind davon nicht betroffen. Es gibt auch einen kurzen Zeitraum der Nichtverfügbarkeit von „horizonadmin“, und Benutzer, die während des Switchover eine Desktopverbindung anfordern, erhalten möglicherweise eine Fehlermeldung, dass keine Desktops verfügbar sind (es wird jedoch kurz danach versucht, eine Verbindung mit einem Desktop herzustellen).
  • Automatischer Failover des Datenbankmaster bei unerwartetem Ausfall der Mandanten-Appliance: Masterausfälle werden jetzt automatisch erkannt, gefolgt von einer Anforderung an die Dienstanbieter-Appliances, um zu überprüfen, ob die Appliance tatsächlich ausgefallen ist. Der Failover-Vorgang wird dann nach einer dreiminütigen Verzögerung initiiert. Dieser neue Failover-Vorgang ist weniger unterbrechend als bei früheren Failover-Vorgängen und lässt den Slony-Cluster anschließend in einem normalen Replizierungsstatus. Nach einem Failover ist keine Slony-Neuinitialisierung erforderlich.
Diese Funktionen werden von den unten beschriebenen Diensten unterstützt.
Dienst Beschreibung Speicherort des Protokolls Hinweise
pgbouncer Verbindungspooler, der Datenbankverbindungen zwischen den Plattformdiensten und Postgres brokert. /var/log/pgbouncer/
  • Verbindungen zu Postgres über den psql-Befehl werden jetzt standardmäßig über pgbouncer durchgeführt. Dadurch wird unabhängig von der verwendeten Appliance eine Verbindung zur Masterdatenbank hergestellt. Um eine Verbindung zu einer bestimmten Datenbankinstanz herzustellen, verwenden Sie die -h- und -p-Flags mit psql. Sie müssen außerdem Port 6432 angeben, um direkt eine Verbindung zu Postgres herzustellen. Beispiel:
    psql -U admin -h ‹Appliance_IP› -p 6432 fdb
  • Sie können die Konfiguration von pgbouncer in „/etc/pgbouncer/pgbouncer.ini“ daraufhin überprüfen, ob sie auf die richtigen Appliances verweist. Die Verbindungszeichenfolgen oben in der Datei sollten auf den aktuellen Slony-Master verweisen. Ist dies nicht der Fall, wird das Problem in den meisten Fällen durch einen Neustart der Appliance behoben.
Dbmonitor Überwachungsdienst mit folgender Funktionsweise:
  • Erkennt Masterausfälle und initiiert den neuen Failover-Prozess.
  • Erkennt Änderungen am Slony-Master-Knoten, die durch den kontrollierten Switchover oder die erneute Subskription verursacht wurden, und aktualisiert pgbouncer mit der neuen Masteradresse entsprechend.
 /var/log/dbmonitor/
Switchover Das Skript wird beim Herunterfahren ausgeführt, um eine Switchover-Aktion durchzuführen. /var/log/desktone/slony-services
Erneute Subskription Das Skript wird beim Hochfahren ausgeführt, um eine Aktion für eine erneute Subskription durchzuführen. /var/log/desktone/slony-services

Manueller Failover der Dienstanbieter-Appliance

Wenn eine Dienstanbieter-Appliance unerwartet heruntergefahren wurde, können Sie einen manuellen Failover durchführen, indem Sie die folgenden Schritte auf der anderen Dienstanbieter-Appliance durchführen.
  1. Führen Sie das Failover-Slony-Master-Skript (unter „/usr/local/desktone/scripts/“) als Stamm durch: 
    failover-slony-master <database type> '<database password>'
    wobei <Datenbanktyp> FDB, EDB oder AVDB ist.
  2. Bestätigen Sie, dass die Datei „pgbouncer.ini“ auf die Front-End-IP-Adresse der aktuellen Appliance verweist:
    /usr/local/desktone/scripts# grep '<IP address>' /etc/pgbouncer/pgbouncer.ini
  3. Laden Sie den pgbouncer-Dienst neu: 
    service pgbouncer reload
  4. Bestätigen Sie den Masterstatus und die Replizierung, indem Sie den Slony-Status ausführen:
    /usr/local/desktone/scripts# slony-status <org #>