Uso de la replicación lógica de PostgreSQL con Aurora - Amazon Aurora

Uso de la replicación lógica de PostgreSQL con Aurora

Al utilizar la función de replicación lógica de PostgreSQL con su clúster de base de datos de Aurora PostgreSQL, puede replicar y sincronizar tablas individuales en lugar de toda la instancia de base de datos. La replicación lógica usa un modelo de publicación y suscripción para replicar los cambios de una fuente a uno o más destinatarios. Para ello, usa registros de cambios del registro de escritura anticipada (WAL) de PostgreSQL. La fuente, o publicador, envía los datos WAL de las tablas especificadas a uno o más destinatarios (suscriptor), replicando así los cambios y manteniendo la tabla del suscriptor sincronizada con la tabla del publicador. El conjunto de cambios del publicador se identifica mediante una publicación. Los suscriptores obtienen los cambios mediante la creación de una suscripción que define la conexión con la base de datos del publicador y sus publicaciones. Un intervalo de replicación es el mecanismo que se utiliza en este esquema para realizar un seguimiento del progreso de una suscripción.

Para los clústeres de bases de datos de Aurora PostgreSQL, los registros WAL se guardan en el almacenamiento de Aurora. El clúster de base de datos de Aurora PostgreSQL que actúa como publicador en un escenario de replicación lógica lee los datos de WAL del almacenamiento de Aurora, los decodifica y los envía al suscriptor para que los cambios se puedan aplicar a la tabla de esa instancia. El publicador utiliza un decodificador lógico para decodificar los datos y que los suscriptores puedan utilizarlos. De forma predeterminada, los clústeres de bases de datos de Aurora PostgreSQL utilizan el complemento de PostgreSQL pgoutput nativo al enviar datos. Hay otros decodificadores lógicos disponibles. Por ejemplo, Aurora PostgreSQL también admite el complemento wal2json que convierte los datos WAL a JSON.

A partir de las versiones 14.5, 13.8, 12.12 y 11.17 de Aurora PostgreSQL, Aurora PostgreSQL amplía el proceso de replicación lógica de PostgreSQL con una memoria caché de escritura para mejorar el rendimiento. Los registros de transacciones de WAL se almacenan en caché localmente, en un búfer, para reducir la cantidad de E/S del disco, es decir, la lectura del almacenamiento de Aurora durante la decodificación lógica. La caché de escritura se usa de forma predeterminada cuando usa replicación lógica para el clúster de bases de datos de Aurora PostgreSQL. Aurora proporciona varias funciones que puede usar para administrar la caché. Para obtener más información, consulte Administración de la memoria caché de escritura de la replicación lógica de Aurora PostgreSQL.

La replicación lógica es compatible con todas las versiones de Aurora PostgreSQL disponibles actualmente. Para obtener información detallada sobre la versión, consulte las actualizaciones de Amazon Aurora PostgreSQL en las notas de la versión de Aurora PostgreSQL.

La replicación lógica es compatible con Babelfish para Aurora PostgreSQL a partir de las siguientes versiones:

  • Versión 15.7 y posteriores

  • Versión 16.3 y posteriores

nota

Además de la característica de replicación lógica nativa de PostgreSQL introducida en PostgreSQL 10, Aurora PostgreSQL también admite la extensión pglogical. Para obtener más información, consulte Uso de pglogical para sincronizar datos entre instancias.

Para obtener información adicional sobre la implementación de PostgreSQL en la replicación lógica, consulte la sección sobre replicación lógica y la sección sobre conceptos de descodificación lógica.

En los siguientes temas, encontrará información sobre la configuración de la replicación lógica entre los clústeres de base de datos de Aurora PostgreSQL.

Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL

