PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Kompromisse bei Hot-Standby-Bereitstellungen

Die neue Hot-Standby-Funktion im kommenden PostgreSQL 9.0 ermöglicht das Ausführen von Abfragen für Standby-Knoten, die zuvor nur einen Wiederherstellungsprozess ausgeführt haben. Zwei häufige Erwartungen, die ich von Benutzern gehört habe, die diese Funktion erwarten, sind, dass sie entweder die Verteilung kurzer Abfragen auf beide Knoten oder die Ausführung langer Berichte für den Standby ermöglicht, ohne Ressourcen auf dem Master zu verwenden. Beides ist derzeit möglich, aber wenn Sie die Kompromisse bei der Funktionsweise von Hot Standby nicht verstehen, kann es hier zu unerwartetem Verhalten kommen.

Langfristige Standardabfragen

Eines der traditionellen Probleme in einer Datenbank, die MVCC verwendet, wie PostgreSQL, besteht darin, dass eine lang andauernde Abfrage eine Ressource – in der aktuellen Postgres-Implementierung als Snapshot bezeichnet – offen halten muss, um zu verhindern, dass die Datenbank Daten entfernt, die die Abfrage benötigt arbeiten. Nur weil ein anderer Client beispielsweise eine Zeile gelöscht und festgeschrieben hat, können Sie die physischen Festplattenblöcke, die sich auf diese Zeile beziehen, noch nicht löschen, wenn eine bereits laufende Abfrage diese Zeile zum Abschließen benötigt. Sie müssen warten, bis keine offenen Abfragen mehr vorhanden sind, die erwarten, dass diese Zeile sichtbar ist.

Hot-Standby-Einschränkungen

Wenn Sie eine lang andauernde Abfrage haben, die Hot Standby ausführen soll, gibt es einige Arten von Problemen, die passieren können, wenn der Wiederherstellungsprozess Updates anwendet. Diese sind in der Hot Standby Dokumentation ausführlich beschrieben. Einige dieser schlechten Dinge führen dazu, dass Abfragen, die im Standby-Modus ausgeführt werden, aus Gründen abgebrochen werden, die möglicherweise nicht intuitiv offensichtlich sind:

  • Ein HOT-Update oder ein VACUUM-bezogenes Update trifft ein, um etwas zu löschen, von dem die Abfrage erwartet, dass es sichtbar ist
  • Eine B-Tree-Löschung erscheint
  • Es gibt ein Sperrproblem zwischen der Abfrage, die Sie ausführen, und den Sperren, die für die Verarbeitung der Aktualisierung erforderlich sind.

Die Lock-Situation ist schwierig zu handhaben, wird aber in der Praxis wahrscheinlich nicht so lange auftreten, wenn Sie nur schreibgeschützte Abfragen auf dem Standby ausführen, da diese über MVCC isoliert werden. Die anderen beiden sind nicht schwer zu treffen. Die grundlegende Sache zu verstehen ist, dass alle UPDATE oder DELETE auf dem Master kann dazu führen, dass jede Abfrage auf dem Standby unterbrochen wird; spielt keine Rolle, ob sich die Änderungen überhaupt auf das beziehen, was die Abfrage tut.

Gut, schnell, günstig:Wählen Sie zwei aus

Im Wesentlichen gibt es drei Dinge, die die Leute priorisieren sollten:

  1. Vermeiden Sie Master-Limitierung:Erlauben Sie xids und zugehörigen Snapshots, sich unbegrenzt auf dem Master fortzubewegen, damit VACUUM und ähnliche Aufräumarbeiten nicht durch das, was der Standby tut, aufgehalten werden
  2. Unbegrenzte Abfragen:Führen Sie Abfragen im Standby-Modus für einen beliebigen Zeitraum aus
  3. Aktuelle Wiederherstellung:Halten Sie den Wiederherstellungsprozess auf dem Standby mit den Vorgängen auf dem Master auf dem Laufenden, was ein schnelles Failover für HA ermöglicht

