Einführung

Vor einiger Zeit wurde mir die Aufgabe gestellt, ein ausfallsicheres Cluster zu entwickeln für PostgreSQL, das in mehreren Rechenzentren innerhalb einer Stadt über Glasfasern verbunden ist und in der Lage ist, den Ausfall (zum Beispiel durch Stromausfall) eines Rechenzentrums zu überstehen. Als Software, die für die Ausfallsicherheit verantwortlich ist, habe ich mich für entschieden Pacemaker, weil dies die offizielle Lösung von RedHat zur Erstellung ausfallsicherer Cluster ist. Sie hat den Vorteil, dass RedHat Support dafür bereitstellt und dass diese Lösung universell (modular) ist. Mit ihrer Hilfe kann die Ausfallsicherheit nicht nur für PostgreSQL, sondern auch für andere Dienste gewährleistet werden, entweder durch die Verwendung standardmäßiger Module oder durch die Erstellung solcher Module für spezifische Bedürfnisse.

Zu dieser Lösung stellte sich die berechtigte Frage: Wie ausfallsicher wird das ausfallsichere Cluster sein? Um dies zu untersuchen, habe ich einen Teststand entwickelt, der verschiedene Ausfälle an den Knoten des Clusters simuliert, auf die Wiederherstellung der Betriebsfähigkeit wartet, den ausgefallenen Knoten wiederherstellt und die Tests im Kreis fortsetzt. Ursprünglich wurde dieses Projekt hapgsql genannt, aber im Laufe der Zeit hat mir der Name, der nur einen Vokal enthält, nicht mehr gefallen. Daher begann ich, ausfallsichere Datenbanken (und die auf sie verweisenden float IPs) zu nennen krogan (eine Figur aus einem Computerspiel, bei dem alle wichtigen Organe verdoppelt sind), während ich die Knoten, Cluster und das gesamte Projekt als tuchanka (den Planeten, auf dem die Kroganer leben) benannte.

Jetzt hat die Führung genehmigt, das Projekt als Open Source unter der MIT-Lizenz zu veröffentlichen.Das README wird in Kürze ins Englische übersetzt (da erwartet wird, dass die Hauptnutzer Entwickler von Pacemaker und PostgreSQL sein werden), und die alte russische Version des README habe ich entschieden, (teilweise) in Form dieses Artikels zu gestalten.

Die Cluster werden auf virtuellen Maschinen VirtualBoxbereitgestellt. Insgesamt werden 12 virtuelle Maschinen bereitgestellt (insgesamt 36GiB), die 4 ausfallsichere Cluster bilden (verschiedene Varianten). Die ersten beiden Cluster bestehen aus zwei PostgreSQL-Servern, die in verschiedenen Rechenzentren untergebracht sind, und einem gemeinsamen Server witness c quorum device (untergebracht auf einer günstigen virtuellen Maschine im dritten Rechenzentrum), der die Ungewissheit löst 50%/50%, indem er seine Stimme einer der Parteien gibt. Der dritte Cluster ist in drei Rechenzentren: ein Master, zwei Slaves, ohne quorum device. Der vierte Cluster besteht aus vier PostgreSQL-Servern, zwei in jedem Rechenzentrum: einem Master und den übrigen Replikaten, und verwendet ebenfalls witness c quorum device. Der vierte Cluster hält den Ausfall von zwei Servern oder eines Rechenzentrums stand. Diese Lösung kann bei Bedarf auf eine größere Anzahl von Replikaten skaliert werden.

Echtzeit-Dienst ntpd wurde ebenfalls für Fehlertoleranz umkonfiguriert, verwendet dabei aber die Methode ntpd (orphan mode). Der Hauptserver witness fungiert als zentraler NTP-Server, verteilt seine Zeit an alle Cluster und synchronisiert damit alle Server untereinander. Wenn witness ein Server ausfällt oder isoliert wird, beginnt einer der Server im Cluster (innerhalb des Clusters) seine Zeit zu verteilen. Ein unterstützender zwischenspeichernder HTTP-Proxy wurde ebenfalls aufgestellt, witnessmit dessen Hilfe die anderen virtuellen Maschinen Zugriff auf die Yum-Repositories haben. In der Realität werden solche Dienste wie Echtzeit und Proxy sicherlich auf dedizierten Servern gehostet, während sie im Stand auf witness aus wirtschaftlichen Gründen in Virtual Machines platziert sind.