La configuración de la replicación lógica requiere privilegios de rds_superuser. El clúster de base de datos de Aurora PostgreSQL debe estar configurado para usar un grupo de parámetros de clúster de base de datos personalizado, de modo que pueda establecer los parámetros necesarios tal como se detalla en el procedimiento siguiente. Para obtener más información, consulte Grupos de parámetros de clústeres de base de datos para clústeres de base de datos en Amazon Aurora.

Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL
  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, elija el clúster de base de datos de Aurora PostgreSQL.

  3. Haga clic en la pestaña Configuration (Configuración). En los detalles de la instancia, busque el enlace Grupo de parámetros con el Grupo de parámetros de clúster de base de datos para Tipo.

  4. Elija el enlace para abrir los parámetros personalizados asociados al clúster de base de datos de Aurora PostgreSQL.

  5. En el campo de búsqueda Parameters (Parámetros), escriba rds para buscar el parámetro rds.logical_replication. El valor predeterminado de este parámetro es 0, lo que significa que está desactivado de forma predeterminada.

  6. Elija Edit parameters (Editar parámetros) para acceder a los valores de las propiedades y, a continuación, elija 1 en el selector para activar la función. En función del uso previsto, es posible que también tenga que cambiar la configuración de los siguientes parámetros. Sin embargo, en muchos casos, los valores predeterminados son suficientes.

    • max_replication_slots: establezca este parámetro en un valor que sea al menos igual al número total planificado de publicaciones y suscripciones de replicación lógica. Si utiliza AWS DMS, este parámetro debe ser igual al menos a las tareas de captura de datos de cambios planificadas del clúster, además de las publicaciones y suscripciones de replicación lógica.

    • max_wal_senders y:max_logical_replication_workers establezca estos parámetros a un valor que sea al menos igual al número de ranuras de replicación lógica que desea queden activas o el número de tareas activas de AWS DMS para la captura de datos de cambios. Dejar inactiva una ranura de replicación lógica evita que vacuum elimine las tuplas obsoletas de las tablas, por lo que se recomienda supervisar las ranuras de replicación y eliminar las ranuras inactivas cuando sea necesario.

    • max_worker_processes: establezca este parámetro en un valor que sea al menos igual al total de los valores max_logical_replication_workers, autovacuum_max_workers y max_parallel_workers. En las clases de instancias de base de datos pequeñas, los procesos de trabajo en segundo plano pueden afectar a las cargas de trabajo de las aplicaciones, por lo que debe supervisarse el rendimiento de la base de datos si establece max_worker_processes en un valor superior al predeterminado. (El valor predeterminado es el resultado de GREATEST(${DBInstanceVCPU*2},8}, lo que significa que, de forma predeterminada, es 8 o dos veces el equivalente en CPU de la clase de instancia de base de datos, lo que sea mayor).

    nota

    Se pueden modificar los valores de los parámetros de un grupo de parámetros de base de datos creado por el cliente, pero no se pueden modificar los valores de los parámetros de un grupo de parámetros de base de datos predeterminado.

  7. Elija Guardar cambios.

  8. Reinicie la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL para que los cambios surtan efecto. En la consola de Amazon RDS, elija la instancia de base de datos principal del clúster y elija Reboot (Reiniciar) en el menú Actions (Acciones).

  9. Cuando la instancia esté disponible, puede comprobar que la replicación lógica esté activada de la siguiente manera.

    1. Use psql para conectarse a la instancia de escritor de su clúster de base de datos de Aurora PostgreSQL.

      psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
    2. Compruebe que la replicación lógica esté habilitada mediante el siguiente comando.

      labdb=> SHOW rds.logical_replication; rds.logical_replication ------------------------- on (1 row)
    3. Verifique que el parámetro wal_level esté establecido en logical.

      labdb=> SHOW wal_level; wal_level ----------- logical (1 row)

Para ver un ejemplo del uso de la replicación lógica para mantener una tabla de base de datos sincronizada con los cambios de un clúster de base de datos de Aurora PostgreSQL de origen, consulte Ejemplo: uso de la replicación lógica con clústeres de base de datos de Aurora PostgreSQL.

Desactivación de la replicación lógica

Tras completar las tareas de replicación, debe detener el proceso de replicación, eliminar las ranuras de replicación y desactivar la replicación lógica. Antes de eliminar las ranuras, asegúrese de que ya no sean necesarias. Las ranuras de replicación activas no se pueden eliminar.

