Einführung

Vor einiger Zeit wurde mir die Aufgabe übertragen, einen Failover-Cluster für zu entwickeln PostgreSQL, der in mehreren Rechenzentren betrieben wird, die über Glasfaser innerhalb derselben Stadt verbunden sind, und in der Lage ist, den Ausfall (z. B. einen Stromausfall) eines Rechenzentrums zu überstehen. Als Software, die für Fehlertoleranz verantwortlich ist, habe ich mich entschieden Pacemaker, da dies die offizielle Lösung von RedHat zum Erstellen von Failover-Clustern ist. Das ist gut, weil RedHat dafür Unterstützung bietet und weil diese Lösung universell (modular) ist. Mit seiner Hilfe wird es möglich sein, Fehlertoleranz nicht nur für PostgreSQL, sondern auch für andere Dienste bereitzustellen, indem entweder Standardmodule verwendet oder für spezifische Anforderungen erstellt werden.

Bei dieser Entscheidung stellte sich die berechtigte Frage: Wie fehlertolerant wird ein Failover-Cluster sein? Um dies zu untersuchen, habe ich einen Prüfstand entwickelt, der verschiedene Ausfälle auf den Knoten des Clusters simuliert, auf eine Wiederherstellung wartet, den ausgefallenen Knoten wiederherstellt und den Test in einer Schleife fortsetzt. Anfangs hieß dieses Projekt hapgsql, aber mit der Zeit wurde mir der Name, der nur einen Vokal hat, langweilig. Daher begann ich, fehlertolerante Datenbanken zu benennen (und darauf verweisende Float-IPs). Krogan (eine Figur aus einem Computerspiel, in der alle wichtigen Organe dupliziert sind) sowie Knoten, Cluster und das Projekt selbst Tuchanka (der Planet, auf dem die Kroganer leben).

Das Management hat nun zugestimmt Öffnen Sie ein Projekt für die Open-Source-Community unter der MIT-Lizenz. Die README-Datei wird bald ins Englische übersetzt (da die Pacemaker- und PostgreSQL-Entwickler voraussichtlich die Hauptkonsumenten sein werden), und ich habe beschlossen, die alte russische Version der README-Datei (teilweise) in Form dieses Artikels herauszugeben.

Cluster werden auf virtuellen Maschinen bereitgestellt VirtualBox. Insgesamt werden 12 virtuelle Maschinen bereitgestellt (insgesamt 36 GB), die 4 Failover-Cluster bilden (verschiedene Optionen). Die ersten beiden Cluster bestehen aus zwei PostgreSQL-Servern, die sich in verschiedenen Rechenzentren befinden, und einem gemeinsamen Server Zeuge c Quorum-Gerät (gehostet auf einer günstigen virtuellen Maschine in einem dritten Rechenzentrum), das Unsicherheiten beseitigt 50% / 50%indem man seine Stimme abgibt. Der dritte Cluster besteht aus drei Rechenzentren: ein Master, zwei Slaves, nein Quorum-Gerät. Der vierte Cluster besteht aus vier PostgreSQL-Servern, zwei pro Rechenzentrum: ein Master, der Rest sind Replikate und werden ebenfalls verwendet Zeuge c Quorum-Gerät. Der vierte übersteht den Ausfall von zwei Servern oder einem Rechenzentrum. Diese Lösung kann bei Bedarf auf weitere Replikate skaliert werden.

Zeitdienst ntpd wurde ebenfalls für Fehlertoleranz neu konfiguriert, verwendet jedoch die Methode von ntpd (Waisenmodus). Gemeinsamer Server Zeuge fungiert als zentraler NTP-Server, verteilt seine Zeit auf alle Cluster und synchronisiert so alle Server untereinander. Wenn Zeuge ausfällt oder sich als isoliert herausstellt, beginnt einer der Cluster-Server (innerhalb des Clusters) mit der Zeitverteilung. Zusätzliches Caching HTTP-Proxy auch angehoben ZeugeMit seiner Hilfe haben andere virtuelle Maschinen Zugriff auf Yum-Repositorys. In der Realität werden Dienste wie genaue Uhrzeit und Proxy höchstwahrscheinlich auf dedizierten Servern und in der Kabine, auf der sie gehostet werden, gehostet Zeuge nur um die Anzahl der virtuellen Maschinen und Platz zu sparen.

