Postgres aktualisieren und upgraden

Kürzlich wurde PostgreSQL 13 veröffentlicht und daher stellt sich die Frage, wie PostgreSQL 12 oder andere Versionen am Besten auf PostgreSQL 13 aktualisiert und geupgradet werden können. In diesem Blogbeitrag erklären wir Ihnen, wie Sie zur neusten Version wechseln können.

Bevor wir anfangen, müssen wir zwei Dinge unterscheiden:

PostgreSQL aktualisieren
PostgreSQL upgraden

Schauen wir uns beide Szenarien an.

1. PostgreSQL aktualisieren

Das erste Szenario, das wir uns anschauen, ist die Aktualisierung einer Hauptversion von PostgreSQL. Angenommen, Sie möchten von PostgreSQL 13.0 zu PostgreSQL 13.1 wechseln. In diesem Fall ist es lediglich notwendig die neuen Binärdateien zu installieren und die Datenbank neu zu starten.
Die Daten müssen nicht neu geladen werden, die erforderlichen Ausfallzeiten sind minimal und das Binärformat ändert sich nicht. Ein schneller Neustart ist alles, was Sie brauchen.
In der folgenden Tabelle können Sie eine kurze Übersicht hierzu sehen:

Tool	Aufgabe	Daten neu laden	Erforderliche Ausfallzeit
pg_dump	Kleinere Release Updates	Nicht benötigt	Nahe Null

2. PostgreSQL upgraden

Schauen wir uns nun die Upgrades an: Wenn Sie von PostgreSQL 9.5, 9.6, 10, 11 oder 12 auf PostgreSQL 13 umsteigen möchten, ist ein Upgrade erforderlich. Dazu haben Sie verschiedene Möglichkeiten:

pg_dump: Dump / Reload
pg_upgrade: Daten auf Binärebene kopieren
pg_upgrade –link: In-Place-Upgrades

Wenn Sie Daten sichern und neu laden, kann dies viel Zeit in Anspruch nehmen. Je größer Ihre Datenbank ist, desto mehr Zeit benötigen Sie für das Upgrade. Daraus folgt, dass pg_dump (all) und pg_restore nicht die richtigen Tools sind, um eine große Multi-Terabyte-Datenbank zu aktualisieren.
pg_upgrade benutzt man, um ein binäres Upgrade durchzuführen. Es kopiert alle Datendateien aus dem alten Verzeichnis in das neue. Abhängig von der Datenmenge kann dies viel Zeit in Anspruch nehmen und zu ernsthaften Ausfallzeiten führen. Wenn sich allerdings das neue und das alte Datenverzeichnis im selben Dateisystem befindet, gibt es eine bessere Option: pg_upgrade –link. Anstatt alle Dateien zu kopieren, erstellt pg_upgrade Hardlinks für diese Datendateien. Die Datenmenge ist kein begrenzender Faktor mehr, da Hardlinks schnell erstellt werden können. pg_upgrade –link verspricht daher Ausfallzeiten nahe Null.
Hier eine kleine Übersicht:

Tool	Aufgabe	Daten neu laden	Erforderliche Ausfallzeit
pg_upgrade	Haupt-Release-Update	Kopie ist erforderlich	Ausfallzeiten sind erforderlich
pg_upgrade -link	Haupt-Release-Update	Nur Hardlinks	Nahe Null

Hierbei ist zu beachten, dass pg_upgrade niemals destruktiv ist. Wenn etwas schief geht, können Sie das neue Datenverzeichnis jederzeit löschen und von vorne beginnen.

2.1 Vorbereiten einer Beispieldatenbank

Um pg_upgrade in Aktion zu zeigen, haben wir wie folgt eine kleine Beispieldatenbank erstellt:

Mainzer Datenfabrik - Postgres aktualisieren und upgraden

Dies ist eine relativ kleine Datenbank, die jedoch bereits groß genug ist, damit Benutzer den Unterschied beim Upgrade spüren können. Mit folgendem Befehl können Sie sich die Größe ausgeben lassen:

Wie Sie sehen hat unsere Datenbank eine Größe von 7,4 GB.

2.2 pg_upgrade

Zum Aktualisieren einer Datenbank sind zwei Schritte erforderlich:

initdb…
pg_upgrade…

Beginnen wir mit initdb:

root:tmp dr$ initdb -D /data/db13
 
The files belonging to this database system will be owned by user "dr".
 
This user must also own the server process.
 