Desactivación de la replicación lógica
  1. Elimine todas las ranuras de replicación.

    Para eliminar todas las ranuras de replicación, conéctese al publicador y ejecute el siguiente comando de SQL.

    SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

    Las ranuras de replicación no pueden estar activas cuando ejecute este comando.

  2. Modifique el grupo de parámetros de clúster de base de datos personalizado asociado al publicador tal como se detalla en Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL, pero establezca el parámetro rds.logical_replication en 0.

    Para obtener más información acerca de los grupos de parámetros personalizados, consulte Modificación de los parámetros en un grupo de parámetros de clúster de base de datos en Amazon Aurora.

  3. Reinicie el clúster de base de datos de Aurora PostgreSQL del publicador para que se aplique el cambio en el parámetro rds.logical_replication.

Administración de la memoria caché de escritura de la replicación lógica de Aurora PostgreSQL

De forma predeterminada, las versiones 14.5, 13.8, 12.12 y 11.17 y posteriores de Aurora PostgreSQL utilizan una memoria caché de escritura para mejorar el rendimiento de la replicación lógica. Sin la memoria caché de escritura, Aurora PostgreSQL utiliza la capa de almacenamiento de Aurora en su implementación del proceso de replicación lógica nativo de PostgreSQL. Para ello, escribe los datos de WAL en el almacenamiento y, a continuación, los lee del almacenamiento para decodificarlos y enviarlos (replicarlos) a sus destinos (suscriptores). Esto puede provocar cuellos de botella durante la replicación lógica de los clústeres de bases de datos de Aurora PostgreSQL.

La memoria caché de escritura reduce la necesidad de utilizar la capa de almacenamiento de Aurora. En lugar de escribir y leer siempre desde la capa de almacenamiento de Aurora, Aurora PostgreSQL utiliza un búfer para almacenar en caché el flujo WAL lógico de modo que pueda usarse durante el proceso de replicación, en lugar de extraerlo siempre del disco. Este búfer es la memoria caché nativa de PostgreSQL que utiliza la replicación lógica, identificada en los parámetros del clúster de base de datos de Aurora PostgreSQL como rds.logical_wal_cache. De forma predeterminada, esta caché utiliza 1/32 de la configuración de caché del búfer (shared_buffers) del clúster de base de datos de Aurora PostgreSQL, pero no menos de 64 KB ni más del tamaño de un segmento de WAL, normalmente 16 MB.

Al utilizar la replicación lógica con el clúster de base de datos de Aurora PostgreSQL (para las versiones que admiten la caché de escritura), puede supervisar la tasa de aciertos de caché para comprobar cómo funciona en su caso de uso. Para ello, conéctese a la instancia de escritura del clúster de base de datos de Aurora PostgreSQL mediante la función de Aurora psql y, a continuación, utilice la función de Aurora aurora_stat_logical_wal_cache, como se muestra en el siguiente ejemplo.

SELECT * FROM aurora_stat_logical_wal_cache();

La función devuelve una salida como la siguiente:

name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp -----------+------------+-----------+------------+-----------+----------+-------------- test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39... test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34... (2 rows)

Los valores de last_reset_timestamp se han acortado para facilitar la lectura. Para obtener más información acerca de esta función, consulte aurora_stat_logical_wal_cache.

Aurora PostgreSQL proporciona las dos funciones siguientes para supervisar la memoria caché de escritura.

Si descubre que el tamaño de la caché de WAL que se ha ajustado automáticamente no es suficiente para sus cargas de trabajo, puede cambiar el valor de rds.logical_wal_cache manualmente modificando el parámetro en el grupo de parámetros del clúster de base de datos personalizado. Tenga en cuenta que cualquier valor positivo inferior a 32 kB se considera 32 kB. Para obtener más información sobre wal_buffers, consulte Write Ahead Log (Registro de escritura) en la documentación de PostgreSQL.

Administración de ranuras lógicas para Aurora PostgreSQL

La actividad de streaming se captura en la vista pg_replication_origin_status. Para ver el contenido de esta vista, puede usar la función pg_show_replication_origin_status(), tal como se muestra a continuación:

SELECT * FROM pg_show_replication_origin_status();

Puede obtener una lista de las ranuras lógicas mediante la siguiente consulta SQL.

SELECT * FROM pg_replication_slots;

Para eliminar una ranura lógica, use pg_drop_replication_slot con el nombre de la ranura, como se muestra en el siguiente comando.

SELECT pg_drop_replication_slot('test_slot');

Ejemplo: uso de la replicación lógica con clústeres de base de datos de Aurora PostgreSQL

