# Replicación con Amazon Aurora PostgreSQL
A continuación, encontrará información sobre la replicación con Amazon Aurora PostgreSQL, lo que incluye cómo supervisar y utilizar la replicación lógica.
**Topics**
+ [Uso de réplicas de Aurora](#AuroraPostgreSQL.Replication.Replicas)
+ [Mejora de la disponibilidad de lectura de las réplicas de Aurora](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Monitoreo de replicación de Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Monitoring)
+ [Información general sobre la replicación lógica de PostgreSQL con Aurora](AuroraPostgreSQL.Replication.Logical.md)
+ [Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [Desactivación de la replicación lógica](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Supervisión de la memoria caché de escritura indirecta y de las ranuras lógicas para la replicación lógica de Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [Ejemplo: uso de la replicación lógica con clústeres de base de datos de Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [Ejemplo: replicación lógica mediante Aurora PostgreSQL y AWS Database Migration Service](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [Configuración de la autenticación de IAM para conexiones de replicación lógica](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Uso de réplicas de Aurora
Una *réplica de Aurora* es un punto de enlace independiente en un clúster de base de datos Aurora que se utilizan preferentemente para ajustar la escala de las operaciones de lectura e incrementar la disponibilidad. Un clúster de base de datos Aurora puede incluir hasta 15 réplicas de Aurora ubicadas en las zonas de disponibilidad de la región de AWS del clúster de base de datos Aurora.
El volumen del clúster de base de datos consta de varias copias de los datos del clúster de base de datos. No obstante, los datos del volumen del clúster se representan como un único volumen lógico para la instancia de base de datos de escritor principal y para las réplicas de Aurora del clúster de base de datos. Para obtener más información acerca de las réplicas de Aurora, consulte [Réplicas de Aurora](Aurora.Replication.md#Aurora.Replication.Replicas).
Las réplicas de Aurora funcionan bien para el escalado de lectura porque están totalmente dedicadas a las operaciones de lectura en el volumen del clúster. La instancia de base de datos de escritor administra operaciones de escritura. El volumen del clúster se comparte entre todas las instancias en su clúster de base de datos Aurora PostgreSQL. Por lo tanto, no se necesita trabajo adicional para replicar una copia de los datos de cada réplica Aurora.
Con Aurora PostgreSQL, cuando se elimina una réplica de Aurora, su punto de enlace de instancia se quita inmediatamente y la réplica de Aurora se quita del punto de enlace del lector. Si hay instrucciones que se ejecutan en la réplica de Aurora que se van a eliminar, hay un periodo de gracia de tres minutos. Las instrucciones existentes pueden finalizar correctamente durante el periodo de gracia. Cuando termina dicho periodo, se apaga la réplica de Aurora y se elimina.
Los clústeres de base de datos de Aurora PostgreSQL admiten réplicas de Aurora en diferentes regiones de AWS con la base de datos global de Aurora. Para obtener más información, consulte [Uso de una base de datos global de Amazon Aurora](aurora-global-database.md).
**nota**
Con la característica de disponibilidad de lectura, si quiere reiniciar las réplicas de Aurora en el clúster de base de datos, debe hacerlo manualmente. Para los clústeres de base de datos creados antes de esta característica, al reiniciar la instancia de base de datos del escritor se reinician automáticamente las réplicas de Aurora. El reinicio automático restablece un punto de entrada que garantiza la coherencia de lectura/escritura en todo el clúster de base de datos.
## Mejora de la disponibilidad de lectura de las réplicas de Aurora
Aurora PostgreSQL mejora la disponibilidad de lectura en el clúster de base de datos al atender continuamente las solicitudes de lectura cuando la instancia de base de datos del escritor se reinicia o cuando la réplica de Aurora no puede seguir el ritmo del tráfico de escritura.
La característica de disponibilidad de lectura está disponible de forma predeterminada en las siguientes versiones de Aurora PostgreSQL:
+ Versión 16.1 y todas las versiones posteriores
+ Versión 15.2 y versiones posteriores a la 15
+ Versión 14.7 y versiones posteriores a la 14
+ Versión 13.10 y versiones posteriores a la 13
+ Versión 12.14 y versiones posteriores a la 12
La característica de disponibilidad de lectura es compatible con la base de datos global Aurora en las siguientes versiones:
+ Versión 16.1 y todas las versiones posteriores
+ Versión 15.4 y versiones posteriores a la 15
+ Versión 14.9 y versiones posteriores a la 14
+ Versión 13.12 y versiones posteriores a la 13
+ Versión 12.16 y versiones posteriores a la 12
Para utilizar la característica de disponibilidad de lectura para un clúster de base de datos creado en una de estas versiones antes de este lanzamiento, reinicie la instancia de escritura del clúster de base de datos.
Al modificar los parámetros estáticos de su clúster de base de datos de Aurora PostgreSQL, debe reiniciar la instancia de escritor para que surtan efecto los cambios de parámetros. Por ejemplo, debe reiniciar la instancia del escritor al establecer el valor de `shared_buffers`. Con la característica de disponibilidad de lectura de las réplicas de Aurora, el clúster de base de datos mantiene la disponibilidad mejorada, lo que reduce el impacto al reiniciar la instancia de escritor. Las instancias del lector no se reinician y siguen respondiendo a las solicitudes de lectura. Para aplicar cambios en los parámetros estáticos, reinicie cada instancia individual del lector.
Una réplica de Aurora de un clúster de base de datos de Aurora PostgreSQL puede recuperarse de errores de replicación, como el reinicio del escritor, la conmutación por error, la replicación lenta y los problemas de red, ya que recupera rápidamente el estado de la base de datos en memoria una vez que se vuelve a conectar con el escritor. Este enfoque permite que las instancias de la réplica de Aurora sean coherentes con las actualizaciones de almacenamiento más recientes mientras la base de datos del cliente aún esté disponible.
Es posible que las transacciones en curso que entren en conflicto con la recuperación de la replicación reciban un error, pero el cliente puede volver a intentar estas transacciones una vez que los lectores alcancen al escritor.
### Supervisión de réplicas de Aurora
Puede monitorizar las réplicas de Aurora cuando se recupere de una desconexión del escritor. Utilice las siguientes métricas para consultar la información más reciente sobre la instancia de lector y realizar un seguimiento de las transacciones de solo lectura en curso.
+ La función `aurora_replica_status` se actualiza para que devuelva la información más actualizada de la instancia de lector cuando aún está conectada. La marca de tiempo de la última actualización en `aurora_replica_status` siempre está vacía para la fila correspondiente a la instancia de base de datos en la que se ejecuta la consulta. Esto significa que la instancia de lector tiene los datos más recientes.
+ Cuando la réplica de Aurora se desconecta de la instancia de escritor y se vuelve a conectar, se emite el siguiente evento de base de datos:
`Read replica has been disconnected from the writer instance and reconnected.`
+ Cuando se cancela una consulta de solo lectura debido a un conflicto de recuperación, es posible que aparezca uno o más de los siguientes mensaje de error en el registro de errores de la base de datos:
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### Limitaciones
Las siguientes limitaciones se aplican a las réplicas de Aurora con la característica de disponibilidad de lectura mejorada:
+ Las réplicas de Aurora del clúster de base de datos secundario se pueden reiniciar si los datos no se pueden transmitir desde la instancia de escritor durante la recuperación de la replicación.
+ Las réplicas de Aurora no admiten la recuperación de la replicación en línea si ya hay una en curso y se reiniciará.
+ Las réplicas de Aurora se reiniciarán cuando la instancia de base de datos se acerque al reinicio del ID de la transacción. Para obtener más información acerca del reinicio del ID de la transacción, consulte el tema sobre [prevención de fallos del reinicio del ID de la transacción](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND ).
+ Las réplicas de Aurora pueden reiniciarse cuando el proceso de replicación está bloqueado bajo determinadas circunstancias.
## Monitoreo de replicación de Aurora PostgreSQL
El escalado de lectura y la alta disponibilidad dependen de un tiempo de retardo mínimo. Puede monitorizar el retardo de una réplica de Aurora con respecto a la instancia de base de datos de escritor del clúster de base de datos Aurora PostgreSQL mediante la monitorización de la métrica `ReplicaLag` de Amazon CloudWatch. Como las réplicas de Aurora leen desde el mismo volumen de clúster que la instancia de base de datos de escritor, la métrica `ReplicaLag` tiene un significado diferente para un clúster de base de datos Aurora PostgreSQL. La métrica `ReplicaLag` de una réplica de Aurora indica el retardo de la caché de página de la réplica de Aurora con respecto a la de la instancia de base de datos de escritor.
Para obtener más información acerca de la monitorización de instancias de RDS y de las métricas de CloudWatch, consulte [Supervisión de métricas en un clúster de Amazon Aurora](MonitoringAurora.md).
# Información general sobre 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](https://github.com/eulerto/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 [Supervisión de la memoria caché de escritura indirecta de la replicación lógica en Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) 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](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
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](https://www.postgresql.org/docs/current/logical-replication.html) y la sección sobre [conceptos de descodificación lógica](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html).
**nota**
PostgreSQL 16 ha agregado soporte para la decodificación lógica a partir de réplicas de lectura. Esta característica no se admite en 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](USER_WorkingWithDBClusterParamGroups.md).
**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 Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, elija el clúster de base de datos de Aurora PostgreSQL.
1. 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**.
1. Elija el enlace para abrir los parámetros personalizados asociados al clúster de base de datos de Aurora PostgreSQL.
1. 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.
1. 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.
1. Seleccione **Save changes (Guardar cambios)**.
1. 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).
1. 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
```
1. Compruebe que la replicación lógica esté habilitada mediante el siguiente comando.
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. 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](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
# 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.
1. 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](AuroraPostgreSQL.Replication.Logical.Configure.md), 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](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. 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`.
# Supervisión de la memoria caché de escritura indirecta y de las ranuras lógicas para la replicación lógica de Aurora PostgreSQL
Supervise la memoria caché de escritura indirecta de la replicación lógica y administre las ranuras lógicas para mejorar el rendimiento del clúster de base de datos de Aurora PostgreSQL. A continuación, encontrará más información sobre la memoria caché de escritura indirecta y las ranuras lógicas.
**Topics**
+ [Supervisión de la memoria caché de escritura indirecta de la replicación lógica en Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Administración de ranuras lógicas para Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Supervisión de la memoria caché de escritura indirecta de la replicación lógica en 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 al mínimo la dependencia de la capa de almacenamiento de Aurora. En lugar de escribir y leer de manera constante en esta capa, 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, lo que reduce la necesidad de acceder al disco. Este búfer es la memoria caché nativa de PostgreSQL que utiliza la replicación lógica y que se identifica en los parámetros del clúster de base de datos de Aurora PostgreSQL como `rds.logical_wal_cache`.
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\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL proporciona las dos funciones siguientes para supervisar la memoria caché de escritura.
+ La función:`aurora_stat_logical_wal_cache` para obtener documentación de referencia, consulte [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ La función:`aurora_stat_reset_wal_cache` para obtener documentación de referencia, consulte [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
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. Considere lo siguiente:
+ Cuando el parámetro `rds.logical_replication` está deshabilitado, `rds.logical_wal_cache` se establece en cero (0).
+ Cuando el parámetro `rds.logical_replication` está habilitado, `rds.logical_wal_cache` tiene un valor predeterminado de 16 MB.
+ El parámetro `rds.logical_wal_cache` es estático y requiere un reinicio de la instancia de base de datos para que los cambios surtan efecto. Este parámetro se define en términos de bloques de 8 Kb. 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 [Registro de escritura anticipada](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) 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](AuroraPostgreSQL.Replication.Logical.Configure.md).
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](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) 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);
```
1. Inserte datos en la base de datos de publicador mediante la siguiente instrucción SQL.
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. Compruebe que los datos existen en la tabla mediante la siguiente instrucción SQL.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 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;
```
1. **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);
```
1. Compruebe que esta tabla esté vacía.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. 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.
1. 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](https://docs.aws.amazon.com/dms/latest/userguide/).
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](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
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](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) en la *guía del usuario de AWS Database Migration Service.*
1. Inicie sesión en la Consola de administración de AWS y abra la consola de AWS DMS en [https://console.aws.amazon.com/dms/v2](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.
1. 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.
1. 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**.
1. 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**.
1. 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](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html) 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.
# Configuración de la autenticación de IAM para conexiones de replicación lógica
A partir de las versiones 11 y posteriores de Aurora PostgreSQL, puede usar la autenticación AWS Identity and Access Management (IAM) para las conexiones de replicación. Esta característica mejora la seguridad al permitirle administrar el acceso a la base de datos mediante roles de IAM en lugar de contraseñas. Funciona por clúster y sigue el mismo modelo de seguridad que la autenticación de IAM estándar.
La autenticación de IAM para conexiones de replicación es una característica opcional. Para habilitarla, establezca el parámetro `rds.iam_auth_for_replication` en `1` en el grupo de parámetros del clúster de la base de datos. Como se trata de un parámetro dinámico, el clúster de base de datos no necesita reiniciarse, lo que le permite aprovechar la autenticación de IAM con las cargas de trabajo existentes sin tiempo de inactividad. Antes de habilitar esta característica, asegúrese de que cumple los [Requisitos previos](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites) mostrados a continuación.
## Requisitos previos
Para utilizar la autenticación de IAM para conexiones de replicación, debe cumplir todos los siguientes requisitos:
+ El clúster de base de datos de Aurora PostgreSQL debe ser la versión 11 o posterior.
+ En el clúster de base de datos de Aurora PostgreSQL del publicador:
+ Habilite la autenticación de bases de datos de IAM.
Para obtener más información, consulte [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Habilite la replicación lógica estableciendo el parámetro `rds.logical_replication` en `1`.
Para obtener más información, consulte [Configuración de la replicación lógica para el clúster de base de datos de Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md).
En la replicación lógica, el publicador es el clúster de base de datos de Aurora PostgreSQL de origen que envía los datos a los clústeres de suscriptores. Para obtener más información, consulte [Información general de la replicación lógica de PostgreSQL con Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html).
**nota**
La autenticación de IAM y la replicación lógica deben estar habilitadas en el clúster de base de datos de Aurora PostgreSQL del publicador. Si ninguna de las dos está habilitada, no podrá utilizar la autenticación de IAM para conexiones de replicación.
## Habilitación de la autenticación de IAM para las conexiones de replicación
Realice los siguientes pasos antes de habilitar la autenticación de IAM para la conexión de replicación.
1. Compruebe que el clúster de base de datos de Aurora PostgreSQL cumpla todos los requisitos previos para la autenticación de IAM con conexiones de replicación. Para obtener más información, consulte [Requisitos previos](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites).
1. Configure el parámetro `rds.iam_auth_for_replication` modificando el grupo de parámetros de clúster de base de datos:
+ Establezca el parámetro `rds.iam_auth_for_replication` como `1`. Este parámetro dinámico no requiere un reinicio.
1. Conéctese a la base de datos y conceda los roles necesarios al usuario de replicación:
Los siguientes comandos SQL otorgan los roles necesarios para habilitar la autenticación de IAM para las conexiones de replicación:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
Tras completar estos pasos, el usuario especificado debe usar la autenticación de IAM para las conexiones de replicación.
**importante**
Al habilitar la característica, los usuarios con los roles `rds_iam` y `rds_replication` deben usar la autenticación de IAM para las conexiones de replicación. Esto se aplica si los roles se asignan directamente al usuario o si se heredan a través de otros roles.
## Desactivación de la autenticación de IAM para las conexiones de replicación
Puede desactivar la autenticación de IAM para conexiones de replicación mediante cualquiera de los siguientes métodos:
+ Establecimiento del parámetro `rds.iam_auth_for_replication` en `0` en el grupo de parámetro de clúster de base de datos
+ Otra opción, puede desactivar cualquiera de estas características en el clúster de base de datos de Aurora PostgreSQL:
+ Desactivación de la replicación lógica estableciendo el parámetro `rds.logical_replication` en `0`
+ Desactivación de la autenticación de IAM
Al desactivar la característica, las conexiones de replicación pueden usar contraseñas de bases de datos para la autenticación si están configuradas.
**nota**
Las conexiones de replicación para los usuarios sin el rol `rds_iam` pueden usar la autenticación por contraseña incluso cuando la característica está habilitada.
## Limitaciones y consideraciones
Las limitaciones y consideraciones siguientes se aplican cuando se use la autenticación de IAM para las conexiones de replicación.
+ La autenticación de IAM para las conexiones de replicación solo está disponible para las versiones 11 y posteriores de Aurora PostgreSQL.
+ El publicador debe admitir la autenticación de IAM para las conexiones de replicación.
+ De forma predeterminada, el token de autenticación de IAM caduca a los 15 minutos. Es posible que tenga que actualizar las conexiones de replicación de larga duración antes de que caduque el token.