Versionen

v0. Funktioniert mit CentOS 7 und PostgreSQL 11 auf VirtualBox 6.1.

Clusterstruktur

Alle Cluster sind dafür ausgelegt, in mehreren Rechenzentren untergebracht zu werden, sind in einem flachen Netzwerk verbunden und müssen den Ausfall oder die Netzwerkarbeit eines Rechenzentrums überstehen. Daher nicht möglich ist verwendet man zur Schutz gegen split-brain die Standardtechnologie Pacemaker, die als STONITH (Shoot The Other Node In The Head) oder Fencing. Ihr Kern besteht darin, dass, wenn die Knoten im Cluster anfangen, zu vermuten, dass mit einem bestimmten Knoten etwas nicht stimmt, er nicht reagiert oder sich nicht korrekt verhält, sie ihn gezwungen über "externe" Geräte, wie zum Beispiel die IPMI-Steuerkarte oder USV, abschalten. Aber dies funktioniert nur in Fällen, in denen bei einem einzelnen Ausfall des Servers IPMI oder USV weiter funktionieren. Hier ist jedoch Schutz gegen einen weitaus katastrophalen Ausfall geplant, bei dem das gesamte Rechenzentrum ausfällt (zum Beispiel durch Stromausfall). Und bei solch einem Ausfall werden auch alle stonith-Geräte (IPMI, USV usw.) nicht funktionieren.

Stattdessen basiert das System auf der Idee des Quorums. Alle Knoten haben eine Stimme, und nur die Knoten, die mehr als die Hälfte aller Knoten sehen, können arbeiten. Diese Anzahl "mehr als die Hälfte + 1" wird genannt Quota. Wenn das Quorum nicht erreicht wird, entscheidet der Knoten, dass er sich in Netzwerkkonnotation befindet und seine Ressourcen deaktivieren muss, d.h. es ist so eine Schutz vor Split-Brain. Wenn die Software, die für dieses Verhalten verantwortlich ist, nicht funktioniert, sollte ein Watchdog, zum Beispiel auf Basis von IPMI, aktiv werden.

Wenn die Anzahl der Knoten gerade ist (Cluster in zwei Rechenzentren), kann es zu einer sogenannten Unsicherheit kommen 50%/50% (fifty-fifty), wenn eine Netzwerktrennung das Cluster genau in der Mitte teilt. Daher wird für eine gerade Anzahl von Knoten quorum device ein unaufdringlicher Daemon hinzugefügt, der auf der günstigsten virtuellen Maschine im dritten Rechenzentrum ausgeführt werden kann. Er gibt seine Stimme einem der Segmente (das er sieht) und löst somit die 50%/50% Unsicherheit auf. Den Server, auf dem das Quorum-Gerät ausgeführt wird, habe ich genannt witness (Terminologie aus repmgr, hat mir gefallen).

Ressourcen können von einem Ort zum anderen verschoben werden, zum Beispiel von fehlerhaften Servern zu funktionierenden, oder auf Anweisung der Systemadministratoren. Damit die Clients wissen, wo sich die benötigten Ressourcen befinden (wohin sie sich verbinden sollen?), werden schwebende IPs (schwebende IP). Das sind IPs, die Pacemaker zwischen den Knoten verschieben kann (alles befindet sich in einem flachen Netzwerk). Jede von ihnen repräsentiert eine Ressource (Dienst) und wird dort sein, wo man sich verbinden muss, um Zugriff auf diesen Dienst (in unserem Fall die DB) zu erhalten.

Tuchanka1 (Schema mit Verdichtung)

Struktur

Die Idee war, dass wir viele kleine Datenbanken mit geringer Last haben, für die es sich nicht lohnt, einen dedizierten Slave-Server im Hot-Standby-Modus für read-only-Transaktionen zu unterhalten (es besteht keine Notwendigkeit für eine solche Ressourcenverschwendung).