En el siguiente procedimiento se muestra cómo iniciar la replicación lógica entre dos clústeres de base de datos de Aurora PostgreSQL. Tanto el publicador como el suscriptor deben estar configurados para la replicación lógica, tal como se detalla en Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL.

El clúster de base de datos de Aurora PostgreSQL que es el publicador designado también debe permitir el acceso a la ranura de replicación. Para ello, modifique el grupo de seguridad asociado a la nube pública virtual (VPC) del clúster de base de datos de Aurora PostgreSQL en función del servicio Amazon VPC. Para permitir el acceso entrante, agregue el grupo de seguridad asociado a la VPC del suscriptor al grupo de seguridad del publicador. Para obtener más información, consulte Controlar el tráfico hacia los recursos mediante grupos de seguridad en la Guía del usuario de Amazon Virtual Private Cloud.

Una vez completados estos pasos preliminares, puede usar los comandos CREATE PUBLICATION de PostgreSQL en el publicador y CREATE SUBSCRIPTION en el suscriptor, tal como se detalla en el siguiente procedimiento.

Para iniciar la replicación lógica entre dos clústeres de base de datos de Aurora PostgreSQL.

En estos pasos se supone que los clústeres de base de datos de Aurora PostgreSQL tienen una instancia de escritor con una base de datos en la que crear las tablas de ejemplo.

  1. En el clúster de base de datos de Aurora PostgreSQL de publicadores

    1. Cree una tabla con la siguiente instrucción SQL.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
    2. Inserte datos en la base de datos de publicador mediante la siguiente instrucción SQL.

      INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
    3. Compruebe que los datos existen en la tabla mediante la siguiente instrucción SQL.

      SELECT count(*) FROM LogicalReplicationTest;
    4. Cree una publicación para esta tabla mediante la instrucción CREATE PUBLICATION que se indica a continuación.

      CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
  2. En el clúster de base de datos Aurora PostgreSQL de suscriptor

    1. Cree la misma tabla LogicalReplicationTest en el suscriptor que creó en el publicador, de la siguiente manera.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
    2. Compruebe que esta tabla esté vacía.

      SELECT count(*) FROM LogicalReplicationTest;
    3. Crea una suscripción para recibir los cambios del publicador. Debe utilizar los siguientes detalles sobre el clúster de base de datos Aurora PostgreSQL de publicador.

      • host: la instancia de base de datos de escritor del clúster de base de datos de Aurora pPostgreSQL del publicador.

      • puerto: el puerto en el que la instancia de base de datos de escritor está a la escucha. El valor predeterminado de PostgreSQL es 5432.

      • dbname: el nombre de la base de datos.

      CREATE SUBSCRIPTION testsub CONNECTION 'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password' PUBLICATION testpub;
      nota

      Especifique una contraseña distinta de la que se muestra aquí como práctica recomendada de seguridad.

      Una vez creada la suscripción, se crea una ranura de replicación lógica en el publicador.

    4. Para comprobar en este ejemplo que se replican los datos iniciales en el suscriptor, use la siguiente instrucción SQL en la base de datos de suscriptor.

      SELECT count(*) FROM LogicalReplicationTest;

Todo cambio adicional en el publicador se replicará en el suscriptor.

La replicación lógica afecta al rendimiento. Le recomendamos que desactive la replicación lógica una vez finalizadas las tareas de replicación.

Ejemplo: replicación lógica mediante Aurora PostgreSQL y AWS Database Migration Service

Puede usar el AWS Database Migration Service (AWS DMS) para replicar una base de datos o parte de una base de datos. Utilice AWS DMS para migrar sus datos de una base de datos de Aurora PostgreSQL a otra base de datos comercial o de código abierto. Para obtener más información acerca de AWS DMS, consulte la Guía del usuario de AWS Database Migration Service.

En el siguiente ejemplo, se muestra cómo configurar la reproducción lógica desde una base de datos de Aurora PostgreSQL como publicador y, luego, cómo usar AWS DMS para la migración. El publicador y suscriptor usados en este ejemplo son los mismos que los creados en Ejemplo: uso de la replicación lógica con clústeres de base de datos de Aurora PostgreSQL.

Para configurar la reproducción lógica con AWS DMS, necesita detalles acerca de su publicador y suscriptor de Amazon RDS. Concretamente, necesita detalles acerca de la instancia de base de datos de escritor del publicador y la instancia de base de datos de suscriptor.

