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/ |
|
Dbmonitor | Überwachungsdienst mit folgender Funktionsweise:
|
/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.
- 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. - 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
- Laden Sie den pgbouncer-Dienst neu:
service pgbouncer reload
- 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 #>