The database cluster will be initialized with locales
       COLLATE: en_US
       CTYPE: UTF-8
       MESSAGES: en_US
       MONETARY: en_US
       NUMERIC: en_US
       TIME: en_US
The default database encoding has accordingly been set to "UTF8".
initdb: could not find suitable text search configuration for locale "UTF-8"
The default text search configuration will be set to "simple".
 
Data page checksums are disabled.
 
creating directory /data/db13 ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Vienna
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
 
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
 
Success. You can now start the database server using:
 
       pg_ctl -D /data/db13 -l logfile start

Beachten Sie, dass pg_upgrade nur funktioniert, wenn die Kodierungen der alten und der neuen Datenbankinstanz übereinstimmen. Andernfalls schlägt es fehl.

Als Nächstes können wir pg_upgrade ausführen. Hier benötigen wir grundsätzlich vier Informationen: Das alte und das neue Datenverzeichnis sowie den Pfad der alten und der neuen Binärdatei

root:tmp dr$ time pg_upgrade -d /data/db12/ \
       -D /data/db13 \
       -b /path/pg12/bin/ \
       -B /usr/local/Cellar/postgresql/13.0/bin/
 
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Creating dump of global objects                             ok
Creating dump of database schemas                           ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
 
If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.
 
Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows in the new cluster                        ok
Deleting files from new pg_xact                             ok
Copying old pg_xact to new server                           ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster               ok
Copying user relation files                                 ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok
 
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
        ./analyze_new_cluster.sh
 
Running this script will delete the old cluster's data files:
        ./delete_old_cluster.sh
 
<strong>real 4m11.702s</strong>
user 0m0.255s
sys 0m13.385s

Erwähnenswert ist hier, dass der Upgrade-Vorgang ein paar Minuten dauert, da alle Daten in das neue Verzeichnis kopiert werden müssen.

Um Ausfallzeiten zu reduzieren, können wir das Verzeichnis bereinigen, initdb erneut ausführen und die Option –link hinzufügen:

root:~ dr$ time pg_upgrade -d /data/db12/ \
       -D /data/db13 \
       -b /path/pg12/bin/ \
       -B /usr/local/Cellar/postgresql/13.0/bin/ \
       --link
 
Performing Consistency Checks
-----------------------------
Checking cluster versions                                    ok
Checking database user is the install user                   ok
 
…
 
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
        ./analyze_new_cluster.sh
 
Running this script will delete the old cluster's data files:
        ./delete_old_cluster.sh
 
<strong>real 0m3.538s</strong>
user 0m0.198s
sys 0m0.322s

In diesem Fall dauerte das Upgrade nur ein paar Sekunden. Wir können die Datenbankinstanz direkt starten und mit der neuen Instanz weiterarbeiten.

pg_upgrade –link

Die Option –link kann die Ausfallzeit auf nahe Null reduzieren. Schauen wir uns hierzu die Datendateien an:

-rw------- 2 dr wheel 1073741824 Dec 16 11:55 16388
-rw------- 2 dr wheel 1073741824 Dec 16 11:58 16388.1
-rw------- 2 dr wheel 66576384 Dec 16 12:01 16388.2
-rw------- 2 dr wheel 1073741824 Dec 16 12:12 16391
-rw------- 2 dr wheel 1073741824 Dec 16 12:13 16391.1
-rw------- 2 dr wheel 66576384 Dec 16 12:14 16391.2
-rw------- 2 dr wheel 1073741824 Dec 16 12:01 16394
-rw------- 2 dr wheel 49373184 Dec 16 12:01 16394.1
-rw------- 2 dr wheel 1073741824 Dec 16 12:03 16395
-rw------- 2 dr wheel 49373184 Dec 16 12:03 16395.1
-rw------- 2 dr wheel 1073741824 Dec 16 12:15 16396
-rw------- 2 dr wheel 49373184 Dec 16 12:15 16396.1
-rw------- 1 dr wheel 8192 Dec 17 10:03 174
-rw------- 1 dr wheel 8192 Dec 17 10:03 175

Hier können Sie sehen, dass die relevanten Datendateien zwei Einträge haben. ‘2‘ gibt an, dass derselbe Speicher als zwei Dateien angezeigt wird und pg_upgrade erstellt Hardlinks.

Beachten Sie, dass der Mountpoint /data und nicht /data/db12 ist, da andernfalls Hardlinks nicht möglich sind.

In unserem Beitrag haben Sie pg_upgrade kennengelernt und sollten nun mit einem wichtigen Upgrade-Tool umgehen und Postgres ohne Probleme aktualisieren und upgraden können.