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

Migration von PostgreSQL in die Cloud – Vergleich von Lösungen von Amazon, Google und Microsoft

Aus der Vogelperspektive scheint es, dass bei der Migration der PostgreSQL-Workloads in die Cloud die Wahl des Cloud-Anbieters keine Rolle spielen sollte. PostgreSQL macht es standardmäßig einfach, Daten ohne Ausfallzeiten über die logische Replikation zu replizieren, wenn auch mit einigen Einschränkungen. Um ihr Serviceangebot attraktiver zu machen, können Cloud-Anbieter einige dieser Einschränkungen ausarbeiten. Wenn wir beginnen, über Unterschiede in den verfügbaren PostgreSQL-Versionen, Kompatibilität, Grenzen, Beschränkungen und Leistung nachzudenken, wird deutlich, dass die Migrationsservices Schlüsselfaktoren im gesamten Serviceangebot sind. Es gilt nicht mehr „Wir bieten es an, wir migrieren es“. Es ist mehr geworden wie „Wir bieten es an, wir migrieren es mit den geringsten Einschränkungen“.

Migration ist für kleine und große Unternehmen gleichermaßen wichtig. Es geht nicht so sehr um die Größe des PostgreSQL-Clusters, sondern um die akzeptable Ausfallzeit und den Aufwand nach der Migration.

Auswahl einer Strategie

Die Migrationsstrategie sollte die Größe der Datenbank, die Netzwerkverbindung zwischen Quelle und Ziel sowie die vom Cloud-Anbieter angebotenen Migrationstools berücksichtigen.

Hardware oder Software?

So wie USB-Sticks und DVDs in den frühen Tagen des Internets verschickt wurden, bieten Cloud-Anbieter in Fällen, in denen die Netzwerkbandbreite nicht ausreicht, um Daten mit der gewünschten Geschwindigkeit zu übertragen, Hardwarelösungen an, die in der Lage sind um bis zu Hunderte von Petabyte an Daten zu transportieren. Unten sind die aktuellen Lösungen von jedem der großen Drei:

Eine praktische Tabelle von Google mit den verfügbaren Optionen:

GCP-Appliance ist Transfer-Appliance

Eine ähnliche Empfehlung von Azure basierend auf der Datengröße im Vergleich zur Netzwerkbandbreite:

Azure-Appliance ist Datenbox

Gegen Ende der Datenmigrationsseite bietet AWS einen Einblick in das, was wir erwarten können, zusammen mit einer Empfehlung für die Lösung:

In Fällen, in denen die Datenbankgröße 100 GB überschreitet und die Netzwerkbandbreite begrenzt ist, empfiehlt AWS a Hardwarelösung.

AWS-Appliance ist Snowball Edge

Datenexport/-import

Organisationen, die Ausfallzeiten tolerieren, können von der Einfachheit gemeinsamer Tools profitieren, die von PostgreSQL sofort einsatzbereit sind. Achten Sie jedoch beim Migrieren von Daten von einem Cloud- (oder Hosting-) Anbieter zu einem anderen Cloud-Anbieter auf die Kosten für ausgehenden Datenverkehr.

AWS

Zum Testen der Migrationen habe ich eine lokale Installation meiner Nextcloud-Datenbank verwendet, die auf einem meiner Heimnetzwerkserver ausgeführt wird:

postgres=# select pg_size_pretty(pg_database_size('nextcloud_prod'));

pg_size_pretty

----------------

58 MB

(1 row)



nextcloud_prod=# \dt

                     List of relations

Schema |             Name | Type  | Owner

--------+-------------------------------+-------+-----------

public | awsdms_ddl_audit              | table | s9sdemo

public | oc_accounts                   | table | nextcloud

public | oc_activity                   | table | nextcloud

public | oc_activity_mq                | table | nextcloud

public | oc_addressbookchanges         | table | nextcloud

public | oc_addressbooks               | table | nextcloud

public | oc_appconfig                  | table | nextcloud

public | oc_authtoken                  | table | nextcloud

public | oc_bruteforce_attempts        | table | nextcloud

public | oc_calendar_invitations       | table | nextcloud

