Übersicht
Der Database Migration Service unterstützt kontinuierliche Migrationen von Quelldatenbanken zu Cloud SQL-Zieldatenbanken.
Zu den unterstützten Quelldatenbanken für PostgreSQL gehören:
- Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17
- Amazon Aurora 10.11 und höher, 11.6 und höher, 12.4 und höher sowie 13.3 und höher, 14.6 und höher, 15.2 und höher, 16 und 17
- Selbstverwaltetes PostgreSQL (lokal oder auf einer beliebigen von Ihnen verwalteten Cloud-VM) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17
- Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17
- Microsoft Azure Database for PostgreSQL Flexible Server: 11 oder höher
Zum Konfigurieren Ihrer Quelle müssen Sie sowohl die Quellinstanz als auch die zugrunde liegenden Quelldatenbanken konfigurieren.
Quellinstanz konfigurieren
So konfigurieren Sie Ihre Quellinstanz:
- Cloud SQL-Quellen:Wenn Sie von einer Cloud SQL-Instanz mit einer privaten IP-Verbindung zu einer Cloud SQL-Instanz mit einem IP-Bereich außerhalb des RFC 1918-Bereichs migrieren, fügen Sie den Bereich außerhalb des RFC 1918-Bereichs der Netzwerkkonfiguration Ihrer Cloud SQL-Quell-Instanz hinzu. Weitere Informationen finden Sie in der Cloud SQL-Dokumentation unter Autorisierte Netzwerke konfigurieren.
- Die Quellinstanz muss die
postgres
-Datenbank enthalten. Wenn Sie diese Datenbank noch nicht haben, erstellen Sie sie. Installieren Sie das Paket
pglogical
auf der Quellinstanz und achten Sie darauf, dass es in der Variablenshared_preload_libraries
enthalten ist. Informationen für Ihre Umgebung finden Sie unterpglogical
-Paket auf der Quellinstanz installieren.Prüfen Sie die Erweiterungen in Ihrer Quellinstanz. Der Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Die Migration wird durch diese Erweiterungen nicht blockiert. Für einen reibungslosen Migrationsprozess sollten Sie jedoch prüfen, ob Ihre Objekte oder Anwendungen keine nicht unterstützten Erweiterungen enthalten. Wir empfehlen, diese Erweiterungen und Verweise aus Ihrer Quelldatenbank zu entfernen, bevor Sie fortfahren.
Quellen mit der Erweiterung
pg_cron
: Die Erweiterungpg_cron
(oder alle mit der Erweiterung verknüpftencron
-Einstellungen) wird vom Database Migration Service nicht migriert, sie wird aber in Cloud SQL for PostgreSQL-Zielen unterstützt. Wenn Sie diepg_cron
-Erweiterung in Ihren Quelldatenbanken verwenden, können Sie sie nach Abschluss der Migration in Ihrer Zielinstanz neu installieren.
Quelldatenbanken konfigurieren
Der Database Migration Service migriert alle Datenbanken unter Ihrer Quellinstanz außer den folgenden Datenbanken:
- Für lokale PostgreSQL-Quellen: Vorlagendatenbanken
template0
undtemplate1
- Für Amazon RDS-Quellen:
template0
,template1
undrdsadmin
- Für Cloud SQL-Quellen: Vorlagendatenbanken
template0
undtemplate1
- Für Microsoft Azure-Quellen:
azure_maintenance
,azure_sys
,template0
,template1
Führen Sie in jeder Datenbank der Quellinstanz, die oben nicht aufgeführt wird, Folgendes aus:
Nur für PostgreSQL-Version 9.4-Quellen: Installieren Sie die folgenden
pglogical
-Erweiterungen auf jeder Datenbank in Ihrer Quellinstanz:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
Bei allen anderen Versionen installieren Sie nur die Erweiterung
pglogical
in jeder Datenbank Ihrer Quellinstanz:CREATE EXTENSION IF NOT EXISTS pglogical
.Bei Tabellen ohne Primärschlüssel unterstützt Database Migration Service die Migration des ersten Snapshots und der
INSERT
-Anweisungen während der CDC-Phase. Sie solltenUPDATE
- undDELETE
-Anweisungen manuell migrieren.Der USER, mit dem Sie die Verbindung zur Quellinstanz herstellen (diese wird als Nutzer auf der Seite Verbindungsprofile konfiguriert), muss bestimmte Berechtigungen für jede migrierte Datenbank sowie für die Standarddatenbank
postgres
haben. Sie können einen neuen Nutzer erstellen oder einen vorhandenen verwenden. Stellen Sie eine Verbindung zur Instanz her und führen Sie die folgenden Befehle aus, um diese Berechtigungen festzulegen:GRANT USAGE on SCHEMA SCHEMA to USER
für alle Schemas (mit Ausnahme des Informationsschemas und der Schemas, die mit „pg_“ beginnen) in jeder zu migrierenden Datenbank.GRANT USAGE on SCHEMA pglogical to PUBLIC;
für jede Datenbank, die Sie migrieren möchten.GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER
für alle Datenbanken, um Replikationsinformationen aus Quelldatenbanken abzurufen.GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER
für alle Schemas (mit Ausnahme des Informationsschemas und der Schemas, die mit „pg_“ beginnen) in jeder zu migrierenden Datenbank.GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER
für alle Schemas (mit Ausnahme des Informationsschemas und der Schemas, die mit „pg_“ beginnen) in jeder zu migrierenden Datenbank.- Wenn die Quelle Amazon RDS ist, führen Sie den folgenden Befehl aus:
GRANT rds_replication to USER
- Wenn die Quelle nicht Amazon RDS ist, führen Sie den folgenden Befehl aus:
- Rolle
ALTER USER USER with REPLICATION
- Rolle
pglogical
-Paket auf der Quellinstanz installieren
In diesem Abschnitt wird beschrieben, wie Sie das pglogical
-Paket und die entsprechenden Parameter je nach Quellinstanz konfigurieren.
On-Premise- oder selbst verwaltete PostgreSQL
- Installieren Sie das pglogical-Paket auf dem Server.
- Stellen Sie eine Verbindung zur Instanz her und legen Sie nach Bedarf die folgenden Parameter fest:
shared_preload_libraries
musspglogical
enthalten.Führen Sie den Befehl
ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';
aus, um diesen Parameter festzulegen.- Setzen Sie
wal_level
auflogical
.Führen Sie den Befehl
ALTER SYSTEM SET wal_level = 'logical';
aus, um diesen Parameter festzulegen. Setzen Sie
wal_sender_timeout
auf0
.Um diesen Parameter festzulegen, führen Sie den Befehl
ALTER SYSTEM SET wal_sender_timeout = 0;
aus. Dabei wird mit0
der Zeitlimitmechanismus deaktiviert, der zum Beenden inaktiver Replikationsverbindungen verwendet wird.max_replication_slots definiert die maximale Anzahl von Replikations-Slots, die von der Quellinstanz unterstützt werden können. Er muss mindestens der Anzahl der Abos entsprechen, für die eine Verbindung erwartet wird, und einige Reservierungen für die Tabellensynchronisierung enthalten.
Der Database Migration Service erfordert einen Slot für jede migrierte Datenbank, also für alle Datenbanken unter der Quellinstanz.
Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und 2 Migrationsjobs für die Quelle erstellt werden, muss die Anzahl der Replikations-Slots zusätzlich zur Anzahl der Replikations-Slots, die Sie bereits verwenden, mindestens 5 * 2 = 10 sein. Wenn Sie die Einstellungen für die Parallelität von Datendumps anpassen möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.
Führen Sie den Befehl
ALTER SYSTEM SET max_replication_slots = #;
aus, um diesen Parameter festzulegen. Dabei steht # für die maximale Anzahl von Replikationsslots.Für max_wal_senders sollte ein Wert festgelegt werden, der mindestens „
max_replication_slots
“ plus die Anzahl der Absender beträgt, die bereits auf Ihrer Instanz verwendet werden.Wenn für den Parameter
Um diesen Parameter festzulegen, führen Sie den Befehlmax_replication_slots
beispielsweise der Wert10
festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12. Wenn Sie die Einstellungen für die Parallelität des Datendumps anpassen möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.ALTER SYSTEM SET max_wal_senders = #;
aus. Dabei steht # für die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse.- Für max_worker_processes sollte mindestens die Anzahl der Datenbanken festgelegt sein, die vom Database Migration Service migriert werden (d. h. alle Datenbanken unter der Quellinstanz) sowie die Anzahl der
max_worker_processes
, die bereits auf Ihrer Instanz verwendet werden.Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Workerprozesse erhöhen und Ihre Konfiguration überprüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.
Führen Sie den Befehl
ALTER SYSTEM SET max_worker_processes = #;
aus, um diesen Parameter festzulegen. Dabei steht # für die Anzahl der zu migrierenden Datenbanken.
- Starten Sie die Quellinstanz neu, um die Konfigurationsänderungen anzuwenden.
Microsoft Azure-Datenbank für PostgreSQL
So konfigurieren Sie die Microsoft Azure-Datenbank für PostgreSQL-Quelle:
- Installieren Sie das pglogical-Paket auf Ihrem Server.
Nur für PostgreSQL-Version 9.4-Quellen: Installieren Sie die folgenden
pglogical
-Erweiterungen auf jeder Datenbank in Ihrer Quellinstanz:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
Bei allen anderen Versionen installieren Sie die Erweiterung
pglogical
in jeder Datenbank Ihrer Quellinstanz:CREATE EXTENSION IF NOT EXISTS pglogical
.Konfigurieren Sie die erforderlichen Serverparameter in Ihrer Quelle über das Microsoft Azure-Portal. Weitere Informationen finden Sie in der Microsoft-Dokumentation unter Serverparameter in Azure Database for PostgreSQL konfigurieren und Serverparameter in Azure Database for PostgreSQL.
Konfigurieren Sie die folgenden Parameter:
- Legen Sie
shared_preload_libraries
so fest, dasspglogical
enthalten ist. - Legen Sie
azure.extensions
so fest, dasspglogical
enthalten ist. - Legen Sie
wal_level
auflogical
fest. Legen Sie
max_replication_slots
auf mindestens die Anzahl der Abos fest, für die eine Verbindung erwartet wird, und fügen Sie einige Reservierungen für die Tabellensynchronisierung hinzu.Der Parameter
max_replication_slots
definiert die maximale Anzahl an Replikations-Slots, die von der Quellinstanz unterstützt werden können.Der Database Migration Service erfordert einen Slot für jede migrierte Datenbank, also für alle Datenbanken unter der Quellinstanz.
Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und 2 Migrationsjobs für die Quelle erstellt werden, muss die Anzahl der Replikations-Slots zusätzlich zur Anzahl der Replikations-Slots, die Sie bereits verwenden, mindestens 5 * 2 = 10 sein. Wenn Sie die Einstellungen für die Parallelität von Datendumps anpassen möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.
Legen Sie
max_wal_senders
auf mindestensmax_replication_slots
plus die Anzahl der Absender fest, die bereits auf Ihrer Instanz verwendet werden.Wenn für den Parameter
max_replication_slots
beispielsweise der Wert10
festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12.Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.
Legen Sie
max_worker_processes
auf mindestens die Anzahl der Datenbanken fest, die vom Database Migration Service migriert werden sollen (d. h. alle Datenbanken unter der Quellinstanz), plus die Anzahl dermax_worker_processes
, die bereits auf Ihrer Instanz verwendet werden.Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Workerprozesse erhöhen und Ihre Konfiguration überprüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.
- Legen Sie
Prüfen Sie den Wert der Einstellung
require_secure_transport
.Für Microsoft Azure-Datenbanken ist standardmäßig die SSL/TLS-Verschlüsselung für alle eingehenden Verbindungen erforderlich. Verwenden Sie je nach
require_secure_transport
-Wert eine der folgenden Verschlüsselungseinstellungen, wenn Sie das Quellverbindungsprofil erstellen:- Wenn
require_secure_transport
aufon
festgelegt ist, wählen Sie Basic, TLS oder mTLS aus. - Wenn
require_secure_transport
aufoff
gesetzt ist, wählen Sie Keine aus.
- Wenn
- Starten Sie die Quellinstanz neu, um die Konfigurationsänderungen anzuwenden.
Amazon RDS PostgreSQL
Installieren Sie die Erweiterung
pglogical
in Ihrer Quelldatenbank.Weitere Informationen finden Sie in der Amazon RDS-Dokumentation unter PostgreSQL-Erweiterungen mit Amazon RDS for PostgreSQL verwenden.
Konfigurieren Sie die Quellinstanz mithilfe von Parametergruppen.
- Erstellen Sie eine neue Parametergruppe. In der Parametergruppe:
- Der Parameter
shared_preload_libraries
musspglogical
enthalten. - Legen Sie den Parameter
rds.logical_replication
auf „1“ fest. Dadurch werden WAL-Protokolle auf der Ebene „logical“ aktiviert. - Legen Sie den Parameter
wal_sender_timeout
auf 0 fest. Dadurch wird das Zeitlimit deaktiviert, das zum Beenden inaktiver Replikationsverbindungen verwendet wird. Legen Sie den Parameter max_replication_slots fest. Dieser Parameter definiert die maximale Anzahl von Replikations-Slots, die von der Quellinstanz unterstützt werden können. Sie muss mindestens der Anzahl der Abos entsprechen, für die eine Verbindung erwartet wird, und einige Reservierungen für die Tabellensynchronisierung enthalten.
Der Database Migration Service erfordert einen Slot für jede migrierte Datenbank, also für alle Datenbanken unter der Quellinstanz.
Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und 2 Migrationsjobs für die Quelle erstellt werden, muss die Anzahl der Replikations-Slots zusätzlich zur Anzahl der Replikations-Slots, die Sie bereits verwenden, mindestens 5 * 2 = 10 sein. Wenn Sie die Einstellungen für die Parallelität von Datendumps anpassen möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.
Der Standardwert für diesen Parameter ist 10.
Legen Sie für den Parameter max_wal_senders einen Wert fest, der mindestens
max_replication_slots
plus die Anzahl der Absender beträgt, die bereits auf Ihrer Instanz verwendet werden.Wenn für den Parameter
max_replication_slots
beispielsweise der Wert10
festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12. Wenn Sie angepasste Parallelitätseinstellungen für den Datendump verwenden möchten, erhöhen Sie die Anzahl der Absender und überprüfen Sie Ihre Konfiguration, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.Der Standardwert für diesen Parameter ist 10.
Legen Sie den Quellparameter max_worker_processes auf mindestens die Anzahl der Datenbanken fest, die vom Database Migration Service migriert werden sollen (d. h. alle Datenbanken unter der Quellinstanz) sowie die Anzahl der
max_worker_processes
, die bereits auf Ihrer Instanz verwendet werden. Wenn Sie die Einstellungen für die Parallelität des Datendumps anpassen möchten, müssen Sie die Anzahl der Workerprozesse erhöhen und die Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.Der Standardwert für diesen Parameter ist 8.
Fügen Sie der Instanz die Parametergruppe hinzu. Wenn Sie eine neue Instanz erstellen, finden Sie diese Option unter Zusätzliche Konfiguration.
Andernfalls ändern Sie die Instanz, um die Parametergruppe anzuhängen.
Starten Sie die Quellinstanz neu, um die Konfigurationsänderungen anzuwenden.
Cloud SQL for PostgreSQL
Aktivieren Sie die logische Replikation und Decodierung für die Quelldatenbank, indem Sie die folgenden Flags konfigurieren:
- Legen Sie die Flags
cloudsql.logical_decoding
undcloudsql.enable_pglogical
aufon
fest. Legen Sie das Flag max_replication_slots fest. Mit diesem Flag wird die maximale Anzahl von Replikations-Slots definiert, die von der Quellinstanz unterstützt werden können. Er muss mindestens der Anzahl der Abos entsprechen, für die eine Verbindung erwartet wird, und einige Reservierungen für die Tabellensynchronisierung enthalten.
Der Database Migration Service erfordert einen Slot für jede migrierte Datenbank, also für alle Datenbanken unter der Quellinstanz.
Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und 2 Migrationsjobs für die Quelle erstellt werden, muss die Anzahl der Replikations-Slots zusätzlich zur Anzahl der Replikations-Slots, die Sie bereits verwenden, mindestens 5 * 2 = 10 sein. Wenn Sie die Einstellungen für die Parallelität von Datendumps anpassen möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.
Der Standardwert für dieses Flag ist 10.
Legen Sie das Flag max_wal_senders auf mindestens
max_replication_slots
plus die Anzahl der Absender fest, die bereits auf Ihrer Instanz verwendet werden.Wenn für das Flag
max_replication_slots
beispielsweise der Wert10
festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12. Wenn Sie die Einstellungen für die Parallelität des Datendumps anpassen möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.Der Standardwert für dieses Flag ist 10.
Legen Sie das Quellflag max_worker_processes auf mindestens die Anzahl der Datenbanken fest, die vom Database Migration Service migriert werden sollen (d. h. alle Datenbanken unter der Quellinstanz) sowie die Anzahl der
max_worker_processes
, die bereits auf Ihrer Instanz verwendet werden. Wenn Sie die Einstellungen für die Parallelität des Datendumps anpassen möchten, erhöhen Sie die Anzahl der Workerprozesse und prüfen Sie die Konfiguration, indem Sie beim Erstellen des Migrationsjobs den Migrationsjob-Test ausführen.Der Standardwert für dieses Flag ist 8.
Legen Sie den Parameter
wal_sender_timeout
auf0
fest:ALTER SYSTEM SET wal_sender_timeout = 0;
Der Wert
0
deaktiviert das Zeitlimit, das zum Beenden inaktiver Replikationsverbindungen verwendet wird.- Starten Sie die Quellinstanz neu, damit die Konfigurationsänderungen, die Sie an den Flags vorgenommen haben, wirksam werden können.
Replikationsverzögerungsmonitoring für PostgreSQL-Versionen vor 9.6 aktivieren
Wenn Sie von einer PostgreSQL-Version vor 9.6 migrieren, ist der Messwert für die Replikationsverzögerung standardmäßig nicht verfügbar. Mit den folgenden Alternativen können Sie diesen Messwert verfolgen, um beim Hochstufen der Datenbank die Ausfallzeit zu minimieren:
Option 1: Aktivieren Sie den Database Migration Service, um die Replikationsverzögerung zu verfolgen, indem Sie Zugriff auf eine bestimmte Abfrage gewähren. Führen Sie einen Nutzer mit der Berechtigung
SUPERUSER
aus:Definieren Sie die folgende Funktion, damit der Database Migration Service die Replikationsverzögerung abfragen kann.
CREATE OR REPLACE FUNCTION pg_stat_replication_user() RETURNS TABLE ( pid integer , usesysid oid , username name , application_name text , client_addr inet , client_hostname text , client_port integer , backend_start timestamp with time zone , backend_xmin xid , state text , sent_location pg_lsn , write_location pg_lsn , flush_location pg_lsn , replay_location pg_lsn , sync_priority integer , sync_state text ) LANGUAGE SQL SECURITY DEFINER AS $$ SELECT * FROM pg_catalog.pg_stat_replication; $$;
Erteilen Sie der USER die Berechtigung
EXECUTE
, indem Sie die folgenden Befehle ausführen:REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};
Option 2: Erteilen Sie die Berechtigung
SUPERUSER
direkt dem USER, mit dem eine Verbindung zur Quellinstanz hergestellt wurde. So kann der Database Migration Service die Replikationsverzögerung direkt lesen.Option 3: Verfolgen Sie die Replikationsverzögerung unabhängig mit der folgenden Abfrage:
SELECT current_timestamp, application_name, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag FROM pg_stat_replication WHERE application_name like 'cloudsql%';
Bei dieser Option spiegelt der Database Migration Service den Messwert für die Replikationsverzögerung in den Grafiken oder API-Antworten nicht wider.