Obtenga la siguiente información para la instancia de base de datos de escritor del publicador:

  • Identificador de la nube virtual privada (VPC)

  • Grupo de subredes

  • Zona de disponibilidad (AZ)

  • Grupo de seguridad de VPC

  • ID de instancia de base de datos

Obtenga la siguiente información para la instancia de base de datos de suscriptor:

  • ID de instancia de base de datos

  • Motor de origen

Para utilizar AWS DMS para la reproducción lógica con Aurora PostgreSQL
  1. Prepare la base de datos de publicador para trabajar con AWS DMS.

    Para ello, tanto PostgreSQL 10.x como bases de datos posteriores requieren que aplique funciones contenedoras de AWS DMS a la base de datos de publicador. Para obtener detalles acerca de este paso y pasos posteriores, consulte las instrucciones en Uso de PostgreSQL versión 10.x y posterior como origen para AWS DMS en la guía del usuario de AWS Database Migration Service.

  2. Inicie sesión en la AWS Management Console y abra la consola de AWS DMS en https://console.aws.amazon.com/dms/v2. En la parte superior derecha, elija la misma región de AWS en la que se encuentran el publicador y el suscriptor.

  3. Cree una instancia de replicación de AWS DMS.

    Elija valores que sean los mismos que para la instancia de base de datos de escritor de su publicador. Entre estos se incluyen los siguientes:

    • En VPC, elija la misma VPC que para la instancia de base de datos de escritor.

    • En Replication Subnet Group (Grupo de subredes de replicación), elija un grupo de subredes con los mismos valores que para la instancia de base de datos de escritor. Cree uno nuevo si es necesario.

    • En la Availability zone (Zona de disponibilidad), elija la misma zona que para la instancia de base de datos de escritor.

    • En el VPC Security Group (Grupo de seguridad de VPC), elija el mismo grupo que para la instancia de base de datos de escritor.

  4. Cree un punto de enlace de AWS DMS para el origen.

    Especifique el publicador como punto de enlace de origen mediante los siguientes valores:

    • En Endpoint type (Tipo de punto de enlace), elija Source endpoint (Punto de enlace de origen).

    • Elija Select RDS DB Instance (Seleccionar instancia de base de datos de RDS).

    • En RDS Instance (Instancia RDS), elija el identificador de base de datos de la instancia de base de datos de escritor del publicador.

    • En Source engine (Motor de origen), elija postgres.

  5. Cree un punto de enlace de AWS DMS para el destino.

    Especifique el suscriptor como punto de enlace de destino mediante los siguientes valores:

    • En Endpoint type (Tipo de punto de enlace), elija Target endpoint (Punto de enlace de destino).

    • Elija Select RDS DB Instance (Seleccionar instancia de base de datos de RDS).

    • En RDS Instance (Instancia RDS), elija el identificador de base de datos de la instancia de base de datos de suscriptor.

    • Elija un valor para Source engine (Motor de origen). Por ejemplo, si el suscriptor es una base de datos PostgreSQL de RDS, elija postgres. Si el suscriptor es una base de datos Aurora PostgreSQL, elija aurora-postgresql.

  6. Cree una tarea de migración de bases de datos de AWS DMS.

    Debe usar una tarea de migración de bases de datos para especificar qué tablas de base de datos se van a migrar, asignar los datos mediante un esquema de destino y crear tablas nuevas en la base de datos de destino. Como mínimo, use los siguientes valores para Task configuration (Configuración de tareas):

    • En Replication instance (Instancia de replicación), elija la instancia de replicación que creó en un paso anterior.

    • En Source database endpoint (Punto de enlace de base de datos de origen), elija el origen del publicador que creó en un paso anterior.

    • En Target database endpoint (Punto de enlace de base de datos de destino), elija el destino del suscriptor que creó en un paso anterior.

    El resto de los detalles de la tarea dependen de su proyecto de migración. Para obtener más información acerca de la especificación de todos los detalles de las tareas de DMS, consulte Trabajo con las tareas DMS de AWS en la guía del usuario de AWS Database Migration Service.

Una vez que AWS DMS cree la tarea, comenzará a migrar datos del publicador al suscriptor.