In jeder Situation mit Hot Standby ist es buchstäblich unmöglich, alle drei gleichzeitig zu haben. Sie können nur Ihren Kompromiss auswählen. Mit den verfügbaren einstellbaren Parametern können Sie bereits einige Möglichkeiten optimieren:

  • Das Deaktivieren all dieser Verzögerungs-/Aufschubeinstellungen optimiert die immer aktuelle Wiederherstellung, aber dann werden Sie feststellen, dass Abfragen mit größerer Wahrscheinlichkeit abgebrochen werden, als Sie vielleicht erwarten.
  • max_standby_delay optimiert für längere Abfragen, auf Kosten der Wiederherstellung auf dem neuesten Stand. Dies verzögert das Anwenden von Updates auf den Standby, sobald ein Update auftritt, das ein Problem verursacht (HOT, VACUUM, B-tree delete, etc.).
  • vacuum_defer_cleanup_age und einige Snapshot-Hacks können einige Master-Limitings einführen, um die anderen beiden Probleme zu verbessern, aber mit einer schwachen Benutzeroberfläche, um dies zu tun. vacuum_defer_cleanup_age ist in Einheiten von Transaktions-IDs angegeben. Sie müssen eine ungefähre Vorstellung von der durchschnittlichen xid-Abwanderung auf Ihrem System pro Zeiteinheit haben, um die Art und Weise, wie die Leute über dieses Problem denken („mindestens 1 Stunde verschieben, damit meine Berichte ausgeführt werden“) in eine Einstellung für diesen Wert umzuwandeln. Die xid-Verbrauchsrate ist einfach nicht üblich oder auch nur vernünftig zu messen/vorherzusagen. Alternativ können Sie einen Snapshot auf dem Primärserver öffnen, bevor Sie eine lang andauernde Abfrage auf dem Standbyserver starten. dblink wird in der Hot Standby-Dokumentation als eine Möglichkeit vorgeschlagen, dies zu erreichen. Theoretisch könnte ein Daemon auf dem Standby im User-Land geschrieben werden, der auf dem Primary lebt, um auch dieses Problem zu umgehen (Simon hat ein grundlegendes Design für einen). Grundsätzlich starten Sie eine Reihe von Prozessen, die jeweils einen Snapshot erfassen und dann eine Zeit lang schlafen, bevor sie ihn freigeben. Indem Sie festlegen, wie lange sie jeweils geschlafen haben, können Sie sicherstellen, dass xid-Schnappschüsse auf dem Master nie zu schnell vorwärts gehen. Es sollte schon offensichtlich klingen, was für ein schrecklicher Hack das wäre.

Potenzielle Verbesserungen

Das Einzige, woran Sie wirklich sauber etwas ändern können, ist das Verschärfen und Verbessern der Benutzeroberfläche für das Master-Limiting. Das macht dies zu dem traditionellen Problem, das bereits in der Datenbank vorhanden ist:Eine lang andauernde Abfrage hält einen Snapshot auf dem Master offen (oder begrenzt zumindest den Fortschritt von sichtbarkeitsbezogenen Transaktions-IDs) und hindert den Master daran, Dinge zu entfernen, die für diese Abfrage benötigt werden Komplett. Alternativ können Sie sich das auch als automatisches Tuning von vacuum_defer_cleanup_age vorstellen.
Die Frage ist, wie man primary macht respektieren Sie die Anforderungen lang andauernder Abfragen im Standby . Dies könnte möglich sein, wenn mehr Informationen über die Anforderungen an die Transaktionssichtbarkeit des Standby mit dem Master geteilt würden. Diese Art von Austausch wäre für die gemeinsame Nutzung der neuen Streaming-Replikationsimplementierung wirklich angemessener. Die Art und Weise, wie ein einfacher Hot-Standby-Server bereitgestellt wird, gibt außer Ansätzen wie dem bereits erwähnten dblink-Hack keine Rückmeldung an den Master, der für den Austausch dieser Daten geeignet ist Es ist noch Zeit, einige Verbesserungen in diesem Bereich vor der Veröffentlichung von 9.0 zu sehen. Es wäre schön zu sehen, wie Hot Standby und Streaming-Replikation wirklich so integriert werden, dass Dinge erreicht werden, zu denen keine von beiden allein in der Lage ist, bevor die Codierung in dieser Version vollständig einfriert.