Versionen

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

Clusterstruktur

Alle Cluster sind so konzipiert, dass sie sich in mehreren Rechenzentren befinden, in einem flachen Netzwerk vereint sind und dem Ausfall oder der Netzwerkisolation eines Rechenzentrums standhalten müssen. Deshalb unmöglich zum Schutz vor verwenden geteiltes Gehirn Standard-Herzschrittmachertechnologie genannt STONITH (Schießen Sie den anderen Knoten in den Kopf) oder Fechten. Das Wesentliche: Wenn die Knoten im Cluster den Verdacht haben, dass mit einem Knoten etwas nicht stimmt, er nicht reagiert oder sich falsch verhält, schalten sie ihn über „externe“ Geräte, beispielsweise eine IPMI- oder USV-Steuerkarte, zwangsweise aus. Dies funktioniert jedoch nur in den Fällen, in denen sie bei einem einzigen Ausfall des IPMI-Servers oder der USV weiterhin funktionieren. Es ist auch ein Schutz vor einem viel katastrophaleren Ausfall vorgesehen, wenn das gesamte Rechenzentrum ausfällt (z. B. stromlos wird). Und mit einer solchen Weigerung alles stonith-Geräte (IPMI, USV usw.) funktionieren ebenfalls nicht.

Stattdessen basiert das System auf der Idee eines Quorums. Alle Knoten haben eine Stimme und nur diejenigen, die mehr als die Hälfte aller Knoten sehen, können arbeiten. Diese Zahl wird „halb + 1“ genannt Kollegium. Wird das Quorum nicht erreicht, entscheidet der Knoten, dass er sich in Netzwerkisolation befindet und muss seine Ressourcen abschalten, d. h. es ist wie es ist Split-Brain-Schutz. Wenn die Software, die für dieses Verhalten verantwortlich ist, nicht funktioniert, sollte ein Watchdog, beispielsweise auf IPMI-Basis, funktionieren.

Ist die Anzahl der Knoten gerade (ein Cluster in zwei Rechenzentren), kann es zur sogenannten Unsicherheit kommen 50% / 50% (Fünfzig-Fünfzig), wenn die Netzwerkisolation den Cluster genau in zwei Hälften teilt. Daher wird es für eine gerade Anzahl von Knoten hinzugefügt Quorum-Gerät - ein anspruchsloser Daemon, der auf der günstigsten virtuellen Maschine im dritten Rechenzentrum ausgeführt werden kann. Er gibt einem der Segmente (die er sieht) seine Stimme und löst dadurch die 50 %/50 %-Unsicherheit auf. Den Server, auf dem das Quorum-Gerät laufen soll, habe ich aufgerufen Zeuge (Terminologie von repmgr, es hat mir gefallen).

Ressourcen können von Ort zu Ort verschoben werden, beispielsweise von fehlerhaften Servern auf wartungsfähige, oder auf Befehl von Systemadministratoren. Damit Kunden wissen, wo sich die benötigten Ressourcen befinden (wo sie eine Verbindung herstellen können?), Floating-IP (Float-IP). Dies sind die IPs, die Pacemaker zwischen den Knoten verschieben kann (alles befindet sich in einem flachen Netzwerk). Jeder von ihnen symbolisiert eine Ressource (Dienst) und befindet sich dort, wo Sie eine Verbindung herstellen müssen, um Zugriff auf diesen Dienst zu erhalten (in unserem Fall die Datenbank).

Tuchanka1 (komprimiertes Schema)

Struktur

Die Idee war, dass wir über viele kleine Datenbanken mit geringer Auslastung verfügen, für die es unrentabel ist, einen dedizierten Slave-Server im Hot-Standby-Modus für schreibgeschützte Transaktionen zu unterhalten (eine solche Ressourcenverschwendung ist nicht erforderlich).

