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:
Schauen wir uns beide Szenarien an.
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 |
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 / Reloadpg_upgrade:
Daten auf Binärebene kopierenpg_upgrade –link
: In-Place-UpgradesWenn 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.
Um pg_upgrade
in Aktion zu zeigen, haben wir wie folgt eine kleine Beispieldatenbank erstellt:
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.
Zum Aktualisieren einer Datenbank sind zwei Schritte erforderlich:
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.
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.
Kontaktieren Sie uns gerne über das
Kontaktformular und vereinbaren ein unverbindliches
Beratungsgespräch mit unseren Berater:innen zur
Bedarfsevaluierung. Gemeinsam optimieren wir Ihre
Umgebung und steigern Ihre Performance!
Wir freuen uns auf Ihre Kontaktaufnahme!