public | oc_calendar_reminders         | table | nextcloud

public | oc_calendar_resources         | table | nextcloud

public | oc_calendar_resources_md      | table | nextcloud

public | oc_calendar_rooms             | table | nextcloud

public | oc_calendar_rooms_md          | table | nextcloud

...

public | oc_termsofservice_terms       | table | nextcloud

public | oc_text_documents             | table | nextcloud

public | oc_text_sessions              | table | nextcloud

public | oc_text_steps                 | table | nextcloud

public | oc_trusted_servers            | table | nextcloud

public | oc_twofactor_backupcodes      | table | nextcloud

public | oc_twofactor_providers        | table | nextcloud

public | oc_users                      | table | nextcloud

public | oc_vcategory                  | table | nextcloud

public | oc_vcategory_to_object        | table | nextcloud

public | oc_whats_new                  | table | nextcloud

(84 rows)

The database is running PostgreSQL version 11.5:

postgres=# select version();

                                                version

------------------------------------------------------------------------------------------------------------

PostgreSQL 11.5 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1), 64-bit

(1 row)

Ich habe auch einen PostgreSQL-Benutzer erstellt, der von AWS DMS verwendet werden soll, dem Amazon-Dienst zum Importieren von PostgreSQL in Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

-----------+------------+-------------

s9sdemo   |   | {nextcloud}

AWS DMS bietet viele Vorteile, so wie wir es von einer verwalteten Lösung in der Cloud erwarten würden: 

  • automatische Skalierung (nur Speicher, da Compute-Instanz die richtige Größe haben muss)
  •  automatische Bereitstellung
  •  Pay-as-you-go-Modell
  •  automatisches Failover

Allerdings ist es am besten, die Datenkonsistenz für eine Live-Datenbank aufrechtzuerhalten. Eine 100-prozentige Konsistenz wird nur erreicht, wenn sich die Datenbank im Nur-Lesen-Modus befindet – das ist eine Folge davon, wie Tabellenänderungen erfasst werden.

Mit anderen Worten, Tabellen haben einen anderen Point-in-Time-Cutover:

Wie bei allem in der Cloud fallen auch hier Kosten an Migrationsdienst.

Befolgen Sie zum Erstellen der Migrationsumgebung die Anleitung "Erste Schritte", um eine Replikationsinstanz, eine Quelle, einen Zielendpunkt und eine oder mehrere Aufgaben einzurichten.

Replikationsinstanz

Das Erstellen der Replikations-Instance ist für jeden, der mit EC2-Instances auf AWS vertraut ist, einfach:

Die einzige Änderung gegenüber den Standardeinstellungen war die Auswahl von AWS DMS 3.3.0 oder später, da meine lokale PostgreSQL-Engine 11.5 ist:

Und hier ist die Liste der derzeit verfügbaren AWS DMS-Versionen:

Große Installationen sollten auch die AWS DMS-Limits beachten:

Es gibt auch eine Reihe von Einschränkungen, die eine Folge der logischen Replikation von PostgreSQL sind Einschränkungen. Beispielsweise migriert AWS DMS keine sekundären Objekte:

Es ist erwähnenswert, dass in PostgreSQL alle Indizes sekundäre Indizes sind, und so weiter ist keine schlechte Sache, wie in dieser ausführlicheren Diskussion erwähnt.

Quellendpunkt

Folgen Sie dem Assistenten, um den Quellendpunkt zu erstellen:

Im Setup-Szenario Konfiguration für ein Netzwerk zu einer VPC über das Internet my Heimnetzwerk erforderte einige Anpassungen, um der IP-Adresse des Quellendpunkts den Zugriff auf meinen internen Server zu ermöglichen. Zuerst habe ich eine Portweiterleitung auf dem Edge-Router (173.180.222.170) erstellt, um Datenverkehr auf Port 30485 an mein internes Gateway (10.11.11.241) auf Port 5432 zu senden, wo ich den Zugriff basierend auf der Quell-IP-Adresse über iptables-Regeln feinabstimmen kann. Von dort fließt der Netzwerkverkehr durch einen SSH-Tunnel zum Webserver, auf dem die PostgreSQL-Datenbank ausgeführt wird. Mit der beschriebenen Konfiguration wird die client_addr in der Ausgabe von pg_stat_activity als 127.0.0.1 angezeigt.