In jedem Rechenzentrum gibt es einen Server. Auf jedem Server laufen zwei Instanzen von PostgreSQL (in der Terminologie von PostgreSQL werden sie Cluster genannt, aber um Verwirrung zu vermeiden, nenne ich sie Instanzen, analog zu anderen Datenbanken, während ich Cluster nur für die Pacemaker-Cluster verwenden werde). Eine Instanz läuft im Master-Modus und bietet ausschließlich Dienstleistungen an (nur auf sie zeigt die Float-IP). Die zweite Instanz funktioniert als Slave für das zweite Rechenzentrum und wird nur Dienstleistungen anbieten, wenn ihr Master ausfällt. Da eine Instanz (der Master) die meisten Dienste (Anfragen) bereitstellt, werden alle Serverressourcen für den Master optimiert (Speicher wird für den Cache shared_buffers bereitgestellt usw.), jedoch so, dass auch die zweite Instanz über ausreichend Ressourcen verfügt (auch wenn deren Leistung über den Dateisystem-Cache suboptimal ist) für den Fall eines Ausfalls eines der Rechenzentren. Der Slave bietet keine Dienste an (führt keine Read-Only-Anfragen aus), solange der Cluster normal läuft, um Ressourcenkriege mit dem Master auf demselben Gerät zu vermeiden.

Im Fall von zwei Knoten ist die Fehlertoleranz nur bei asynchroner Replikation möglich, da bei synchroner Replikation der Ausfall des Slaves zur Unterbrechung des Masters führt.

Ausfall Witness

Ausfall Witness (quorum device) werde ich nur für das Cluster Tuchanka1 betrachten, für alle anderen wird die Situation die gleiche sein. Bei einem Ausfall des Witness ändert sich in der Cluster-Struktur nichts, alles funktioniert weiterhin wie gehabt. Aber das Quorum wird 2 aus 3 betragen, und jeder weitere Ausfall wird daher fatal für den Cluster sein. Es wird dennoch notwendig sein, es dringend zu reparieren.

Ausfall Tuchanka1

Ausfall eines der Rechenzentren für Tuchanka1. In diesem Fall witness gibt es seine Stimme dem zweiten Knoten im zweiten Rechenzentrum. Dort verwandelt sich der ehemalige Slave in einen Master, sodass auf einem Server beide Master laufen und beide ihre Float-IPs haben.

Tuchanka2 (klassisch)

Struktur

Klassisches Schema mit zwei Knoten. Auf einem läuft der Master, auf dem anderen der Slave. Beide können Anfragen verarbeiten (der Slave nur Read-Only), daher zeigen beide Float-IPs an: krogan2 — auf den Master, krogan2s1 — auf den Slave. Die Fehlertoleranz ist sowohl beim Master als auch beim Slave gegeben.

Im Fall von zwei Knoten ist die Fehlertoleranz nur bei asynchroner Replikation möglich, denn bei synchroner Replikation führt der Ausfall des Slaves zur Unterbrechung des Masters.

Ausfall Tuchanka2

Beim Ausfall eines der Rechenzentren witness Er stimmt für die zweite. Auf dem einzigen funktionierenden Rechenzentrum wird ein Master erstellt, auf den beide float IPs zeigen: die Master- und die Slave-IP. Selbstverständlich muss die Instanz so konfiguriert sein, dass sie über ausreichend Ressourcen (Limits für Verbindungen usw.) verfügt, um gleichzeitig alle Verbindungen und Anfragen von der Master- und Slave-float-IP zu akzeptieren. Das bedeutet, dass sie bei normalem Betrieb über ausreichende Limits verfügen muss.

Tuchanka4 (viele Slaves)

Struktur

