Descripción general
El servicio de migración de bases de datos admite migraciones continuas desde bases de datos de origen a bases de datos de destino de Cloud SQL.
Las bases de datos de origen compatibles con PostgreSQL incluyen:
- Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17.
- Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16, 17.
- PostgreSQL autoadministrado (local o en cualquier máquina virtual en la nube que usted controle completamente) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
- Cloud SQL para PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
- Base de datos de Microsoft Azure para servidor flexible PostgreSQL: 11+
Configurar su fuente requiere configurar tanto la instancia de origen como las bases de datos de origen subyacentes.
Configure su instancia de origen
Para configurar su instancia de origen, siga estos pasos:
- Para fuentes de Cloud SQL: si está migrando 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 direcciones IP que no es RFC 1918 , agregue el rango que no es RFC 1918 a la configuración de red de su instancia de Cloud SQL de origen. Consulta Configurar redes autorizadas en la documentación de Cloud SQL.
- Su instancia de origen debe incluir la base de datos
postgres
. Si no tiene esta base de datos, créela. Instale el paquete
pglogical
en la instancia fuente y asegúrese de que esté incluido en la variableshared_preload_libraries
. Consulte Instalar el paquetepglogical
en la instancia de origen de su entorno.Verifique las extensiones en su instancia de origen. El servicio de migración de bases de datos no migra 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, verifique que sus objetos o aplicaciones no hagan referencia a ninguna extensión no compatible. Recomendamos eliminar estas extensiones y referencias de su base de datos de origen antes de continuar.
Para fuentes que usan la extensión
pg_cron
: el servicio de migración de base de datos no migra la extensiónpg_cron
(o cualquier configuracióncron
asociada con la extensión), pero es compatible con destinos de Cloud SQL para PostgreSQL. Si usa la extensiónpg_cron
en sus bases de datos de origen, puede volver a instalarla en su instancia de destino una vez completada la migración.
Configure sus bases de datos de origen
El Servicio de migración de bases de datos migra todas las bases de datos de su instancia de origen, excepto las siguientes bases de datos:
- Para fuentes PostgreSQL locales: bases de datos de plantilla
template0
ytemplate1
- Para orígenes de Amazon RDS:
template0
,template1
yrdsadmin
- Para fuentes de Cloud SQL: bases de datos de plantilla
template0
ytemplate1
- Para fuentes de Microsoft Azure:
azure_maintenance
,azure_sys
,template0
,template1
Haga lo siguiente en cada base de datos de su instancia de origen que no se mencione anteriormente:
Solo para fuentes de PostgreSQL versión 9.4 , instale las siguientes extensiones
pglogical
en cada base de datos en su instancia de fuente:-
CREATE EXTENSION IF NOT EXISTS pglogical;
-
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
-
Para todas las demás versiones , instale solo la extensión
pglogical
en cada base de datos en su instancia de origen:CREATE EXTENSION IF NOT EXISTS pglogical
.Para las tablas que no tienen claves principales, el Servicio de migración de bases de datos admite la migración de la instantánea inicial y las declaraciones
INSERT
durante la fase CDC . Debe migrar las declaracionesUPDATE
yDELETE
manualmente.El USER que está utilizando para conectarse 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
postgres
predeterminada. Puede crear un nuevo usuario o reutilizar uno existente. Para establecer estos privilegios, conéctese a la instancia y ejecute 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_") en cada base de datos para migrar. -
GRANT USAGE on SCHEMA pglogical to PUBLIC;
en cada base de datos a 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_") en cada base de datos para 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_") en cada base de datos para migrar. - Si su fuente es Amazon RDS , ejecute el siguiente comando:
-
GRANT rds_replication to USER
-
- Si su fuente no es Amazon RDS , ejecute el siguiente comando:
-
ALTER USER USER with REPLICATION
-
-
Instale el paquete pglogical
en la instancia fuente
Esta sección describe cómo configurar el paquete pglogical
y los parámetros aplicables, según su instancia de origen.
PostgreSQL local o autoadministrado
- Instale el paquete pglogic en el servidor.
- Conéctese a la instancia y establezca los siguientes parámetros, según sea necesario:
shared_preload_libraries
debe incluirpglogical
.Para configurar este parámetro, ejecute
ALTER SYSTEM SET shared_preload_libraries = 'pglogical, [any other libraries in your instance] ';
dominio.- Establezca
wal_level
enlogical
.Para configurar este parámetro, ejecute
ALTER SYSTEM SET wal_level = 'logical';
dominio. Establezca
wal_sender_timeout
en0
.Para configurar este parámetro, ejecute
ALTER SYSTEM SET wal_sender_timeout = 0;
comando, donde0
deshabilita el mecanismo de tiempo de espera que se utiliza para finalizar las conexiones de replicación inactivas.max_replication_slots define la cantidad máxima de ranuras de replicación que la instancia de origen puede admitir. Se debe configurar al menos la cantidad de suscripciones que se espera que se conecten, más algunas reservas para la sincronización de tablas.
El servicio de migración de bases de datos 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 si hay 2 trabajos de migración creados para el origen, entonces el número de ranuras de replicación debe ser al menos 5 * 2 = 10, más el número de ranuras de replicación que ya utiliza. Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de ranuras de replicación y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.
Para configurar este parámetro, ejecute
ALTER SYSTEM SET max_replication_slots = # ;
comando, donde # representa el número máximo de ranuras de replicación.max_wal_senders debe establecerse al menos en el mismo valor que
max_replication_slots
, más la cantidad de remitentes que ya se utilizan en su instancia.Por ejemplo, si el parámetro
Para configurar este parámetro, ejecutemax_replication_slots
está establecido en10
y ya está usando 2 remitentes, entonces la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12. Si planea usar configuraciones de paralelismo de volcado de datos ajustadas, asegúrese de aumentar la cantidad de remitentes y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.ALTER SYSTEM SET max_wal_senders = # ;
comando, donde # representa el número de procesos del remitente WAL que se ejecutan simultáneamente.- max_worker_processes debe configurarse en al menos la misma cantidad de bases de datos que el Servicio de migración de bases de datos va a migrar (que son todas las bases de datos en la instancia de origen), más la cantidad de
max_worker_processes
que ya se usan en su instancia.Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de procesos de trabajo y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.
Para configurar este parámetro, ejecute
ALTER SYSTEM SET max_worker_processes = # ;
comando, donde # representa el número de bases de datos que se migrarán.
- Para aplicar los cambios de configuración, reinicie la instancia de origen .
Base de datos de Microsoft Azure para PostgreSQL
Para configurar su base de datos Microsoft Azure para el origen PostgreSQL, siga estos pasos:
- Instale el paquete pglogic en su servidor.
Solo para fuentes de PostgreSQL versión 9.4 , instale las siguientes extensiones
pglogical
en cada base de datos en su instancia de fuente:-
CREATE EXTENSION IF NOT EXISTS pglogical;
-
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
-
Para todas las demás versiones , instale la extensión
pglogical
en cada base de datos en su instancia de origen:CREATE EXTENSION IF NOT EXISTS pglogical
.Configure los parámetros del servidor requeridos en su origen mediante el portal de Microsoft Azure. Para obtener más información, consulte Configurar los parámetros del servidor en Azure Database para PostgreSQL y Parámetros del servidor en Azure Database para PostgreSQL en la documentación de Microsoft.
Configure los siguientes parámetros:
- Configure
shared_preload_libraries
para incluirpglogical
. - Configure
azure.extensions
para incluirpglogical
. - Establezca
wal_level
enlogical
. Establezca
max_replication_slots
en al menos la cantidad de suscripciones que se espera que se conecten, 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 la instancia de origen puede admitir.El servicio de migración de bases de datos 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 si hay 2 trabajos de migración creados para el origen, entonces el número de ranuras de replicación debe ser al menos 5 * 2 = 10, más el número de ranuras de replicación que ya utiliza. Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de ranuras de replicación y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.
Establezca
max_wal_senders
al menos en el mismo valor quemax_replication_slots
, más la cantidad de remitentes que ya se utilizan en su instancia.Por ejemplo, si el parámetro
max_replication_slots
está establecido en10
y ya está utilizando 2 remitentes, entonces la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12.Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de remitentes y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.
Establezca
max_worker_processes
en al menos la misma cantidad de bases de datos que el Servicio de migración de bases de datos va a migrar (que son todas las bases de datos en la instancia de origen), más la cantidad demax_worker_processes
que ya se usan en su instancia.Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de procesos de trabajo y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.
- Configure
Verifique el valor de su configuración
require_secure_transport
.De forma predeterminada, las bases de datos de Microsoft Azure requieren cifrado SSL/TLS para todas las conexiones entrantes. Según el valor
require_secure_transport
, utilice una de las siguientes configuraciones de cifrado cuando cree el perfil de conexión de origen :- Si
require_secure_transport
estáon
, seleccione Básico , TLS o mTLS . - Si
require_secure_transport
estáoff
, seleccione Ninguno .
- Si
- Para aplicar los cambios de configuración, reinicie la instancia de origen .
Amazon RDS PostgreSQL
Instale la extensión
pglogical
en su base de datos de origen.Para obtener más información, consulte Uso de extensiones de PostgreSQL con Amazon RDS para PostgreSQL en la documentación de Amazon RDS.
Configure la instancia de origen mediante grupos de parámetros .
- Cree un nuevo grupo de parámetros . En el grupo de parámetros:
- Asegúrese
pglogical
shared_preload_libraries
- Establezca el parámetro
rds.logical_replication
en 1. Esto habilitará los registros WAL en el nivel "lógico". - Establezca el parámetro
wal_sender_timeout
en 0. Esto deshabilitará el mecanismo de tiempo de espera que se utiliza para finalizar las conexiones de replicación inactivas. Establezca el parámetro max_replication_slots . Este parámetro define la cantidad máxima de ranuras de replicación que la instancia de origen puede admitir. Se debe configurar al menos la cantidad de suscripciones que se espera que se conecten, más algunas reservas para la sincronización de tablas.
El servicio de migración de bases de datos 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 si se crearán 2 trabajos de migración para el origen, entonces la cantidad de ranuras de replicación debe ser al menos 5 * 2 = 10, más la cantidad de ranuras de replicación que ya utiliza. Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de ranuras de replicación y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.
El valor predeterminado para este parámetro es 10 .
Establezca el parámetro max_wal_senders al menos en el mismo que
max_replication_slots
, más la cantidad de remitentes que ya se utilizan en su instancia.Por ejemplo, si el parámetro
max_replication_slots
está establecido en10
y ya está usando 2 remitentes, entonces la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12. Si planea usar configuraciones de paralelismo de volcado de datos ajustadas, asegúrese de aumentar la cantidad de remitentes y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.El valor predeterminado para este parámetro es 10 .
Establezca el parámetro de origen max_worker_processes en al menos la misma cantidad de bases de datos que el Servicio de migración de bases de datos va a migrar (que son todas las bases de datos en la instancia de origen), más la cantidad de
max_worker_processes
que ya se usan en su instancia. Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de procesos de trabajo y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.El valor predeterminado para este parámetro es 8 .
Adjunte el grupo de parámetros a la instancia. Si está creando una nueva instancia, puede encontrar esta opción en Configuración adicional .
De lo contrario, modifique la instancia para adjuntar el grupo de parámetros.
Para aplicar los cambios de configuración, reinicie la instancia de origen .
Nube SQL para PostgreSQL
Habilite la replicación lógica y la decodificación para la base de datos de origen configurando los siguientes indicadores:
- Establezca los indicadores
cloudsql.logical_decoding
ycloudsql.enable_pglogical
enon
. Establezca el indicador max_replication_slots . Este indicador define la cantidad máxima de ranuras de replicación que la instancia de origen puede admitir. Se debe configurar al menos la cantidad de suscripciones que se espera que se conecten, más algunas reservas para la sincronización de tablas.
El servicio de migración de bases de datos 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 si se crearán 2 trabajos de migración para el origen, entonces la cantidad de ranuras de replicación debe ser al menos 5 * 2 = 10, más la cantidad de ranuras de replicación que ya utiliza. Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de ranuras de replicación y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.
El valor predeterminado para esta bandera es 10 .
Establezca el indicador max_wal_senders al menos en el mismo que
max_replication_slots
, más la cantidad de remitentes que ya se utilizan en su instancia.Por ejemplo, si el indicador
max_replication_slots
está establecido en10
y ya está usando 2 remitentes, entonces la cantidad de procesos de remitente WAL que se ejecutan al mismo tiempo sería 10 + 2 = 12. Si planea usar configuraciones de paralelismo de volcado de datos ajustadas, asegúrese de aumentar la cantidad de remitentes y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.El valor predeterminado para esta bandera es 10 .
Establezca el indicador de origen max_worker_processes en al menos la misma cantidad de bases de datos que el Servicio de migración de bases de datos va a migrar (que son todas las bases de datos en la instancia de origen), más la cantidad de
max_worker_processes
que ya se usan en su instancia. Si planea utilizar configuraciones ajustadas de paralelismo de volcado de datos, asegúrese de aumentar la cantidad de procesos de trabajo y verificar su configuración ejecutando la prueba del trabajo de migración cuando cree el trabajo de migración.El valor predeterminado para esta bandera es 8 .
Establezca el parámetro
wal_sender_timeout
en0
:ALTER SYSTEM SET wal_sender_timeout = 0;
El valor
0
deshabilita el mecanismo de tiempo de espera que finaliza las conexiones de replicación inactivas.- Reinicie su instancia de origen para que los cambios de configuración que realizó en las banderas puedan surtir efecto.
Habilite el monitoreo del retraso de replicación para la versión de PostgreSQL anterior a la 9.6
Si está migrando 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 le permiten realizar un seguimiento de esta métrica para garantizar un tiempo de inactividad mínimo al promocionar la base de datos:
Opción 1 : habilite el Servicio de migración de bases de datos para realizar un seguimiento del retraso de replicación otorgando acceso a una consulta específica. Utilizando un usuario con privilegio
SUPERUSER
, realice lo siguiente:Defina la siguiente función para permitir que el Servicio de migración de bases de datos consulte el retraso 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; $$;
Otorgue el permiso
EXECUTE
al USER ejecutando los siguientes comandos:-
REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
-
GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};
-
Opción 2 : Otorgue el privilegio
SUPERUSER
directamente al USER utilizado para conectarse a la instancia de origen. Esto permitirá que el Servicio de migración de bases de datos lea el retraso de replicación directamente.Opción 3 : realice 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, el Servicio de migración de bases de datos no reflejará la métrica de retraso de replicación en los gráficos o respuestas de API.
A menos que se indique lo contrario, el contenido de esta página está sujeto a la licencia Reconocimiento 4.0 de Creative Commons y las muestras de código están sujetas a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio web de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-05-15 (UTC).