Bevor eingehender Datenverkehr zugelassen wird, zeigen iptables-Protokolle 12 Versuche von der Replikationsinstanz bei ip=3.227.167.58):

Jan 19 17:35:28 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23973 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:29 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23974 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:31 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23975 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:35 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23976 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:48 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4328 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:49 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4329 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:51 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4330 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:55 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4331 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:08 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8298 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:09 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8299 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:11 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8300 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:16 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8301 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Sobald die IP-Adresse des Quellendpunkts (3.227.167.58) zugelassen wird, ist der Verbindungstest erfolgreich und die Konfiguration des Quellendpunkts ist abgeschlossen. Wir haben auch eine SSL-Verbindung, um den Datenverkehr durch öffentliche Netzwerke zu verschlüsseln. Dies kann auf dem PostgreSQL-Server mit der folgenden Abfrage sowie in der AWS-Konsole bestätigt werden:

postgres=# SELECT datname, usename, client_addr, ssl, cipher, query, query_start FROM pg_stat_activity a, pg_stat_ssl s where a.pid=s.pid and usename = 's9sdemo';

datname | usename | client_addr | ssl | cipher | query | query_start

---------+---------+-------------+-----+--------+-------+-------------

(0 rows)

…und beobachten Sie dann, während Sie die Verbindung von der AWS-Konsole ausführen. Die Ergebnisse sollten ungefähr so ​​aussehen:

postgres=# \watch



                                                                           Sun 19 Jan 2020 06:50:51 PM PST (every 2s)



    datname     | usename | client_addr | ssl |           cipher |                 query | query_start

----------------+---------+-------------+-----+-----------------------------+------------------------------------------------------------------------------------+-------------------------------

 nextcloud_prod | s9sdemo | 127.0.0.1   | t | ECDHE-RSA-AES256-GCM-SHA384 | select cast(setting as integer) from pg_settings where name = 'server_version_num' | 2020-01-19 18:50:51.463496-08

(1 row)

…während die AWS-Konsole einen Erfolg melden sollte:

Wie im Abschnitt „Voraussetzungen“ angegeben, wenn wir die Migrationsoption Vollständiges Laden auswählen , laufende Replikation, müssen wir die Berechtigungen für den PostgreSQL-Benutzer ändern. Diese Migrationsoption erfordert Superuser-Rechte, daher habe ich die Einstellungen für den zuvor erstellten PostgreSQL-Benutzer angepasst:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

-----------+------------+-----------

s9sdemo   | Superuser  | {}

Dasselbe Dokument enthält Anweisungen zum Ändern von postgresql.conf. Hier ist ein Unterschied zum Original:

--- a/var/lib/pgsql/data/postgresql.conf

+++ b/var/lib/pgsql/data/postgresql.conf

@@ -95,7 +95,7 @@ max_connections = 100                 # (change requires restart)



# - SSL -



-#ssl = off

+ssl = on

#ssl_ca_file = ''

#ssl_cert_file = 'server.crt'

#ssl_crl_file = ''

@@ -181,6 +181,7 @@ dynamic_shared_memory_type = posix  # the default is the first option



# - Settings -



+wal_level = logical

#wal_level = replica                   # minimal, replica, or logical

                                       # (change requires restart)

#fsync = on                            # flush data to disk for crash safety

@@ -239,6 +240,7 @@ min_wal_size = 80MB

#max_wal_senders = 10          # max number of walsender processes

                              # (change requires restart)

#wal_keep_segments = 0         # in logfile segments; 0 disables

+wal_sender_timeout = 0

#wal_sender_timeout = 60s      # in milliseconds; 0 disables



#max_replication_slots = 10    # max number of replication slots

@@ -451,6 +453,7 @@ log_rotation_size = 0                       # Automatic rotation of logfiles will

#log_duration = off

#log_error_verbosity = default         # terse, default, or verbose messages

Vergessen Sie zuletzt nicht, die pg_hba.conf-Einstellungen anzupassen, um eine SSL-Verbindung von der IP-Adresse der Replikationsinstanz zuzulassen.