Es gibt bereits eine andere Extremität. Manchmal gibt es Datenbanken, die sehr viele read-only-Anfragen erhalten (ein typischer Fall einer stark belasteten Website). Tuchanka4 ist eine Situation, in der es drei oder mehr Slaves geben kann, um solche Anfragen zu verarbeiten, aber dennoch nicht zu viele. Bei einer sehr großen Anzahl von Slaves muss ein hierarchisches Replikationssystem erfunden werden. Im minimalen Fall (auf dem Bild) gibt es in jedem der beiden Rechenzentren zwei Server, auf jedem davon läuft eine PostgreSQL-Instanz.

Eine weitere Besonderheit dieses Schemas ist, dass hier bereits eine synchrone Replikation eingerichtet werden kann. Diese ist so konfiguriert, dass sie nach Möglichkeit in ein anderes Rechenzentrum repliziert, und nicht auf eine Replik im selben Rechenzentrum, in dem sich der Master befindet. Die float IP zeigt auf den Master und auf jeden Slave. Im Idealfall sollte zwischen den Slaves eine Anfragerobustheit hergestellt werden. sql proxy, zum Beispiel auf der Clientseite. Verschiedene Typen von Clients benötigen möglicherweise unterschiedliche Typen sql proxy, und nur die Entwickler der Clients wissen, welcher Typ welcher benötigt. Diese Funktionalität kann sowohl von einem externen Daemon als auch von einer Client-Bibliothek (Connection Pool) usw. realisiert werden. All dies liegt außerhalb des Themas der hochverfügbaren Datenbankcluster (Hochverfügbarkeit SQL proxy lässt sich unabhängig realisieren, zusammen mit der Klientenverfügbarkeit).

Ausfall Tuchanka4

Bei einem Ausfall eines Rechenzentrums (d.h. zwei Server) stimmt der Witness für den zweiten. Infolgedessen arbeiten in dem zweiten Rechenzentrum zwei Server: auf einem läuft der Master, und auf diesen zeigt die Master-float-IP (für die Annahme von read-write-Anfragen); und auf dem zweiten Server arbeitet ein Slave mit synchroner Replikation, und auf diesen zeigt eine der Slave-float-IPs (für read-only-Anfragen).

Das erste, was zu beachten ist: Arbeitsfähige Slave-float-IPs werden nicht alle sein, sondern nur eine. Und für die korrekte Arbeit mit dieser muss sichergestellt sein, dass sql proxy Alle Anfragen wurden an die einzig verbleibende float IP umgeleitet; falls nicht, sql proxy kann man alle float IPs der Slaves durch Kommas in der URL für die Verbindung auflisten. In diesem Fall wird die libpq Verbindung zum ersten aktiven IP hergestellt, so ist es im System für automatisiertes Testen implementiert. Möglicherweise wird es in anderen Bibliotheken, wie JDBC, nicht so funktionieren, und es ist erforderlich, sql proxy. Dies wurde so gemacht, weil für float IPs der Slaves ein Verbot besteht, gleichzeitig auf demselben Server zu laufen, damit sie gleichmäßig über die Slave-Server verteilt werden, wenn mehrere betrieben werden.

Zweitens: Selbst im Falle eines Ausfalls des Rechenzentrums wird die synchrone Replikation erhalten bleiben. Und selbst wenn ein sekundärer Ausfall passiert, also wenn einer der beiden Server im verbleibenden Rechenzentrum ausfällt, wird der Cluster zwar aufhören, Dienste anzubieten, jedoch die Informationen über alle bestätigten Transaktionen, für die er eine Commit-Bestätigung gegeben hat, behalten (keine Informationsverluste bei sekundären Ausfällen).

Tuchanka3 (3 Rechenzentren)

Struktur

Dies ist ein Cluster für eine Situation, in der es drei voll funktionierende Rechenzentren gibt, in denen jeweils ein voll funktionierender DB-Server vorhanden ist. In diesem Fall quorum device nicht nötig. In einem Rechenzentrum läuft der Master, in den beiden anderen — Slaves. Die Replikation ist synchron, vom Typ ANY (slave1, slave2), das heißt, der Kunde erhält die Bestätigung des Commits, wenn einer der Slaves zuerst antwortet, dass er den Commit angenommen hat. Es gibt eine float IP für den Master und zwei für die Slaves. Im Gegensatz zu Tuchanka4 sind alle drei float IPs ausfallsicher. Für die Lastenverteilung von read-only SQL-Anfragen kann man sql proxy (mit separater Ausfallsicherheit) verwenden, oder der einen Hälfte der Kunden eine Slave-float IP zuweisen und der anderen Hälfte die zweite.