Jedes Rechenzentrum verfügt über einen Server. Jeder Server verfügt über zwei PostgreSQL-Instanzen (in der PostgreSQL-Terminologie werden sie Cluster genannt, aber um Verwirrung zu vermeiden, werde ich sie Instanzen nennen (analog zu anderen Datenbanken) und Pacemaker-Cluster nur als Cluster bezeichnen). Eine Instanz arbeitet im Master-Modus und stellt nur Dienste bereit (nur Float-IP führt zu ihr). Die zweite Instanz fungiert als Slave für das zweite Rechenzentrum und stellt nur Dienste bereit, wenn ihr Master ausfällt. Da meistens nur eine der beiden Instanzen (der Master) Dienste bereitstellt (Anforderungen ausführt), werden alle Serverressourcen für den Master optimiert (Speicher wird für den Shared_Buffers-Cache usw. zugewiesen), jedoch für die zweite Instanz verfügt auch über genügend Ressourcen (wenn auch für nicht optimale Arbeit über den Dateisystem-Cache), falls eines der Rechenzentren ausfällt. Während des normalen Clusterbetriebs stellt der Slave keine Dienste bereit (führt keine Nur-Lese-Anfragen aus), so dass kein Krieg um Ressourcen mit dem Master auf derselben Maschine entsteht.

Bei zwei Knoten ist Fehlertoleranz nur bei asynchroner Replikation möglich, da bei synchroner Replikation der Ausfall des Slaves zum Stopp des Masters führt.

Versäumnis, Zeuge zu sein

Nichtbezeugen (Quorum-Gerät) Ich werde nur für den Tuchanka1-Cluster in Betracht ziehen, die gleiche Geschichte wird für alle anderen gelten. Wenn der Zeuge ausfällt, ändert sich nichts an der Clusterstruktur, alles funktioniert weiterhin so, wie es funktioniert hat. Das Quorum wird jedoch 2 von 3 betragen, und daher wird jeder nächste Fehler für den Cluster fatal sein. Es muss noch dringend getan werden.

Ablehnung Tuchanka1

Ausfall eines der Rechenzentren für Tuchanka1. In diesem Fall Zeuge gibt seine Stimme an den zweiten Knoten im zweiten Rechenzentrum ab. Dort wird der ehemalige Slave zum Master, was zur Folge hat, dass beide Master auf demselben Server arbeiten und ihre beiden Float-IPs auf sie verweisen.

Tuchanka2 (klassisch)

Struktur

Das klassische Schema aus zwei Knoten. Der Master arbeitet an einem, der Slave an dem zweiten. Beide können Anfragen ausführen (der Slave ist nur schreibgeschützt), sodass auf beide per Float-IP verwiesen wird: Krogan2 ist der Master, Krogan2s1 ist der Slave. Sowohl der Master als auch der Slave verfügen über Fehlertoleranz.

Bei zwei Knoten ist Fehlertoleranz nur bei asynchroner Replikation möglich, da bei synchroner Replikation der Ausfall des Slaves zum Stopp des Masters führt.

Ablehnung Tuchanka2

Wenn eines der Rechenzentren ausfällt Zeuge stimme für den zweiten. Im einzigen funktionierenden Rechenzentrum wird der Master angehoben und beide Float-IPs verweisen darauf: Master und Slave. Natürlich muss die Instanz so konfiguriert sein, dass sie über genügend Ressourcen (Verbindungslimits etc.) verfügt, um alle Verbindungen und Anfragen von der Master- und Slave-Float-IP gleichzeitig anzunehmen. Das heißt, im Normalbetrieb sollte ein ausreichender Spielraum für Grenzwerte vorhanden sein.

Tuchanka4 (viele Sklaven)

Struktur

Schon wieder ein Extrem. Es gibt Datenbanken, die viele schreibgeschützte Anfragen haben (ein typischer Fall einer stark ausgelasteten Site). Tuchanka4 ist eine Situation, in der es möglicherweise drei oder mehr Sklaven gibt, die solche Anfragen bearbeiten, aber immer noch nicht zu viele. Bei einer sehr großen Anzahl von Slaves wird es notwendig sein, ein hierarchisches Replikationssystem zu erfinden. Im Minimalfall (im Bild) verfügt jedes der beiden Rechenzentren über zwei Server, die jeweils über eine PostgreSQL-Instanz verfügen.

