Vereinfachte Verwaltung einer PostgreSQL-Produktionsdatenbank

In den letzten Jahren wurde PostgreSQL zunehmend akzeptiert. PostgreSQL ist eine erstaunliche relationale Datenbank. In Bezug auf die Funktionen gehört es zu den Besten, wenn nicht sogar zu den Besten. Es gibt viele Dinge, die ich daran liebe – PL/PG SQL, intelligente Standardeinstellungen, Replikation (die tatsächlich sofort einsatzbereit ist) und eine aktive und lebendige Open-Source-Community. Über die Funktionen hinaus gibt es jedoch noch andere wichtige Aspekte einer Datenbank, die berücksichtigt werden müssen. Wenn Sie planen, einen großen 24/7-Betrieb aufzubauen, wird die Fähigkeit, die Datenbank einfach zu betreiben, sobald sie in Produktion ist, zu einem sehr wichtigen Faktor. In diesem Aspekt hält PostgreSQL nicht sehr gut mit. In diesem Blogbeitrag werden wir einige dieser betrieblichen Herausforderungen mit PostgreSQL detailliert beschreiben. Hier gibt es grundsätzlich nichts Unfixierbares, nur eine Frage der Priorisierung. Hoffentlich können wir genug Interesse in der Open-Source-Community wecken, um diese Funktionen zu priorisieren.

1. Keine automatische Client-Treiber-Erkennung von Master-Failover

Der PostgreSQL-Client-Treiber erkennt nicht automatisch, wenn ein Master-Failover stattgefunden hat (und ein neuer Master gewählt wurde). Um dies zu umgehen, müssen Administratoren serverseitig eine Proxy-Schicht bereitstellen. Die beliebtesten Optionen sind DNS-Mapping, virtuelles IP-Mapping, PgPool und HAProxy. Alle diese Optionen können gut funktionieren, es ist jedoch ein erheblicher zusätzlicher Lern- und Administratoraufwand erforderlich. Wenn ein Proxy in den Datenpfad eingefügt wird, wirkt sich dies ebenfalls erheblich auf die Leistung aus. Dies ist eine integrierte Standardfunktion in vielen der neuen NoSQL-Datenbanken, und PostgreSQL würde großartig daran tun, sich in ihren Büchern zu verbessern, wenn es um den Betrieb geht.

2. Kein integriertes automatisches Failover zwischen Master und Standby

Wenn ein PostgreSQL-Master ausfällt, muss einer der Standby-Server zum Master gewählt werden. Dieser Mechanismus ist nicht in PostgreSQL integriert. Typischerweise werden Softwaretools von Drittanbietern wie Patroni, Pacemaker usw. verwendet, um dieses Szenario zu handhaben. Warum haben Sie es nicht in den Server eingebaut? Diese Tools von Drittanbietern sehen täuschend einfach aus, erfordern jedoch erhebliche Anstrengungen, Kenntnisse und Tests seitens des Administrators, um dies richtig zu machen. Indem Sie dies in die Datenbank einbauen, tun Sie Ihrem Datenbankadministrator einen großen Gefallen.

3. Kein großes Upgrade ohne Ausfallzeiten

Es ist nicht möglich, Ihre PostgreSQL-Datenbank ohne Ausfallzeiten von einer Hauptversion auf eine andere zu aktualisieren. Sie müssen im Wesentlichen alle Ihre Server herunterfahren und pg_upgrade verwenden, um Ihre Daten auf die neuere Version zu aktualisieren. Die Ausfallzeit ist nicht groß, da keine Datenkopie beteiligt ist, es gibt jedoch immer noch Ausfallzeit. Wenn Sie rund um die Uhr arbeiten, ist dies möglicherweise keine Option für Sie.

Mit der Veröffentlichung der logischen Replikation haben wir eine alternative Option für Online-Upgrades.

1. Erstellen Sie mit der neuen Version ein brandneues PostgreSQL Master-Standby-Setup.
2. Logische Replikation einrichten, um von der älteren Version auf die neuere Version zu replizieren.
3. Sobald Sie fertig sind, ändern Sie Ihre Verbindungszeichenfolge so, dass sie vom alten Setup auf das neue Setup verweist.

Auch dies kann zum Laufen gebracht werden, aber der Overhead ist enorm. Im Idealfall ist hier eine Möglichkeit erforderlich, ein Upgrade vor Ort in rollierender Weise über ein Master-Standby-Setup durchzuführen. Mit dem MySQL-Upgrade können Sie Ihre Slaves vor Ort auf die neue Version aktualisieren und dann ein Failover auslösen.

4. Kein Vor-Ort-VAKUUM VOLL

Autovacuum/VACUUM ist sehr nützlich und hilft, dieses Problem bis zu einem gewissen Grad anzugehen. Sie sollten das Aufblähen Ihrer Tische regelmäßig untersuchen, um sicherzustellen, dass Ihre Autovacuum-Einstellungen angemessen sind und für Ihren Tisch gut funktionieren. Das Autovacuum reicht jedoch nicht bis zum Ende – es führt nicht dazu, dass die Seiten tatsächlich zusammengeführt und gelöscht werden. Wenn Sie eine große Anzahl von Aktualisierungen haben, Workloads einfügen und löschen, werden Ihre Seiten am Ende fragmentiert, was sich auf Ihre Leistung auswirkt. Der einzige Weg, dies zu umgehen, besteht darin, VACUUM FULL auszuführen, das im Grunde alle Seiten neu erstellt, um die Fragmentierung zu beseitigen. Dieser Vorgang kann jedoch nur mit Ausfallzeit durchgeführt werden – Ihr Tisch ist für die Dauer des VACUUM FULL ausgefallen. Bei großen Datensätzen kann dies mehrere Stunden dauern und ist keine praktische Alternative, wenn Sie einen 24/7-Betrieb ausführen möchten.

Hinweis:Die Community hat bereits mit der Arbeit an der zheap-Speicher-Engine begonnen, die diese Einschränkung überwindet.

Falls es weitere Verbesserungen gibt, die Sie für nützlich halten, können Sie gerne einen Kommentar hinterlassen.