Ausfall Tuchanka3

Im Falle eines Ausfalls eines der Rechenzentren bleiben zwei übrig. In einem ist der Master und die float IP vom Master aktiv, im anderen — ein Slave und beide Slave-float IPs (auf der Instanz sollte eine doppelte Ressourcensicherung vorhanden sein, um alle Verbindungen von beiden Slave-float IPs anzunehmen). Zwischen Master und Slave gibt es eine synchrone Replikation. Außerdem wird der Cluster die Informationen über die bestätigten und abgeschlossenen Transaktionen beibehalten (keine Informationsverluste) im Fall der Zerstörung zweier Rechenzentren (sofern sie nicht gleichzeitig zerstört werden).

Eine detaillierte Beschreibung der Dateistruktur und der Bereitstellung habe ich beschlossen, nicht einzufügen. Wer spielen möchte, kann das alles im README nachlesen. Ich gebe nur die Beschreibung des automatisierten Testsystems an.

Automatisches Testsystem

Zur Überprüfung der Ausfallsicherheit von Clustern unter Simulation verschiedener Störungen wurde ein automatisches Testsystem entwickelt. Es wird durch ein Skript gestartet test/failure. Das Skript kann Cluster-IDs als Parameter annehmen, die getestet werden sollen. Zum Beispiel dieser Befehl:

test/failure 2 3

testet nur den zweiten und dritten Cluster. Wenn keine Parameter angegeben sind, werden alle Cluster getestet. Alle Cluster werden parallel getestet, und die Ergebnisse werden im Tmux-Paneel ausgegeben. Tmux verwendet einen dedizierten Tmux-Server, daher kann das Skript aus dem Standard-Tmux gestartet werden, wodurch ein verschachtelter Tmux entsteht. Ich empfehle, ein großes Terminal mit kleiner Schriftgröße zu verwenden. Vor Beginn des Tests werden alle VMs auf den Snapshot zum Zeitpunkt des Skriptabschlusses zurückgesetzt. setup.

Das Terminal ist in Spalten entsprechend der Anzahl der getesteten Cluster aufgeteilt, standardmäßig (im Screenshot) sind es vier. Ich werde den Inhalt der Spalten am Beispiel von Tuchanka2 weiter erläutern. Die Paneele auf dem Screenshot sind nummeriert:

1. Hier werden die Statistiken der Tests angezeigt. Spalten:
   • failure — der Name des Tests (Funktion im Skript), der die Störung emuliert.
   • Reaktion — die durchschnittliche Zeit in Sekunden, die benötigt wird, damit der Cluster seine Betriebsfähigkeit wiederherstellt. Gemessen wird ab dem Beginn der Skriptausführung, das die Störung emuliert, bis zu dem Zeitpunkt, an dem der Cluster seine Betriebsfähigkeit wiederherstellt und weiterhin Dienste anbieten kann. Wenn die Zeit sehr kurz ist, zum Beispiel sechs Sekunden (was in Clustern mit mehreren Arbeitern (Tuchanka3 und Tuchanka4) vorkommen kann), bedeutet dies, dass die Störung auf einem asynchronen Arbeiter aufgetreten ist und sich nicht auf die Betriebsfähigkeit ausgewirkt hat, es gab keine Statuswechsel im Cluster.
   • deviation — zeigt die Streuung (Präzision) des Wertes Reaktion durch die Methode „Standardabweichung“ an.
   • count — wie oft dieser Test ausgeführt wurde.