Ein weiteres Merkmal dieses Schemas besteht darin, dass es hier bereits möglich ist, eine synchrone Replikation zu organisieren. Es ist so konfiguriert, dass es, wenn möglich, in ein anderes Rechenzentrum repliziert und nicht auf ein Replikat im selben Rechenzentrum wie der Master. Der Master und jeder Slave werden durch eine Float-IP angezeigt. Im Endeffekt wird es zwischen den Slaves notwendig sein, eine Art Ausgleich der Anfragen vorzunehmen SQL-Proxy, zum Beispiel auf der Clientseite. Unterschiedliche Arten von Clients erfordern möglicherweise unterschiedliche Arten von SQL-Proxy, und nur die Client-Entwickler wissen, wer welches benötigt. Diese Funktionalität kann entweder durch einen externen Daemon oder durch eine Client-Bibliothek (Verbindungspool) usw. implementiert werden. All dies liegt außerhalb des Rahmens des Datenbank-Failover-Clusters (Failover). SQL-Proxy kann unabhängig implementiert werden, zusammen mit Client-Failover).

Ablehnung Tuchanka4

Fällt ein Rechenzentrum (also zwei Server) aus, stimmt der Zeuge für das zweite. Infolgedessen arbeiten im zweiten Rechenzentrum zwei Server: Der Master arbeitet auf einem und die Master-Float-IP verweist auf ihn (um Lese-/Schreibanforderungen zu empfangen); und auf dem zweiten Server läuft ein Slave mit synchroner Replikation, und eine der Slave-Float-IPs zeigt darauf (für schreibgeschützte Anfragen).

Als Erstes ist zu beachten: Es funktionieren nicht alle Slave-Float-IPs, sondern nur eine. Und um damit richtig arbeiten zu können, ist das notwendig SQL-Proxy alle Anfragen an die einzige verbleibende Float-IP umgeleitet; und wenn SQL-Proxy Nein, Sie können alle Float-IP-Slaves durch Kommas getrennt in der Verbindungs-URL auflisten. In diesem Fall mit libpq Die Verbindung erfolgt wie im automatischen Testsystem zur ersten funktionierenden IP. Möglicherweise funktioniert dies in anderen Bibliotheken, zum Beispiel JDBC, nicht und ist notwendig SQL-Proxy. Dies geschieht, weil es verboten ist, dass Float-IP für Slaves gleichzeitig auf einem Server ansteigt, sodass sie gleichmäßig auf die Slave-Server verteilt werden, wenn es mehrere davon gibt.

Zweitens: Auch bei einem Ausfall des Rechenzentrums bleibt die synchrone Replikation erhalten. Und selbst wenn ein sekundärer Fehler auftritt, d. h. einer der beiden Server im verbleibenden Rechenzentrum ausfällt, behält der Cluster, obwohl er keine Dienste mehr bereitstellt, weiterhin Informationen über alle festgeschriebenen Transaktionen, für die er die Festschreibung bestätigt hat (dies wird der Fall sein). Es liegen keine Verlustinformationen bei Sekundärfehlern vor.

Tuchanka3 (3 Rechenzentren)

Struktur

Dies ist ein Cluster für eine Situation, in der drei voll funktionsfähige Rechenzentren vorhanden sind, von denen jedes über einen voll funktionsfähigen Datenbankserver verfügt. In diesem Fall Quorum-Gerät nicht benötigt. Ein Master arbeitet in einem Rechenzentrum und Slaves arbeiten in den anderen beiden. Die Replikation erfolgt synchron, Typ ANY (Slave1, Slave2), d. h. der Client erhält eine Commit-Bestätigung, wenn einer der Slaves als erster antwortet, dass er das Commit akzeptiert hat. Auf Ressourcen wird durch eine Float-IP für den Master und zwei für die Slaves verwiesen. Im Gegensatz zu Tuchanka4 sind alle drei Float-IPs fehlertolerant. Um schreibgeschützte SQL-Abfragen auszugleichen, können Sie verwenden SQL-Proxy (mit separater Fehlertoleranz) oder weisen Sie der Hälfte der Clients einen Slave-IP-Float und der anderen Hälfte den zweiten zu.

