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 primären Migrationen. Er wird automatisch aktualisiert, um auf die neue primäre Datenbank zu verweisen und so einen nahtlosen Übergang zwischen den primären Appliances zu ermöglichen.
  • Kontrollierter Switchover der primären Datenbank beim Herunterfahren oder Neustarten: Bei jedem vom Gast initiierten Herunterfahren oder Neustart der aktuellen primären Datenbank wird die primäre Rolle kontrolliert auf die andere Appliance im HA-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 der primären Datenbank bei unerwartetem Ausfall der Mandanten-Appliance: Ausfälle der primären Appliance 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 primären Datenbank 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 primären Slony 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 primäre Ausfälle und initiiert den neuen Failover-Prozess.
  • Erkennt Änderungen am primären Slony-Knoten, die durch den kontrollierten Switchover oder die erneute Subskription verursacht wurden, und aktualisiert pgbouncer mit der neuen primären Adresse 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 Status der primären Appliance und die Replizierung, indem Sie den Slony-Status ausführen:
    /usr/local/desktone/scripts# slony-status <org #>