2. Das kurze Protokoll gibt Aufschluss darüber, womit der Cluster gerade beschäftigt ist. Es wird die Iterationsnummer (Test), der Zeitstempel und der Name der Operation angezeigt. Eine zu lange Ausführung (> 5 Minuten) weist auf ein Problem hin.
3. heart (Herz) — die aktuelle Zeit. Zur visuellen Beurteilung der Funktionalität Meister wird in seine Tabelle ständig die aktuelle Zeit unter Verwendung der Float-IP des Meisters geschrieben. Bei Erfolg wird das Ergebnis in diesem Panel angezeigt.
4. Schlag (Puls) — die „aktuelle Zeit“, die zuvor vom Skript aufgezeichnet wurde heart in den Meister, wird jetzt gelesen von Slave durch seine Float-IP. Dies ermöglicht eine visuelle Beurteilung der Funktionalität des Slaves und der Replikation. In Tuchanka1 gibt es keine Slaves mit Float-IP (keine Slaves, die Dienstleistungen erbringen), aber es gibt zwei Instanzen (DB), daher wird hier nicht Schlag, und heart die zweite Instanz angezeigt.
5. Überwachung des Cluster-Zustands mit dem Tool pcs mon. Zeigt die Struktur, Ressourcenzuteilung nach Knoten und andere nützliche Informationen an.
6. Hier wird das Systemmonitoring von jeder virtuellen Maschine des Clusters angezeigt. Es kann mehr solcher Panels geben — je nach Anzahl der virtuellen Maschinen im Cluster. Zwei Diagramme CPU-Auslastung (in virtuellen Maschinen mit zwei Prozessoren), Name der virtuellen Maschine, Systemauslastung (genannt Load Average, weil er über 5, 10 und 15 Minuten gemittelt ist), Daten zu Prozessen und Speicherzuweisung.
7. Nachverfolgung des Skripts, das die Tests durchführt. Im Falle eines Fehlers — plötzlicher Arbeitsunterbrechung oder endlosem Wartezyklus — kann hier die Ursache für solches Verhalten gesehen werden.

Die Tests werden in zwei Phasen durchgeführt. Zuerst durchläuft das Skript alle Testarten, wählt zufällig die virtuelle Maschine aus, auf die dieser Test angewendet werden soll. Danach wird ein unendlicher Testzyklus durchgeführt, bei dem sowohl die virtuellen Maschinen als auch der Fehler jedes Mal zufällig ausgewählt werden. Ein plötzlicher Abschluss des Testskripts (unteres Panel) oder ein endloser Wartezyklus auf etwas (> 5 Minuten Ausführungszeit einer Operation, was in der Nachverfolgung sichtbar ist) deutet darauf hin, dass einer der Tests auf diesem Cluster fehlgeschlagen ist.

Jeder Test besteht aus folgenden Operationen:

1. Ausführen einer Funktion, die einen Fehler emuliert.
2. Bereit? — Warten auf die Wiederherstellung der Funktionalität des Clusters (wenn alle Dienstleistungen bereitgestellt werden).
3. Angezeigt wird die Wartezeit bis zur Wiederherstellung des Clusters (Reaktion).
4. Reparatur — der Cluster wird „repariert“. Danach sollte er in den vollständig funktionsfähigen Zustand zurückkehren und bereit für den nächsten Fehler sein.

Hier ist eine Liste der Tests mit einer Beschreibung, was sie tun:

• ForkBomb: erzeugt "Out of memory" mit einer Fork-Bombe.
• OutOfSpace: der Festplattenspeicher ist voll. Der Test ist jedoch eher symbolisch, da bei der geringen Last, die beim Testen entsteht, in der Regel keine Ausfälle von PostgreSQL auftreten, wenn die Festplatte voll ist.
• Postgres-KILL: tötet PostgreSQL mit dem Befehl killall -KILL postgres.
• Postgres-STOP: hängt PostgreSQL mit dem Befehl killall -STOP postgres.
• PowerOff: „schaltet“ die virtuelle Maschine mit dem Befehl aus VBoxManage controlvm "виртуалка" poweroff.
• Reset: startet die virtuelle Maschine mit dem Befehl neu VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: hängt den SBD-Daemon mit dem Befehl killall -STOP sbd.
• ShutDown: sendet über SSH den Befehl an die virtuelle Maschine systemctl poweroff, das System beendet korrekt den Betrieb.
• UnLink: Netzwerkisolierung, Befehl VBoxManage controlvm "виртуалка" setlinkstate1 off.