Ablehnung Tuchanka3

Fällt eines der Rechenzentren aus, bleiben zwei übrig. In einem Fall werden die Master- und Float-IP vom Master angehoben, im zweiten Fall der Slave und beide Slave-Float-IPs (die Instanz muss über einen doppelten Ressourcenspielraum verfügen, um alle Verbindungen von beiden Slave-Float-IPs zu akzeptieren). Synchrone Replikation zwischen Master und Slave. Außerdem speichert der Cluster Informationen über festgeschriebene und bestätigte Transaktionen (es kommt zu keinem Informationsverlust), falls zwei Rechenzentren zerstört werden (sofern diese nicht gleichzeitig zerstört werden).

Ich habe beschlossen, keine detaillierte Beschreibung der Dateistruktur und -bereitstellung beizufügen. Wenn Sie herumspielen möchten, können Sie dies alles in der README-Datei nachlesen. Ich gebe nur eine Beschreibung des automatischen Tests.

Automatisches Testsystem

Um die Fehlertoleranz von Clustern durch Nachahmung verschiedener Fehler zu überprüfen, wurde ein automatisches Testsystem entwickelt. Gestartet durch ein Skript test/failure. Das Skript kann als Parameter die Anzahl der Cluster übernehmen, die Sie testen möchten. Zum Beispiel dieser Befehl:

test/failure 2 3

testet nur den zweiten und dritten Cluster. Wenn keine Parameter angegeben werden, werden alle Cluster getestet. Alle Cluster werden parallel getestet und das Ergebnis wird im tmux-Panel angezeigt. Tmux verwendet einen dedizierten tmux-Server, sodass das Skript unter dem Standard-tmux ausgeführt werden kann, was zu einem verschachtelten tmux führt. Ich empfehle, das Terminal in einem großen Fenster und mit kleiner Schriftart zu verwenden. Bevor mit dem Testen begonnen wird, werden alle virtuellen Maschinen zum Zeitpunkt des Endes des Skripts auf einen Snapshot zurückgesetzt setup.

Das Terminal ist entsprechend der Anzahl der getesteten Cluster in Spalten unterteilt, standardmäßig sind es (im Screenshot) vier davon. Den Inhalt der Spalten beschreibe ich am Beispiel von Tuchanka2. Die Panels im Screenshot sind nummeriert:

1. Hier werden Teststatistiken angezeigt. Lautsprecher:
   • Fehler – der Name des Tests (Funktion im Skript), der den Fehler emuliert.
   • Reaktion – die arithmetische Mittelzeit in Sekunden, für die der Cluster seine Leistung wiederhergestellt hat. Sie wird vom Start des Skripts, das den Fehler emuliert, bis zu dem Zeitpunkt gemessen, an dem der Cluster seinen Zustand wiederherstellt und weiterhin Dienste bereitstellen kann. Wenn die Zeit sehr kurz ist, beispielsweise sechs Sekunden (dies geschieht in Clustern mit mehreren Slaves (Tuchanka3 und Tuchanka4)), bedeutet dies, dass die Störung auf einem asynchronen Slave gelandet ist und die Leistung in keiner Weise beeinträchtigt hat. Es gab keine Cluster-Statusschalter.
   • Abweichung - zeigt die Streuung (Genauigkeit) des Wertes an Reaktion nach der Standardabweichungsmethode.
   • zählen Wie oft wurde dieser Test durchgeführt?
