In diesem Blog zeigen wir dir, wie du eine JFrog Artifactory PostgreSQL Datenbank, die vom Crunchy Operator verwaltet wird, zum CloudNativePG Operator online migrieren kannst, ohne dass es zu einem Ausfall kommt (der einzige Ausfall könnte durch die Neukonfiguration deiner Anwendung entstehen, um auf die neue Datenbank zu verweisen). Für die PostgreSQL Logische Replikation haben wir uns auf einen Blogbeitrag von Percona bezogen.

Motivation

Warum haben wir die Artifactory PostgreSQL Datenbank vom Crunchy Operator zum CloudNativePG Operator migriert?
Sowohl der Crunchy Operator als auch der CloudNativePG Operator sind sehr ähnlich, aber es gibt einen Unterschied, der uns zu dieser Migration motiviert hat - die Kosten. Während die Nutzung des CloudNativePG Operators kostenlos ist, erfordert der Crunchy Operator eine Subscription.

Es gibt Ausnahmen, bei denen der Crunchy Operator ohne Subscription genutzt werden kann. Weitere Details finden Sie unter Crunchy Data Terms Of Use.

Unsere Umgebung

Der Einfachheit halber verwenden wir ein 2 Pod Setup für die aktuelle Artifactory Datenbank, die vom Crunchy Operator verwaltet wird, und 1 Pod für die Ziel Artifactory Datenbank, die vom CloudNativePG verwaltet wird. Sobald die Migration abgeschlossen ist, kannst du die Ziel Artifactory Datenbank auf so viele Pods skalieren, wie du benötigst.

Migration

Um die DB Migration durchzuführen, muss ein leerer CloudNativePG DB Cluster für JFrog Artifactory erstellt werden. Wenn du Hilfe beim Einrichten eines CloudNativePG PostgreSQL Clusters benötigst, schaue bitte in die offizielle CloudNativePG Dokumentation oder kontaktiere uns.

Schritt 1: Erstelle einen Migrationsbenutzer

Erstelle einen Migrationsbenutzer auf dem Primären und dem Ziel DB Pod:

CREATE USER dbmigration WITH SUPERUSER PASSWORD '***';

Der dbmigration Benutzer wird nur für Migrationszwecke verwendet. Nach der Migration sollte der Benutzer gelöscht werden.

Schritt 2: Erstelle eine Publication

Melde dich als dbmigration Benutzer bei der Artifactory DB auf dem Primären DB Pod an:

psql -U dbmigration -h source-db-lp6h-0 -d artifactory

Erstelle eine Publication für alle Tabellen in der Artifactory DB:

CREATE PUBLICATION artifactorypub FOR ALL TABLES;

Schritt 3: Erstelle einen logical replication slot

Im Primären DB Pod erstelle einen logical replication slot, um die Änderungen in der Datenbank zu erfassen:

SELECT pg_create_logical_replication_slot('artifactorypub_slot', 'pgoutput');

Überprüfe, ob der logical replication slot erstellt wurde:

SELECT * FROM pg_replication_slots;

Schritt 4: Pausiere die Replikation

Melde dich als postgres Benutzer bei der Sekundären DB an:

psql -U postgres -h source-db-9d4m-0

Pausiere die Replikation zwischen der Primären und der Sekundären DB:

SELECT pg_wal_replay_pause();

Mit angehaltener Replikation können wir sicherstellen, dass keine Updates in die sekundäre Datenbank geschrieben werden.
Überprüfe, ob die Replikation pausiert ist:

SELECT pg_is_wal_replay_paused();

Schritt 5: Notiere den replay_lsn für die Replikation

Notiere im Primären DB Pod den replay_lsn (Log Sequence Number). Später werden wir den replay_lsn auf der Ziel DB konfigurieren, ab welchem Log Sequence Number die Replikation fortgesetzt werden soll:

SELECT client_addr, application_name, replay_lsn FROM pg_stat_replication;

Die Ausgabe sollte ähnlich wie unten aussehen

client_addr |   application_name    |  replay_lsn
------------+-----------------------+---------------
10.128.8.21 |   source-db-9d4m-0    | 12CB/9500BFA8
(1 row)

Schritt 6: Dump und restore der Artifactory DBd

Erstellen Sie auf dem Ziel Pod target-db-1 einen Artifactory Datenbank Dump vom sekundären DB Pod:

pg_dump -d artifactory -U artifactory -h source-db-9d4m-0.source-pods.postgres-db.svc -Fc > artifactory_dmp.db

Stelle die Artifactory DB auf der Ziel DB wieder her:

