Descripción general
Database Migration Service admite migraciones continuas de bases de datos de origen a bases de datos de destino de Cloud SQL.
Entre las bases de datos de origen admitidas para PostgreSQL, se incluyen las siguientes:
- Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16 y 17
- Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16 y 17
- PostgreSQL autoadministrado (local o en cualquier VM en la nube que controlas por completo) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16 y 17
- Cloud SQL para PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16 y 17
- Microsoft Azure Database para PostgreSQL Flexible Server: 11 y versiones posteriores
Para configurar tu fuente, debes configurar la instancia de origen y las bases de datos de origen subyacentes.
Configura tu instancia de origen
Para configurar tu instancia de origen, sigue estos pasos:
- Para fuentes de Cloud SQL: Si migras desde una instancia de Cloud SQL que usa una conexión de IP privada a una instancia de Cloud SQL que usa un rango de IP de dirección que no es RFC 1918, agrega el rango que no es RFC 1918 a la configuración de red de tu instancia de Cloud SQL de origen. Consulta Configura redes autorizadas en la documentación de Cloud SQL.
- Tu instancia de origen debe incluir la base de datos
postgres
. Si no tienes esta base de datos, créala. Instala el paquete
pglogical
en la instancia de origen y asegúrate de que se incluya en la variableshared_preload_libraries
. Consulta Cómo instalar el paquetepglogical
en la instancia de origen para tu entorno.Verifica las extensiones en tu instancia de origen. Database Migration Service no migra las extensiones que no son compatibles con Cloud SQL. La presencia de estas extensiones no bloquea la migración, pero para garantizar un proceso de migración sin problemas, verifica que tus objetos o aplicaciones no hagan referencia a extensiones no admitidas. Te recomendamos que quites estas extensiones y referencias de la base de datos de origen antes de continuar.
En el caso de las fuentes que usan la extensión
pg_cron
: Database Migration Service no migra la extensiónpg_cron
(ni la configuración decron
asociada con ella), pero es compatible con los destinos de Cloud SQL para PostgreSQL. Si usas la extensiónpg_cron
en tus bases de datos de origen, puedes volver a instalarla en tu instancia de destino una vez que se complete la migración.
Configura tus bases de datos de origen
Database Migration Service migra todas las bases de datos de tu instancia de origen, excepto las siguientes:
- Para fuentes de PostgreSQL locales: bases de datos de plantillas
template0
ytemplate1
- Para fuentes de Amazon RDS:
template0
,template1
yrdsadmin
- Para fuentes de Cloud SQL: bases de datos de plantillas
template0
ytemplate1
- Para fuentes de Microsoft Azure:
azure_maintenance
,azure_sys
,template0
,template1
Haz lo siguiente en cada base de datos de tu instancia de origen que no se mencionó anteriormente:
Solo para fuentes de PostgreSQL versión 9.4, instala las siguientes extensiones
pglogical
en cada base de datos de tu instancia de origen:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
Para todas las demás versiones, instala solo la extensión
pglogical
en cada base de datos de tu instancia de origen:CREATE EXTENSION IF NOT EXISTS pglogical
.En el caso de las tablas que no tienen claves primarias, Database Migration Service admite la migración de la instantánea inicial y las sentencias
INSERT
durante la fase de CDC. Debes migrar las sentenciasUPDATE
yDELETE
de forma manual.El USER que uses para conectarte a la instancia de origen (que se configurará como el usuario en la página Perfiles de conexión) debe tener ciertos privilegios en cada una de las bases de datos migradas, así como en la base de datos predeterminada de
postgres
. Puedes crear un usuario nuevo o reutilizar uno existente. Para configurar estos privilegios, conéctate a la instancia y ejecuta los siguientes comandos:GRANT USAGE on SCHEMA SCHEMA to USER
en todos los esquemas (aparte del esquema de información y los esquemas que comienzan con “pg_”) de cada base de datos que vayas a migrar.GRANT USAGE on SCHEMA pglogical to PUBLIC;
en cada base de datos que se migrará.GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER
en todas las bases de datos para obtener información de replicación de las bases de datos de origen.GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER
en todos los esquemas (aparte del esquema de información y los esquemas que comienzan con “pg_”) de cada base de datos que vayas a migrar.GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER
en todos los esquemas (aparte del esquema de información y los esquemas que comienzan con “pg_”) de cada base de datos que vayas a migrar.- Si tu fuente es Amazon RDS, ejecuta el siguiente comando:
GRANT rds_replication to USER
- Si tu fuente no es Amazon RDS, ejecuta el siguiente comando:
- La función
ALTER USER USER with REPLICATION
- La función
Instala el paquete pglogical
en la instancia de origen
En esta sección, se describe cómo configurar el paquete pglogical
y los parámetros aplicables, según tu instancia de origen.
PostgreSQL autoadministrado o local
- Instala el paquete pglogical en el servidor.
- Conéctate a la instancia y establece los siguientes parámetros según sea necesario:
shared_preload_libraries
debe incluirpglogical
.Para establecer este parámetro, ejecuta el comando
ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';
.- Establece
wal_level
enlogical
.Para establecer este parámetro, ejecuta el comando
ALTER SYSTEM SET wal_level = 'logical';
. Establece
wal_sender_timeout
en0
.Para establecer este parámetro, ejecuta el comando
ALTER SYSTEM SET wal_sender_timeout = 0;
, en el que0
inhabilita el mecanismo de tiempo de espera que se usa para finalizar las conexiones de replicación inactivas.max_replication_slots define la cantidad máxima de ranuras de replicación que puede admitir la instancia de origen. Debe establecerse en al menos la cantidad de suscripciones que se espera conectar, más algunas reservas para la sincronización de tablas.
Database Migration Service requiere una ranura para cada base de datos que se migra (que son todas las bases de datos de la instancia de origen).
Por ejemplo, si hay 5 bases de datos en la instancia de origen y se crearon 2 trabajos de migración para la fuente, la cantidad de ranuras de replicación debe ser al menos de 5 * 2 = 10, más la cantidad de ranuras de replicación que ya usas. Si planeas usar la configuración ajustada de paralelismo de volcado de datos, asegúrate de aumentar la cantidad de ranuras de replicación y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.
Para establecer este parámetro, ejecuta el comando
ALTER SYSTEM SET max_replication_slots = #;
, en el que # representa la cantidad máxima de ranuras de replicación.max_wal_senders debe ser, al menos, igual que
max_replication_slots
, además de la cantidad de remitentes que ya se usaron en tu instancia.Por ejemplo, si el parámetro
Para establecer este parámetro, ejecuta el comandomax_replication_slots
se establece en10
y ya usas 2 remitentes, la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12. Si planeas usar la configuración de paralelismo de volcado de datos ajustado, asegúrate de aumentar la cantidad de remitentes y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.ALTER SYSTEM SET max_wal_senders = #;
, en el que # representa la cantidad de procesos de remitente WAL que se ejecutan de forma simultánea.- max_worker_processes debe establecerse en, al menos, la misma cantidad de bases de datos que Database Migration Service migrará (que son todas las bases de datos de la instancia de origen), además de la cantidad de
max_worker_processes
que ya se usó en tu instancia.Si planeas usar la configuración de paralelismo de volcado de datos ajustada, asegúrate de aumentar la cantidad de procesos de trabajo y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.
Para establecer este parámetro, ejecuta el comando
ALTER SYSTEM SET max_worker_processes = #;
, en el que # representa la cantidad de bases de datos que se migrarán.
- Para aplicar los cambios de configuración, reinicia la instancia de origen.
Microsoft Azure Database para PostgreSQL
Para configurar tu fuente de Microsoft Azure Database for PostgreSQL, sigue estos pasos:
- Instala el paquete pglogical en tu servidor.
Solo para fuentes de PostgreSQL versión 9.4, instala las siguientes extensiones
pglogical
en cada base de datos de tu instancia de origen:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
Para todas las demás versiones, instala la extensión
pglogical
en cada base de datos de tu instancia de origen:CREATE EXTENSION IF NOT EXISTS pglogical
.Configura los parámetros de servidor obligatorios en tu fuente con el portal de Microsoft Azure. Para obtener más información, consulta Configura parámetros del servidor en Azure Database for PostgreSQL y Parámetros del servidor en Azure Database for PostgreSQL en la documentación de Microsoft.
Configura los siguientes parámetros:
- Establece
shared_preload_libraries
para que incluyapglogical
. - Establece
azure.extensions
para que incluyapglogical
. - Establece
wal_level
comological
. Establece
max_replication_slots
en al menos la cantidad de suscripciones que se espera conectar, más algunas reservas para la sincronización de tablas.El parámetro
max_replication_slots
define la cantidad máxima de ranuras de replicación que puede admitir la instancia de origen.Database Migration Service requiere una ranura para cada base de datos que se migra (que son todas las bases de datos de la instancia de origen).
Por ejemplo, si hay 5 bases de datos en la instancia de origen y se crearon 2 trabajos de migración para la fuente, la cantidad de ranuras de replicación debe ser al menos de 5 * 2 = 10, más la cantidad de ranuras de replicación que ya usas. Si planeas usar la configuración ajustada de paralelismo de volcado de datos, asegúrate de aumentar la cantidad de ranuras de replicación y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.
Configura
max_wal_senders
en, al menos, lo mismo quemax_replication_slots
, además de la cantidad de remitentes que ya se usaron en tu instancia.Por ejemplo, si el parámetro
max_replication_slots
se establece en10
y ya usas 2 remitentes, la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12.Si planeas usar la configuración de paralelismo de volcado de datos ajustado, asegúrate de aumentar la cantidad de remitentes y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.
Configura
max_worker_processes
en, al menos, la misma cantidad de bases de datos que Database Migration Service migrará (que son todas las bases de datos de la instancia de origen), más la cantidad demax_worker_processes
que ya se usó en tu instancia.Si planeas usar la configuración de paralelismo de volcado de datos ajustada, asegúrate de aumentar la cantidad de procesos de trabajo y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.
- Establece
Verifica el valor de la configuración de
require_secure_transport
.De forma predeterminada, las bases de datos de Microsoft Azure requieren la encriptación SSL/TLS para todas las conexiones entrantes. Según el valor de
require_secure_transport
, usa una de las siguientes opciones de configuración de encriptación cuando crees el perfil de conexión de origen:- Si
require_secure_transport
está configurado enon
, selecciona Básico, TLS o mTLS. - Si
require_secure_transport
está configurado comooff
, selecciona None.
- Si
- Para aplicar los cambios de configuración, reinicia la instancia de origen.
PostgreSQL de Amazon RDS
Instala la extensión
pglogical
en tu base de datos de origen.Para obtener más información, consulta Cómo usar extensiones de PostgreSQL con Amazon RDS para PostgreSQL en la documentación de Amazon RDS.
Configura la instancia de origen con grupos de parámetros.
- Crea un grupo de parámetros nuevo. En el grupo de parámetros, haz lo siguiente:
- Asegúrate de que el parámetro
shared_preload_libraries
incluyapglogical
. - Establece el parámetro
rds.logical_replication
en 1. Esto habilitará los registros de WAL en el nivel "lógico". - Establece el parámetro
wal_sender_timeout
en 0. Esto inhabilitará el mecanismo de tiempo de espera que se usa para finalizar las conexiones de replicación inactivas. Establece el parámetro max_replication_slots. Este parámetro define la cantidad máxima de ranuras de replicación que puede admitir la instancia de origen. Debe establecerse en al menos la cantidad de suscripciones que se espera conectar, más algunas reservas para la sincronización de tablas.
Database Migration Service requiere una ranura para cada base de datos que se migra (que son todas las bases de datos de la instancia de origen).
Por ejemplo, si hay 5 bases de datos en la instancia de origen y se crearán 2 trabajos de migración para la fuente, la cantidad de ranuras de replicación debe ser al menos de 5 * 2 = 10, más la cantidad de ranuras de replicación que ya usas. Si planeas usar la configuración ajustada de paralelismo de volcado de datos, asegúrate de aumentar la cantidad de ranuras de replicación y verificar tu configuración. Para ello, ejecuta la prueba del trabajo de migración cuando lo crees.
El valor predeterminado para este parámetro es 10.
Configura el parámetro max_wal_senders en, al menos, lo mismo que
max_replication_slots
, además de la cantidad de remitentes que ya se usaron en tu instancia.Por ejemplo, si el parámetro
max_replication_slots
se establece en10
y ya usas 2 remitentes, la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12. Si planeas usar la configuración de paralelismo de volcado de datos ajustada, asegúrate de aumentar la cantidad de remitentes y verificar tu configuración. Para ello, ejecuta la prueba del trabajo de migración cuando lo crees.El valor predeterminado para este parámetro es 10.
Configura el parámetro fuente max_worker_processes en, al menos, la misma cantidad de bases de datos que Database Migration Service migrará (que son todas las bases de datos de la instancia de origen), además de la cantidad de
max_worker_processes
que ya se usó en tu instancia. Si planeas usar la configuración de paralelismo de volcado de datos ajustada, asegúrate de aumentar la cantidad de procesos de trabajo y verificar tu configuración. Para ello, ejecuta la prueba del trabajo de migración cuando lo crees.El valor predeterminado para este parámetro es 8.
Adjunta el grupo de parámetros a la instancia. Si creas una instancia nueva, puedes encontrar esta opción en Configuración adicional.
De lo contrario, modifica la instancia para adjuntar el grupo de parámetros.
Para aplicar los cambios de configuración, reinicia la instancia de origen.
Cloud SQL para PostgreSQL
Habilita la replicación lógica y la decodificación para la base de datos de origen configurando las siguientes marcas:
- Establece las marcas
cloudsql.logical_decoding
ycloudsql.enable_pglogical
enon
. Establece la marca max_replication_slots. Esta marca define la cantidad máxima de ranuras de replicación que puede admitir la instancia de origen. Debe establecerse en al menos la cantidad de suscripciones que se espera conectar, más algunas reservas para la sincronización de tablas.
Database Migration Service requiere una ranura para cada base de datos que se migra (que son todas las bases de datos de la instancia de origen).
Por ejemplo, si hay 5 bases de datos en la instancia de origen y se crearán 2 trabajos de migración para la fuente, la cantidad de ranuras de replicación debe ser al menos de 5 * 2 = 10, más la cantidad de ranuras de replicación que ya usas. Si planeas usar la configuración ajustada de paralelismo de volcado de datos, asegúrate de aumentar la cantidad de ranuras de replicación y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.
El valor predeterminado para esta marca es 10.
Configura la marca max_wal_senders en, al menos, lo mismo que
max_replication_slots
, además de la cantidad de remitentes que ya se usaron en tu instancia.Por ejemplo, si la marca
max_replication_slots
se establece en10
y ya usas 2 remitentes, la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12. Si planeas usar la configuración de paralelismo de volcado de datos ajustado, asegúrate de aumentar la cantidad de remitentes y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.El valor predeterminado para esta marca es 10.
Establece la marca de origen max_worker_processes en, al menos, la misma cantidad de bases de datos que Database Migration Service migrará (que son todas las bases de datos de la instancia de origen), más la cantidad de
max_worker_processes
que ya se usó en tu instancia. Si planeas usar la configuración ajustada de paralelismo de volcado de datos, asegúrate de aumentar la cantidad de procesos de trabajo y verificar tu configuración ejecutando la prueba del trabajo de migración cuando lo crees.El valor predeterminado para esta marca es 8.
Establece el parámetro
wal_sender_timeout
en0
:ALTER SYSTEM SET wal_sender_timeout = 0;
El valor
0
inhabilita el mecanismo de tiempo de espera que finaliza las conexiones de replicación inactivas.- Reinicia la instancia de origen para que se apliquen los cambios de configuración que realizaste en las marcas.
Habilita la supervisión del retraso de replicaciones para las versiones de PostgreSQL anteriores a la 9.6
Si migras desde una versión de PostgreSQL anterior a la 9.6, la métrica de retraso de replicación no está disponible de forma predeterminada. Las siguientes alternativas te permiten hacer un seguimiento de esta métrica para garantizar un tiempo de inactividad mínimo cuando asciendas la base de datos:
Opción 1: Habilita Database Migration Service para realizar un seguimiento del retraso de replicación mediante el acceso a una consulta específica. Realiza lo siguiente con un usuario con el privilegio
SUPERUSER
:Define la siguiente función para permitir que el servicio de migración de bases de datos consulte la demora de replicación.
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; $$;
Ejecuta los siguientes comandos para otorgar el permiso
EXECUTE
a USER:REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};
Opción 2: Otorga el privilegio
SUPERUSER
directamente al USER que se usó para conectarse a la instancia de origen. Esto permitirá que Database Migration Service lea la demora de replicación directamente.Opción 3: Realiza un seguimiento del retraso de replicación de forma independiente mediante la siguiente consulta:
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%';
En esta opción, Database Migration Service no reflejará la métrica de retraso de replicación en los grafos o las respuestas de la API.