2. Mithilfe eines kurzen Protokolls können Sie bewerten, was der Cluster gerade tut. Die Iterationsnummer (Testnummer), der Zeitstempel und der Operationsname werden angezeigt. Eine zu lange Ausführung (> 5 Minuten) weist auf ein Problem hin.
3. Herz (Herz) ist die aktuelle Zeit. Zur visuellen Leistungsbeurteilung Master Die aktuelle Uhrzeit wird mithilfe der Float-IP des Masters ständig in seine Tabelle geschrieben. Bei Erfolg wird das Ergebnis in diesem Panel angezeigt.
4. schlagen (Puls) – „aktuelle Zeit“, die zuvor vom Skript aufgezeichnet wurde Herz zu meistern, jetzt vorlesen Sklave über seine Float-IP. Ermöglicht die visuelle Beurteilung der Leistung eines Slaves und der Replikation. In Tuchanka1 gibt es keine Slaves mit Float-IP (es gibt keine Slaves, die Dienste anbieten), aber es gibt zwei Instanzen (DB), daher wird es hier nicht angezeigt schlagenUnd Herz zweite Instanz.
5. Überwachen Sie den Status des Clusters mithilfe des Dienstprogramms pcs mon. Zeigt die Struktur, die Verteilung der Ressourcen nach Knoten und andere nützliche Informationen.
6. Es zeigt die Systemüberwachung jeder virtuellen Clustermaschine an. Möglicherweise gibt es mehr solcher Panels – wie viele virtuelle Maschinen der Cluster hat. Zwei Grafiken CPU-Auslastung (zwei Prozessoren in virtuellen Maschinen), Name der virtuellen Maschine, System laden (genannt „Load Average“, da der Durchschnitt über 5, 10 und 15 Minuten ermittelt wurde), Prozessdaten und Speicherzuordnung.
7. Verfolgen des Skripts, das die Tests durchführt. Im Falle einer Störung – einer plötzlichen Arbeitsunterbrechung oder einer endlosen Warteschleife – sehen Sie hier den Grund für dieses Verhalten.

Die Prüfung erfolgt in zwei Stufen. Zunächst durchläuft das Skript alle Arten von Tests und wählt zufällig eine virtuelle Maschine aus, auf die dieser Test angewendet wird. Dann wird ein endloser Testzyklus durchgeführt, wobei jedes Mal virtuelle Maschinen und eine Fehlfunktion zufällig ausgewählt werden. Ein plötzlicher Abbruch des Testskripts (unteres Feld) oder eine endlose Warteschleife auf etwas (> 5 Minuten Zeit, um einen Vorgang abzuschließen, dies ist im Trace zu sehen) weist darauf hin, dass einige Tests auf diesem Cluster fehlgeschlagen sind.

Jeder Test besteht aus den folgenden Vorgängen:

1. Starten einer Funktion, die einen Fehler emuliert.
2. Ready? - Warten auf die Wiederherstellung des Zustands des Clusters (wenn alle Dienste erbracht sind).
3. Das Zeitlimit für die Cluster-Wiederherstellung wird angezeigt (Reaktion).
4. Fixieren - Der Cluster ist „repariert“. Danach sollte es wieder voll funktionsfähig und für die nächste Störung bereit sein.

Hier ist eine Liste der Tests mit einer Beschreibung ihrer Funktion:

• Gabelbombe: Erzeugt „Nicht genügend Speicher“ mit einer Fork-Bombe.
• OutOfSpace: Die Festplatte ist voll. Der Test ist jedoch eher symbolisch, da beim Testen eine unbedeutende Last entsteht und PostgreSQL bei einem Festplattenüberlauf normalerweise nicht fehlschlägt.
• Postgres-KILL: beendet PostgreSQL mit dem Befehl killall -KILL postgres.
• postgres-STOP: PostgreSQL hängt mit dem Befehl killall -STOP postgres.
• Ausschalten: Schaltet die virtuelle Maschine mit dem Befehl „stromlos“. VBoxManage controlvm "виртуалка" poweroff.
• Zurücksetzen: lädt die virtuelle Maschine mit dem Befehl neu VBoxManage controlvm "виртуалка" reset.
• SBD STOP: Hält den SBD-Daemon mit dem Befehl an killall -STOP sbd.
• Herunterfahren: sendet über SSH einen Befehl an die virtuelle Maschine systemctl poweroff, das System wird ordnungsgemäß heruntergefahren.
• uNLINK: Netzwerkisolation, Befehl VBoxManage controlvm "виртуалка" setlinkstate1 off.