pg_restore -h target-db-1 -U artifactory -d artifactory artifactory_dmp.db

Schritt 7: Setze die Replikation fort

Da wir den aktuellen Zustand der Sekundären DB auf die Ziel DB wiederhergestellt haben und die Log Sequence Number notiert haben, kann die Replikation zwischen der Primären und der Sekundären DB wieder aktiviert werden.

Melden dich als Benutzer postgres bei der sekundären Datenbank an:

psql -U postgres -h source-db-9d4m-0

Setze die Replikation fort:

SELECT pg_wal_replay_resume();

Überprüfe, ob die Replikation fortgesetzt wurde:

SELECT pg_is_wal_replay_paused();

Schritt 8: Erstelle eine subscription

Melde dich als dbmigration Benutzer bei der Artifactory DB auf dem Ziel DB Pod an:

psql -U dbmigration -h target-db-1 -d artifactory

Erstelle eine subscription, das auf die Primären DB verweist:

CREATE SUBSCRIPTION artifactorysub CONNECTION 'host=source-primary.postgres-db.svc port=5432 dbname=artifactory user=dbmigration password=***' PUBLICATION artifactorypub WITH (copy_data = false, create_slot=false, enabled=false, slot_name=artifactorypub_slot);

Mit einer subscription erhält die Ziel DB Updates von der publication, die wir zuvor auf der Primären DB erstellt haben. Überprüfe, ob die subscription erstellt wurde:

SELECT * FROM pg_stat_subscription;

Schritt 9: Aktiviere die Replikation

Um die Replikation auf der Ziel DB zu aktivieren, benötigen wir den identifier, die von pg_replication_origin zurückgegeben wird:

SELECT roident, subname, roname FROM pg_subscription sub, pg_replication_origin ro WHERE 'pg_' || sub.oid = ro.roname;

Die Ausgabe sollte ähnlich wie unten aussehen

roident |    subname     |  roname
--------+----------------+----------
      1 | artifactorysub | pg_16400
(1 row)

Aktualisiere nun den Replikationsursprung mit dem roname Wert, den du aus dem obigen Befehl erhalten hast, und mit dem replay_lsn, den du in Schritt 5 erhalten hast:

SELECT pg_replication_origin_advance('pg_16400', '12CB/9500BFA8');

Schritt 10: Aktiviere die subscription

Aktivieren Sie die subscription auf dem Ziel DB Pod. Sobald es aktiviert ist, wird die logische Replikation gestartet:

ALTER SUBSCRIPTION artifactorysub ENABLE;

Überprüfe, ob die subscription aktiviert ist:

SELECT * FROM pg_stat_subscription;

Du solltest nun Zeitstempel von gesendeten und empfangenen Nachrichten sehen

subid |    subname     | pid  | relid | received_lsn  |      last_msg_send_time       |     last_msg_receipt_time     | latest_end_lsn |        latest_end_time
------+----------------+------+-------+---------------+-------------------------------+-------------------------------+----------------+-------------------------------
18167 | artifactorysub | 3117 |       | 12CB/A5001958 | 2024-11-22 07:53:41.152916+00 | 2024-11-22 07:53:41.153084+00 | 12CB/A5001958  | 2024-11-22 07:53:41.152916+00
(1 row)

Schritt 11: Überprüfe, ob beide DBs synchron sind

Um die Datensynchronisierung zwischen der Primär- und der Ziel-Datenbank sicherzustellen, führen Sie diese Abfrage auf beiden DB-Pods aus:

SELECT count(*) FROM access_tokens;

Die Ergebnisse sollten übereinstimmen.

Schritt 12: Aufräumen

Sobald Ihre Anwendung auf die neue Ziel Datenbank zeigt, entfernen Sie die Migrationskonfiguration.

Deaktiviere die subscription:

ALTER SUBSCRIPTION artifactorysub DISABLE;

Entferne die subscription:

DROP SUBSCRIPTION artifactorysub;

Lösche den DB Migrationsbenutzer:

DROP USER dbmigration;

Fazit

Bevor du die DB Migration in der Produktionsumgebung durchführst, solltest du die obigen Schritte mehrmals in deiner Testumgebung wiederholen, um dich mit der Migration vertraut zu machen. Dazu kannst du deinen Ziel DB Cluster löschen und die logical replication slot wie auch die publication auf deiner Quell DB entfernen. Wenn du Fragen hast oder Unterstützung bei der Migration deiner PostgreSQL Datenbank benötigst, zögere nicht, uns zu kontaktieren.