Beenden des Tests entweder mit dem Standardbefehl tmux "kill-window" Ctrl-b &, oder mit dem Befehl "detach-client" Ctrl-b d: dabei endet der Test, tmux wird geschlossen, und die virtuellen Maschinen werden heruntergefahren.

Die beim Testen aufgetretenen Probleme

• Zur Zeit der watchdog Daemon sbd verarbeitet das Stoppen der überwachten Daemonen, jedoch nicht deren Hängenbleiben. Folglich werden Fehler, die nur zu einem Hängenbleiben führen, fehlerhaft behandelt. Corosync und Pacemaker, aber sie hängen dabei nicht auf sbd. Zur Überprüfung Corosync gibt es bereits PR#83 (in GitHub bei sbd), verabschiedet in den Branch master. Versprochen wurde (in PR#83), dass es auch für Pacemaker etwas Ähnliches geben wird, ich hoffe, dass dies bis RedHat 8 realisiert wird. Doch solche „Fehler“ sind theoretisch, sie lassen sich leicht künstlich imitieren, zum Beispiel killall -STOP corosync, kommen jedoch in der Realität niemals vor.

• Der Pacemaker In der Version für CentOS 7 ist das sync_timeout arbeiten quorum devicefalsch gesetzt, mit der Folge, dass bei einem Ausfall eines Knotens mit einer gewissen Wahrscheinlichkeit auch der zweite Knoten neu gestartet wurde, auf den der Master überwechseln sollte. Dieser Fehler wurde durch Erhöhung sync_timeout arbeiten quorum device während des Setups (im Skript setup/setup1) behoben. Diese Korrektur wurde von den Entwicklern nicht akzeptiert, stattdessen haben sie versprochen, die Infrastruktur so zu überarbeiten (irgendwann in der unbestimmten Zukunft), dass dieser Timeout automatisch berechnet wird. PacemakerWenn bei der Konfiguration der Datenbank angegeben ist, dass in

• LC_MESSAGES (Textnachrichten) Unicode verwendet werden kann, zum Beispiel ru_RU.UTF-8 , dann wird bei der Ausführung vonpostgres in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier pacemaker pgsqlms+(paf) gestartet wird, werden im Log anstelle von UTF-8-Zeichen Fragezeichen angezeigt. in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier), dann Die Entwickler von PostgreSQL haben sich nicht darauf geeinigt, was in diesem Fall zu tun ist. Das kann umgangen werden, indem manLC_MESSAGES=en_US.UTF-8 setzt. Bei der Konfiguration (Erstellung) einer DB-Instanz.

• Wenn wal_receiver_timeout eingestellt ist (standardmäßig 60s), findet beim Test PostgreSQL-STOP auf dem Master in den Clustern tuchanka3 und tuchanka4 keine Wiederverbindung der Replikation zum neuen Master statt.Die Replikation dort ist synchron, daher stoppt nicht nur der Slave, sondern auch der neue Master. Dies wird durch Setzen von wal_receiver_timeout=0 bei der PostgreSQL-Konfiguration umgangen.

• Selten beobachtete ich ein Hängen der Replikation bei PostgreSQL im ForkBomb-Test (Speicherüberlauf). Nach ForkBomb können die Slaves manchmal nicht zum neuen Master reconnecten.Ich habe so etwas nur in den Clustern tuchanka3 und tuchanka4 erlebt, wo der Master aufgrund der synchronen Replikation hängen blieb. Das Problem verschwand von selbst nach einiger Zeit (etwa zwei Stunden). Zusätzliche Untersuchungen sind erforderlich, um dies zu beheben. Nach den Symptomen scheint es sich um einen vorherigen Fehler zu handeln, der durch einen anderen Grund verursacht wird, aber mit denselben Konsequenzen.

Das Krogans-Bild wurde von Deviant Art mit Genehmigung des Autors entnommen:

Quelle: habr.com