Beenden Sie den Test entweder mit dem Standard-tmux-Befehl „kill-window“ Strg-B&, oder per Befehl „detach-client“ Strg-B d: Gleichzeitig ist der Test abgeschlossen, tmux wird geschlossen und virtuelle Maschinen werden ausgeschaltet.

Während des Tests festgestellte Probleme

• Im Augenblick Watchdog-Daemon SBD Behandelt das Stoppen beobachteter Daemons, aber nicht das Einfrieren. Infolgedessen werden Störungen falsch behoben, was nur zum Einfrieren führt Corosync и Pacemaker, aber nicht hängend jdm. Zum Überprüfen Corosync bereits PR # 83 (auf GitHub unter jdm), in die Filiale aufgenommen Master. Sie haben versprochen (in PR#83), dass es etwas Ähnliches für Pacemaker geben würde, ich hoffe, dass bis dahin Redhat xnumx wird tun. Solche „Fehlfunktionen“ sind jedoch spekulativ und können leicht künstlich nachgeahmt werden, beispielsweise durch killall -STOP corosyncaber nie im wirklichen Leben treffen.

• У Pacemaker in der Version für 7 CentOS falsch eingestellt sync_timeout у Quorum-Gerät, in den Ergebnissen Wenn ein Knoten ausfiel, wurde mit einiger Wahrscheinlichkeit der zweite Knoten neu gestartet, zu dem der Meister umziehen sollte. Durch Vergrößerung gehärtet sync_timeout у Quorum-Gerät während der Bereitstellung (im Skript). setup/setup1). Diese Änderung wurde von den Entwicklern nicht akzeptiert PacemakerStattdessen versprachen sie, die Infrastruktur (auf unbestimmte Zeit) so zu überarbeiten, dass dieser Timeout automatisch berechnet wird.

• Wenn Sie dies während der Datenbankkonfiguration angegeben haben LC_MESSAGES (Textnachrichten) Unicode kann beispielsweise verwendet werden, ru_RU.UTF-8, dann beim Start Postgres in einer Umgebung, in der das Gebietsschema nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier). Schrittmacher+pgsqlms(paf) beginnt Postgres), Das Im Protokoll werden anstelle von UTF-8-Buchstaben Fragezeichen angezeigt. Die PostgreSQL-Entwickler waren sich nie einig, was in diesem Fall zu tun ist. Es kostet, Sie müssen setzen LC_MESSAGES=en_US.UTF-8 beim Konfigurieren (Erstellen) einer DB-Instanz.

• Wenn wal_receiver_timeout festgelegt ist (standardmäßig sind es 60 Sekunden), dann beim Testen von PostgreSQL-STOP auf dem Master in den Clustern tuchanka3 und tuchanka4 Bei der Replikation wird keine erneute Verbindung zu einem neuen Master hergestellt. Die Replikation erfolgt dort synchron, d. h. nicht nur der Slave stoppt, sondern auch der neue Master. Wird durch Festlegen von wal_receiver_timeout=0 bei der Konfiguration von PostgreSQL abgerufen.

• Ich habe gelegentlich beobachtet, dass die PostgreSQL-Replikation im ForkBomb-Test hängen blieb (Speicherüberlauf). Nach ForkBomb kommt es manchmal vor, dass Slaves sich nicht wieder mit dem neuen Master verbinden. Ich habe dies nur in Tuchanka3- und Tuchanka4-Clustern gesehen, wo der Master aufgrund der Tatsache, dass die Replikation synchron ist, hängen blieb. Das Problem verschwand nach einiger Zeit (ca. zwei Stunden) von selbst. Um dieses Problem zu beheben, sind weitere Untersuchungen erforderlich. Die Symptome ähneln denen des vorherigen Fehlers, der eine andere Ursache hat, aber die gleichen Folgen hat.

Krogan-Foto aufgenommen von Deviant Art mit Genehmigung des Autors:

Source: habr.com