Wir sind jetzt bereit für den nächsten Schritt.

Zielendpunkt

Folgen Sie dem Assistenten, um den Zielendpunkt zu erstellen:

Bei diesem Schritt wird davon ausgegangen, dass die RDS-Instanz mit dem angegebenen Endpunkt bereits vorhanden ist die leere Datenbank nextcloud_awsdms. Die Datenbank kann während der Einrichtung der RDS-Instanz erstellt werden.

Wenn das AWS-Netzwerk korrekt eingerichtet ist, sollten wir an dieser Stelle bereit sein, den Verbindungstest durchzuführen:

Wenn die Umgebung eingerichtet ist, ist es jetzt an der Zeit, die Migrationsaufgabe zu erstellen :

Migrationsaufgabe

Sobald der Assistent fertig ist, sieht die Konfiguration so aus:

...und der zweite Teil derselben Ansicht:

Sobald die Aufgabe gestartet wurde, können wir den Fortschritt überwachen – öffnen Sie die Aufgabe Details und scrollen Sie nach unten zu Tabellenstatistiken:

 AWS DMS verwendet das zwischengespeicherte Schema, um die Datenbanktabellen zu migrieren. Während die Migration fortschreitet, können wir zusätzlich zur AWS-Konsole weiterhin die Abfragen in der Quelldatenbank und das PostgreSQL-Fehlerprotokoll „beobachten“:

Bei Fehlern wird der Fehlerstatus in der Konsole angezeigt:

Ein Ort, an dem Sie nach Hinweisen suchen können, ist CloudWatch, obwohl während meiner Tests die Protokolle wurde nicht veröffentlicht, was wahrscheinlich nur ein weiterer Fehler in der Beta-Version von AWS DMS 3.3.0 sein könnte, wie sich gegen Ende dieser Übung herausstellte:

Der Migrationsfortschritt wird schön in der AWS DMS-Konsole angezeigt:

Sobald die Migration abgeschlossen ist, überprüfen Sie noch einmal das PostgreSQL-Fehlerprotokoll , enthüllt eine überraschende Nachricht:

Was zu passieren scheint, ist, dass in PostgreSQL 9.6, 10 die Tabelle pg_class enthält die benannte Spalte relhaspkey, aber das ist in 11 nicht der Fall. Und das ist der Fehler in der Beta-Version von AWS DMS 3.3.0, auf den ich mich zuvor bezogen habe.

GCP

Googles Ansatz basiert auf dem Open-Source-Tool PgBouncer. Die Aufregung war nur von kurzer Dauer, da die offizielle Dokumentation über die Migration von PostgreSQL in eine Compute-Engine-Umgebung spricht.

Weitere Versuche, eine Migrationslösung zu Cloud SQL zu finden, die AWS DMS ähnelt, schlugen fehl. Die Datenbankmigrationsstrategien enthalten keinen Verweis auf PostgreSQL:

Lokale PostgreSQL-Installationen können mithilfe der Dienste zu Cloud SQL migriert werden eines der Google Cloud-Partner.

Eine mögliche Lösung könnte PgBouncer für Cloud SQL sein, aber das ist nicht Gegenstand dieses Blogs.

Microsoft Cloud-Dienste (Azure)

Um die Migration von PostgreSQL-Workloads von lokal auf die verwaltete Azure-Datenbank für PostgreSQL zu erleichtern, stellt Microsoft Azure DMS bereit, das laut Dokumentation zur Migration mit minimaler Ausfallzeit verwendet werden kann. Im Tutorial Migrieren von PostgreSQL zu Azure Database for PostgreSQL online mit DMS werden diese Schritte ausführlich beschrieben.

In der Azure DMS-Dokumentation werden die Probleme und Einschränkungen im Zusammenhang mit der Migration der PostgreSQL-Arbeitslasten in Azure ausführlich erörtert.

Ein bemerkenswerter Unterschied zu AWS DMS ist die Anforderung, das Schema manuell zu erstellen:

Eine Demo davon wird das Thema eines zukünftigen Blogs sein. Bleiben Sie dran.