Uso de réplicas de lectura para Amazon RDS para PostgreSQL - Amazon Relational Database Service
Decodificación lógica en una réplica de lecturaLimitaciones de las réplicas de lectura con PostgreSQLConfiguración de réplicas de lectura con PostgreSQLCómo funciona la replicación en diferentes versiones de RDS para PostgreSQLSupervisión y ajuste del proceso de replicaciónSolución de problemas de réplicas de lectura de RDS para PostgreSQL

Uso de réplicas de lectura para Amazon RDS para PostgreSQL

Puede escalar las lecturas de sus instancias de base de datos de Amazon RDS para PostgreSQL añadiendo réplicas de lectura a las instancias. Al igual que con otros motores de bases de datos de Amazon RDS, RDS para PostgreSQL utiliza los mecanismos de replicación nativos de PostgreSQL para mantener las réplicas de lectura actualizadas con los cambios en la base de datos de origen. Para obtener información general acerca de las réplicas y Amazon RDS, consulte Trabajo con réplicas de lectura de instancias de base de datos.

A continuación, encontrará información específica sobre cómo utilizar réplicas de lectura con RDS para PostgreSQL.

Decodificación lógica en una réplica de lectura

RDS para PostgreSQL admite la replicación lógica desde instancias en espera con PostgreSQL 16.1. Esto le permite crear una decodificación lógica desde una instancia en espera de solo lectura, lo que reduce la carga de la instancia de base de datos principal. Puede lograr una mayor disponibilidad para las aplicaciones que necesitan sincronizar datos en varios sistemas. Esta característica aumenta el rendimiento del almacenamiento de datos y del análisis de datos.

Además, las ranuras de replicación de una instancia en espera determinada mantienen la promoción de esa instancia en espera a una principal. Esto significa que, en caso de que se produzca una conmutación por error de una instancia de base de datos principal o de que se promueva una instancia en espera para ser la nueva instancia principal, las ranuras de replicación se mantendrán y los suscriptores en espera anteriores no se verán afectados.

Creación de una decodificación lógica en una réplica de lectura

  1. Active la replicación lógica: para crear una decodificación lógica en una instancia en espera, debe activar la replicación lógica en la instancia de base de datos de origen y en su réplica física. Para obtener más información, consulte Configuración de réplicas de lectura con PostgreSQL.

    • Para activar la replicación lógica de una instancia de base de datos de RDS para PostgreSQL recién creada: cree un nuevo grupo de parámetros personalizados de base de datos y establezca el parámetro estático rds.logical_replication en 1. A continuación, asocie este grupo de parámetros de base de datos a la instancia de base de datos de origen y a su réplica de lectura física. Para obtener más información, consulte Asociación de un grupo de parámetros de base de datos con una instancia de base de datos.

    • Para activar la replicación lógica de una instancia de base de datos de RDS para PostgreSQL existente: modifique el grupo de parámetros personalizados de base de datos de la instancia de base de datos de origen y su réplica de lectura física para establecer el parámetro estático rds.logical_replication en 1. Para obtener más información, consulte Modificación de parámetros de un grupo de parámetros de base de datos.

    nota

    Debe reiniciar las instancias de base de datos para aplicar estos cambios en los parámetros.

    Puede utilizar la siguiente consulta para comprobar los valores de wal_level y rds.logical_replication en la instancia de base de datos de origen y su réplica de lectura física.

    Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
            
 name                    | setting 
-------------------------+---------
 rds.logical_replication | on
 wal_level               | logical
(2 rows)

  2. Cree una tabla en la base de datos de origen: conéctese a la base de datos de su instancia de base de datos de origen. Para obtener más información, consulte Conexión a una instancia de base de datos que ejecuta el motor de base de datos de PostgreSQL.

    Utilice las siguientes consultas para crear una tabla en la base de datos de origen e insertar valores: 

    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
    Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000

  3. Cree una publicación para la tabla de origen: utilice la siguiente consulta para crear una publicación para la tabla en la instancia de base de datos de origen.

    Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION

    Utilice una consulta SELECT para comprobar los detalles de la publicación que se creó tanto en la instancia de base de datos de origen como en la instancia de réplica de lectura física.

    Postgres=>SELECT * from pg_publication;
             
oid    | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot 
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
 16429 | testpub |    16413 | f            | t         | t         | t         | t           | f
(1 row)

  4. Cree una suscripción a partir de una instancia de réplica lógica: cree otra instancia de base de datos de RDS para PostgreSQL como instancia de réplica lógica. Asegúrese de que la VPC esté configurada correctamente para garantizar que esta instancia de réplica lógica pueda acceder a la instancia de réplica de lectura física. Para obtener más información, consulte VPC de Amazon y Amazon RDS. Si la instancia de base de datos de origen está inactiva, es posible que se produzcan problemas de conectividad y que la instancia principal no envíe los datos a la instancia en espera.

    Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port 
                dbname=source_db_name user=user password=password PUBLICATION testpub;
NOTICE:  created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
    Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE

    Utilice una consulta SELECT para comprobar los detalles de la suscripción en la instancia de la réplica lógica.

    Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
            
oid    | subname | subenabled | subslotname | subpublications 
-------+---------+------------+-------------+-----------------
 16429 | testsub | t          | testsub     | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
 count 
-------
 10000
(1 row)

  5. Inspeccione el estado de la ranura de replicación lógica: solo puede ver la ranura de replicación física en la instancia de base de datos de origen.

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name                                    | slot_type | confirmed_flush_lsn 
---------------------------------------------+-----------+---------------------
 rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical  | 
(1 row)

    Sin embargo, en la instancia de la réplica de lectura, puede ver la ranura de replicación lógica y el valor de confirmed_flush_lsn cambia a medida que la aplicación consume activamente los cambios lógicos.

    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/500002F0
(1 row)
    Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
            
slot_name | slot_type | confirmed_flush_lsn 
-----------+-----------+---------------------
 testsub   | logical   | 0/5413F5C0
(1 row)

Limitaciones de las réplicas de lectura con PostgreSQL

A continuación se indican las limitaciones de las réplicas de lectura de PostgreSQL:

nota

Una réplica de lectura de una instancia de base de datos multi-AZ y single-AZ de RDS para PostgreSQL que ejecute la versión 12 o una posterior de PostgreSQL se reinicia automáticamente para aplicar la rotación de contraseñas durante el período de mantenimiento de 60 a 90 días.

  • Las réplicas de lectura de PostgreSQL son de solo lectura. Aunque una réplica de lectura no es una instancia de base de datos grabable, puede promocionarla para que se convierta en un RDS independiente para una instancia de base de datos de PostgreSQL. Sin embargo, el proceso no es reversible.

  • No puede crear una réplica de lectura a partir de otra réplica de lectura si su instancia de base de datos de RDS para PostgreSQL ejecuta una versión de PostgreSQL anterior a la 14.1. RDS para PostgreSQL solo admite réplicas de lectura en cascada en RDS para PostgreSQL versión 14.1 y versiones superiores. Para obtener más información, consulte Uso de réplicas de lectura en cascada con RDS para PostgreSQL.

  • Si promociona una réplica de lectura de PostgreSQL, se convierte en una instancia de base de datos grabable. Deja de recibir archivos de write-ahead log (WAL, registro de escritura anticipada) de una instancia de base de datos de origen y ya no es una instancia de solo lectura. Puede crear nuevas réplicas de lectura a partir de la instancia de base de datos promocionada como lo hace para cualquier instancia de base de datos de RDS para PostgreSQL. Para obtener más información, consulte Promoción de una réplica de lectura para convertirla en una instancia de base de datos independiente.

  • Si promociona una réplica de lectura de PostgreSQL desde una cadena de replicación (una serie de réplicas de lectura en cascada), cualquier réplica de lectura descendente existente continúa recibiendo archivos WAL de la instancia promocionada, automáticamente. Para obtener más información, consulte Uso de réplicas de lectura en cascada con RDS para PostgreSQL.

  • Si no se están ejecutando transacciones de usuario en la instancia de base de datos de origen, la réplica de lectura de PostgreSQL asociada registra un retardo de replicación de hasta cinco minutos. El retraso de la réplica se calcula como currentTime - lastCommitedTransactionTimestamp, lo que significa que cuando no se procesan transacciones, el valor del retraso de la réplica aumenta durante un período de tiempo hasta que cambia el segmento del registro de escritura anticipada (WAL). De forma predeterminada, RDS para PostgreSQL cambia el segmento WAL cada 5 minutos, lo que da como resultado un registro de transacciones y una disminución del retardo comunicado.

  • No puede activar las copias de seguridad automatizadas para las réplicas de lectura de RDS para PostgreSQL de versiones anteriores a 14.1. Las copias de seguridad automatizadas para réplicas de lectura se admiten únicamente para RDS para PostgreSQL 14.1 y versiones posteriores. Para RDS para PostgreSQL 13 y versiones anteriores, cree una instantánea a partir de una réplica de lectura si desea realizar una copia de seguridad de ella.

  • La Point-in-time recovery (PITR, recuperación en un momento dado) no se admite para las réplicas de lectura. Puede utilizar PITR solo con una instancia principal (escritor), no con una réplica de lectura. Para obtener más información, consulte Restauración de una instancia de base de datos a un momento especificado.

Configuración de réplicas de lectura con PostgreSQL

RDS para PostgreSQL utiliza la replicación de streaming nativa de PostgreSQL para crear una copia de solo lectura de una instancia de base de datos de origen. La instancia de base de datos de réplica de lectura es una réplica física de la instancia de la base de datos de origen creada de forma asíncrona. Se crea mediante una conexión especial que transmite los datos de los registros de escritura previa (WAL) entre la instancia de base de datos de origen y la réplica de lectura. Para obtener más información, consulte Replicación de streaming en la documentación de PostgreSQL.

PostgreSQL transmite de forma asíncrona los cambios de la base de datos a esta conexión segura a medida que se realizan en la instancia de base de datos de origen. Puede cifrar las comunicaciones de las aplicaciones cliente a la instancia de base de datos de origen o cualquier réplica de lectura configurando el parámetro ssl en 1. Para obtener más información, consulte Uso de SSL con una instancia de base de datos PostgreSQL.

PostgreSQL usa un rol de replicación para realizar la replicación en streaming. El rol tiene privilegios, pero no se puede usar para modificar ningún dato. PostgreSQL usa un único proceso para gestionar la replicación.

Puede crear una réplica de lectura de PostgreSQL sin que afecte a las operaciones o usuarios de la instancia de base de datos de origen. Amazon RDS establece los parámetros y los permisos necesarios en la instancia de base de datos de origen y la réplica de lectura sin que afecte al servicio. Se toma una instantánea de la instancia de base de datos de origen, y esta instantánea se utiliza para crear la réplica de lectura. Si elimina la réplica de lectura en algún momento futuro, no se produce ninguna interrupción.

Puede crear hasta 15 réplicas de lectura a partir de una instancia de base de datos de origen dentro de la misma región. A partir de RDS para PostgreSQL 14.1, también puede crear hasta tres niveles de réplica de lectura en una cadena (cascada) a partir de una instancia de base de datos de origen. Para obtener más información, consulte Uso de réplicas de lectura en cascada con RDS para PostgreSQL. En todos los casos, la instancia de base de datos de origen debe tener configuradas copias de seguridad automatizadas. Para ello, debe establecer el periodo de retención de copia de seguridad en su instancia de base de datos en cualquier valor distinto de 0. Para obtener más información, consulte Creación de una réplica de lectura.

Puede crear réplicas de lectura para su instancia de base de datos de RDS para PostgreSQL en la misma Región de AWS que la instancia de base de datos de origen. Esto se denomina replicación dentro de la región. También puede crear réplicas de lectura en una Regiones de AWS diferente de la instancia de base de datos de origen. Esto se denomina replicación entre regiones. Para obtener información sobre la configuración de réplicas de lectura entre regiones, consulte Creación de una réplica de lectura en una Región de AWS distinta. Los diversos mecanismos que admiten el proceso de replicación para dentro de la región y entre regiones difieren ligeramente en función de la versión de RDS para PostgreSQL, como se explica en Cómo funciona la replicación de streaming en diferentes versiones de RDS para PostgreSQL.

Para que la replicación sea eficaz, cada réplica de lectura debe tener la misma cantidad de recursos de computación y de almacenamiento que la instancia de base de datos de origen. Si modifica la escala de la instancia de base de datos de origen, asegúrese de ajustar también la escala de las réplicas de lectura.

Amazon RDS anula los parámetros incompatibles de una réplica de lectura si impiden que la réplica de lectura se inicie. Por ejemplo, supongamos que el valor del parámetro max_connections es mayor en la instancia de base de datos de origen que en la réplica de lectura. En ese caso, Amazon RDS actualiza el parámetro en la réplica de lectura para que tenga el mismo valor que el de la instancia de base de datos de origen.

Las réplicas de lectura de RDS para PostgreSQL tienen acceso a bases de datos externas que están disponibles a través de foreign data wrappers (FDW, envoltorios de datos externos) en la instancia de base de datos de origen. Por ejemplo, suponga que su instancia de base de datos de RDS para PostgreSQL utiliza el envoltorio mysql_fdw para acceder a los datos de RDS para MySQL. Si es así, las réplicas de lectura también pueden acceder a esos datos. Otros FDW admitidos incluyen oracle_fdw, postgres_fdw y tds_fdw. Para obtener más información, consulte Uso de los contenedores de datos externos compatibles para Amazon RDS for PostgreSQL.

Uso de RDS para réplicas de lectura de PostgreSQL con configuraciones Multi-AZ

Puede crear una réplica de lectura a partir de una instancia de base de datos Single-AZ o Multi-AZ. Puede utilizar implementaciones Multi-AZ para mejorar la durabilidad y la disponibilidad de los datos críticos, con una réplica en espera. Una réplica en espera es una réplica de lectura dedicada que puede asumir la carga de trabajo si la base de datos de origen falla. No puede usar su réplica en espera para servir tráfico de lectura. Sin embargo, puede crear réplicas de lectura a partir de una instancia de base de datos Multi-AZ con un tráfico elevado para descargar las consultas de solo lectura. Para obtener más información sobre las implementaciones Multi-AZ, consulte Implementaciones de instancias de base de datos Multi-AZ.

Si la instancia de base de datos de origen de una implementación Multi-AZ conmuta por error, las réplicas de lectura asociadas cambian para utilizar la instancia en espera (ahora principal) como origen de replicación. Es posible que las réplicas de lectura deban reiniciarse, según la versión de RDS para PostgreSQL, de la siguiente manera:

  • PostgreSQL 13 y versiones superiores: no es obligatorio reiniciar. Las réplicas de lectura se sincronizan automáticamente con el nuevo elemento principal. Sin embargo, en algunos casos, la aplicación cliente podría almacenar en caché los detalles del Domain Name Service (DNS, servicio de nombres de dominio) de las réplicas de lectura. Si es así, configure el valor de time-to-live (TTL, tiempo de vida) en menos de 30 segundos. Esto impide que la réplica de lectura se mantenga en una dirección IP obsoleta (y, por lo tanto, impide que se sincronice con el nuevo elemento principal). Para obtener más información sobre esta y otras prácticas recomendadas, consulte Directrices operativas básicas de Amazon RDS.

  • PostgreSQL 12 y todas las versiones anteriores: las réplicas de lectura se reinician automáticamente después de una conmutación por error en la réplica en espera porque la espera (ahora principal) tiene una dirección IP y un nombre de instancia diferente. El reinicio sincroniza la réplica de lectura con el nuevo elemento principal.

Para obtener más información sobre la conmutación por error, consulte Proceso de conmutación por error para Amazon RDS. Para obtener más información sobre cómo funcionan las réplicas de lectura en una implementación Multi-AZ, consulte Trabajo con réplicas de lectura de instancias de base de datos.

Para proporcionar soporte de conmutación por error para una réplica de lectura, puede crear la réplica de lectura como una instancia de base de datos Multi-AZ para que Amazon RDS cree una espera de su réplica en otra zona de disponibilidad (AZ). La creación de su réplica de lectura como instancia de base de datos Multi-AZ es independiente de si la base de datos de origen es una instancia de base de datos Multi-AZ.

Uso de réplicas de lectura en cascada con RDS para PostgreSQL

A partir de la versión 14.1, RDS para PostgreSQL admite réplicas de lectura en cascada. Con réplicas de lectura en cascada, puede escalar las lecturas sin agregar sobrecarga a su instancia de base de datos de RDS para PostgreSQL de origen. La instancia de base de datos de origen no envía las actualizaciones del registro WAL a cada réplica de lectura. En cambio, cada réplica de lectura de una serie en cascada envía actualizaciones de registro WAL a la siguiente réplica de lectura de la serie. Esto reduce la carga de la instancia de base de datos de origen.

Con réplicas de lectura en cascada, la instancia de base de datos de RDS para PostgreSQL envía datos WAL a la primera réplica de lectura de la cadena. Esa réplica de lectura envía datos WAL a la segunda réplica de la cadena, etc. El resultado final es que todas las réplicas de lectura de la cadena tienen los cambios de la instancia de base de datos de RDS para PostgreSQL, pero sin la sobrecarga únicamente en la instancia de base de datos de origen.

Puede crear una serie de hasta tres réplicas de lectura en cadena a partir de una instancia de base de datos RDS para PostgreSQL de origen. Por ejemplo, suponga que tiene una instancia de base de datos de RDS para PostgreSQL 14.1, rpg-db-main. Puede hacer lo siguiente:

  • A partir de rpg-db-main, cree la primera réplica de lectura de la cadena, read-replica-1.

  • A continuación, a partir de read-replica-1, cree la siguiente réplica de lectura de la cadena, read-replica-2.

  • Por último, a partir de read-replica-2, cree la tercera réplica de lectura de la cadena, read-replica-3.

No se puede crear otra réplica de lectura más allá de esta tercera réplica de lectura en cascada de la serie para rpg-db-main. Una serie completa de instancias desde una instancia de base de datos de origen de RDS para PostgreSQL hasta el final de una serie de réplicas de lectura en cascada puede constar de cuatro instancias de base de datos como máximo.

Para que las réplicas de lectura en cascada funcionen, active las copias de seguridad automáticas en su RDS para PostgreSQL. Cree primero la réplica de lectura y, a continuación, active las copias de seguridad automáticas en la instancia de base de datos de RDS para PostgreSQL. El proceso es el mismo que para otros motores de base de datos de Amazon RDS. Para obtener más información, consulte Creación de una réplica de lectura.

Al igual que con cualquier réplica de lectura, puede promocionar una réplica de lectura que forma parte de una cascada. La promoción de una réplica de lectura desde dentro de una cadena de réplicas de lectura elimina esa réplica de la cadena. Por ejemplo, suponga que desea quitar parte de la carga de trabajo de su Instancia de base de datos de rpg-db-main a una nueva instancia para que la utilice únicamente el departamento de contabilidad. Tomando la cadena de tres réplicas de lectura del ejemplo, decide promocionar read-replica-2. La cadena se ve afectada de la siguiente manera:

  • Promover read-replica-2 la elimina de la cadena de replicación.

    • Ahora es una instancia de base de datos de lectura o escritura completa.

    • Continúa replicando en read-replica-3, tal como hacía antes de la promoción.

  • Su rpg-db-main sigue replicándose en read-replica-1.

Para obtener más información acerca de la promoción de réplicas de lectura, consulte Promoción de una réplica de lectura para convertirla en una instancia de base de datos independiente.

nota

Para las réplicas de lectura en cascada, RDS para PostgreSQL admite 15 réplicas de lectura para cada instancia de base de datos de origen en el primer nivel de replicación y 5 réplicas de lectura para cada instancia de base de datos de origen en el segundo y tercer nivel de replicación.

Cómo funciona la replicación de streaming en diferentes versiones de RDS para PostgreSQL

Como se discute en Configuración de réplicas de lectura con PostgreSQL, RDS para PostgreSQL utiliza el protocolo de replicación de streaming nativo de PostgreSQL para enviar datos WAL desde la instancia de base de datos de origen. Envía datos WAL de origen a réplicas de lectura tanto para réplicas de lectura dentro de la región como entre regiones. Con la versión 9.4, PostgreSQL introdujo slots de replicación física como mecanismo de soporte para el proceso de replicación.

Una slot de replicación física impide que una instancia de base de datos de origen elimine los datos WAL antes de que todas las réplicas de lectura los consuman. Cada réplica de lectura tiene su propia slot física en la instancia de base de datos de origen. La slot realiza un seguimiento del WAL más antiguo (por número de secuencia lógica, LSN) que podría necesitar la réplica. Después de que todas las slots y conexiones de base de datos hayan progresado más allá de un WAL (LSN) determinado, ese LSN se convierte en candidato para su eliminación en el siguiente punto de control.

Amazon RDS utiliza Amazon S3 para archivar datos WAL. En las réplicas de lectura dentro de la región, puede utilizar estos datos archivados para recuperar la réplica de lectura cuando sea necesario. Un ejemplo de cuándo podría hacerse es si la conexión entre la base de datos de origen y la réplica de lectura se interrumpe por cualquier motivo.

En la tabla siguiente, encontrará un resumen de las diferencias entre las versiones de PostgreSQL y los mecanismos de soporte para dentro de la región y entre regiones que utiliza RDS para PostgreSQL.

En región Entre regiones
PostgreSQL 14.1 and higher versions

  • Slots de replicación

  • Archivo de Amazon S3

  • Slots de replicación
PostgreSQL 13 and lower versions

  • Archivo de Amazon S3

  • Slots de replicación

Para obtener más información, consulte Supervisión y ajuste del proceso de replicación.

Descripción de los parámetros que controlan la replicación de PostgreSQL

Los siguientes parámetros afectan al proceso de replicación y determinan qué tal se actualizan las réplicas de lectura con la instancia de base de datos de origen:

max_wal_senders

El parámetro max_wal_senders especifica el número máximo de conexiones que la instancia de base de datos de origen puede admitir al mismo tiempo a través del protocolo de replicación de streaming. El valor predeterminado de RDS para PostgreSQL 13 y las versiones posteriores es 20. Este parámetro debe establecerse en ligeramente superior al número real de réplicas de lectura. Si este parámetro se establece demasiado bajo para el número de réplicas de lectura, la replicación se detiene.

Para obtener más información, consulte see max_wal_senders enla documentación de PostgreSQL.

wal_keep_segments

El parámetro wal_keep_segments especifica el número de archivos de registro de escritura anticipada (WAL) que mantiene la instancia de base de datos de origen en el directorio pg_wal. La configuración predeterminada es 32.

Si wal_keep_segments no tiene un valor lo suficientemente grande para su implementación, una réplica de lectura puede quedarse tan rezagada que se detenga la replicación en streaming. Si es así, Amazon RDS genera un error de replicación e inicia la recuperación en la réplica de lectura. Para ello, reproduce los datos WAL archivados de la instancia de base de datos de origen desde Amazon S3. Este proceso de recuperación continúa hasta que la réplica de lectura reduce el retraso lo suficiente para seguir con la replicación en streaming. Puede ver este proceso en acción tal como lo captó el registro de PostgreSQL en Ejemplo: Cómo se recupera una réplica de lectura de las interrupciones de la replicación.

nota

En la versión 13 de PostgreSQL, el parámetro wal_keep_segments se denomina wal_keep_size. Tiene el mismo propósito que wal_keep_segments, pero su valor predeterminado está en megabytes (MB) (2048 MB) en lugar del número de archivos. Para obtener más información, consulte wal_keep_segments y wal_keep_size en la documentación de PostgreSQL.

max_slot_wal_keep_size

El parámetro max_slot_wal_keep_size controla la cantidad de datos WAL que conserva la instancia de base de datos de RDS para PostgreSQL en el directorio pg_wal para servir slots. Este parámetro se utiliza para configuraciones que utilizan slots de replicación. El valor predeterminado para este parámetro es -1, lo que significa que no hay límite en cuanto a la cantidad de datos WAL que se conservan en la instancia de base de datos de origen. Para obtener información sobre cómo supervisar las slots de replicación, consulte Supervisión de las slots de replicación de su instancia de base de datos de RDS para PostgreSQL.

Para obtener más información sobre este parámetro, consulte max_slot_wal_keep_size en la documentación de PostgreSQL.

Siempre que se interrumpe el flujo que proporciona los datos de WAL a una réplica de lectura, PostgreSQL cambia al modo de recuperación. Restaura la réplica de lectura mediante datos de WAL archivados de Amazon S3 o mediante el uso de datos de WAL asociados a la ranura de replicación. Cuando finaliza este proceso, PostgreSQL restablece la replicación en streaming.

Ejemplo: Cómo se recupera una réplica de lectura de las interrupciones de la replicación

En el siguiente ejemplo, encontrará los detalles del registro que muestran el proceso de recuperación de una réplica de lectura. El ejemplo procede de una instancia de base de datos de RDS para PostgreSQL que ejecuta la versión 12.9 de PostgreSQL en la misma Región de AWS que la base de datos de origen, por lo que no se utilizan slots de replicación. El proceso de recuperación es el mismo para otras instancias de base de datos de PostgreSQL que ejecutan PostgreSQL anterior a la versión 14.1 con réplicas de lectura dentro de la región.

Cuando la réplica de lectura perdió el contacto con la instancia de base de datos de origen, Amazon RDS registra el problema en el registro como el mensaje FATAL: could not receive data from WAL stream, junto con ERROR: requested WAL segment ... has already been removed. Como se muestra en la línea en negrita, Amazon RDS recupera la réplica reproduciendo un archivo WAL archivado. 

2014-11-07 19:01:10 UTC::@:[23180]:DEBUG:  switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR:  requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG:  restored log file "000000010000001A000000D3" from archive

Cuando Amazon RDS reproduce suficientes datos de WAL archivados en la réplica para ponerse al corriente, el streaming a la réplica de lectura comienza de nuevo. Cuando se reanuda el streaming, Amazon RDS escribe una entrada en el archivo de registro, similar a la siguiente.

2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1

Configuración de los parámetros que controlan la memoria compartida

Los parámetros que establezca determinan el tamaño de la memoria compartida para rastrear los identificadores de las transacciones, los bloqueos y las transacciones preparadas. La estructura de la memoria compartida de una instancia en espera debe ser igual o mayor que la de una instancia principal. Esto garantiza que la primera no se quede sin memoria compartida durante la recuperación. Si los valores de los parámetros de la réplica son inferiores a los valores de los parámetros de la principal, Amazon RDS ajustará automáticamente los parámetros de la réplica y reiniciará el motor.

Los parámetros afectados son:

  • max_connections

  • max_worker_processes

  • max_wal_senders

  • max_prepared_transactions

  • max_locks_per_transaction

Para evitar que RDS reinicie las réplicas por falta de memoria, se recomienda aplicar los cambios de los parámetros como un reinicio progresivo en cada réplica. Al configurar los parámetros, debe aplicar las siguientes reglas:

  • Aumentar los valores de los parámetros:

    • En primer lugar, siempre debe aumentar los valores de los parámetros de todas las réplicas de lectura y realizar un reinicio progresivo de todas las réplicas. A continuación, aplique los cambios de los parámetros a la instancia principal y reinicie.

  • Disminuir los valores de los parámetros:

    • En primer lugar, debe reducir los valores de los parámetros de la instancia principal y llevar a cabo un reinicio. A continuación, aplique los cambios de los parámetros a todas las réplicas de lectura asociadas y lleve a cabo un reinicio progresivo.

Supervisión y ajuste del proceso de replicación

Le recomendamos encarecidamente que supervise de forma rutinaria su instancia de base de datos de RDS para PostgreSQL y réplicas de lectura. Debe asegurarse de que las réplicas de lectura se mantengan al día con los cambios en la instancia de base de datos de origen. Amazon RDS recupera de forma transparente sus réplicas de lectura cuando se producen interrupciones en el proceso de replicación. Sin embargo, es mejor evitar la necesidad de recuperarse en absoluto. La recuperación mediante slots de replicación es más rápida que utilizar el archivo de Amazon S3, pero cualquier proceso de recuperación puede afectar al rendimiento de lectura.

Para determinar qué tal se mantienen las réplicas de lectura con la instancia de base de datos de origen, puede hacer lo siguiente:

  • Compruebe la cantidad de ReplicaLag entre la instancia de base de datos de origen y las réplicas. El retardo de réplica es la cantidad de retardo, en segundos, que una réplica de lectura acumula con respecto a la instancia de base de datos de origen. Esta métrica informa del resultado de la siguiente consulta.

    SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";

    El retraso de réplica indica qué tal se mantiene una réplica de lectura con la instancia de base de datos de origen. Es la cantidad de latencia entre la instancia de base de datos de origen y una instancia de lectura específica. Un valor elevado para el retraso de réplica puede indicar una discrepancia entre las clases de instancia de base de datos o los tipos de almacenamiento (o ambos) utilizados por la instancia de base de datos de origen y sus réplicas de lectura. La clase de instancia de base de datos y los tipos de almacenamiento de la instancia de origen de base de datos y todas las réplicas de lectura deben ser iguales.

    El retraso de la réplica también puede ser el resultado de problemas de conexión intermitentes. Puede monitorizar el retardo de replicación en Amazon CloudWatch mediante la visualización de la métrica ReplicaLag de Amazon RDS. Para obtener más información sobre ReplicaLag y otras métricas de Amazon RDS, consulte Métricas de Amazon CloudWatch para Amazon RDS.

  • Consulte el registro de PostgreSQL para obtener información que puede utilizar para ajustar la configuración. En cada punto de control, el registro de PostgreSQL captura el número de archivos de registro de transacciones reciclados, como se muestra en el siguiente ejemplo.

    2014-11-07 19:59:35 UTC::@:[26820]:LOG:  checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s

    Puede utilizar esta información para averiguar cuántos archivos de transacciones se reciclarán en un periodo de tiempo determinado. Puede cambiar la configuración de wal_keep_segments si es necesario. Suponga, por ejemplo, que el registro de PostgreSQL checkpoint complete muestra 35 recycled durante un intervalo de 5 minutos. En este caso, el valor predeterminado de wal_keep_segments de 32 no es suficiente para seguir el ritmo de la actividad de streaming, con lo que debe aumentar el valor de este parámetro.

  • Utilice Amazon CloudWatch para supervisar las métricas que pueden predecir problemas de replicación. En lugar de analizar el registro de PostgreSQL directamente, puede utilizar Amazon CloudWatch para comprobar las métricas recopiladas. Por ejemplo, puede comprobar el valor de la métrica TransactionLogsGeneration para ver cuántos datos WAL está generando la instancia de base de datos de origen. En algunos casos, la carga de trabajo de la instancia de base de datos podría generar una gran cantidad de datos WAL. De ser así, puede que tenga que cambiar la clase de la instancia de base de datos de origen y de las réplicas de lectura. El uso de una clase de instancia con un rendimiento de red alto (10 Gbps) puede reducir el retraso de las réplicas.

Supervisión de las slots de replicación de su instancia de base de datos de RDS para PostgreSQL

Todas las versiones de RDS para PostgreSQL utilizan slots de replicación para réplicas de lectura entre regiones. RDS para PostgreSQL 14.1 y versiones posteriores utilizan slots de replicación para réplicas de lectura en región. Las réplicas de lectura dentro de la región también utilizan Amazon S3 para archivar datos WAL. En otras palabras, si la instancia de base de datos y las réplicas de lectura ejecutan PostgreSQL 14.1 o superior, las slots de replicación y los archivos de Amazon S3 están disponibles para recuperar la réplica de lectura. La recuperación de una réplica de lectura mediante su slot de replicación es más rápida que la recuperación del archivo Amazon S3. Por lo tanto, le recomendamos que supervise las slots de replicación y las métricas relacionadas.

Puede ver las slots de replicación en sus instancias de base de datos de RDS para PostgreSQL consultando la vista de pg_replication_slots, de la siguiente manera.

postgres=> SELECT * FROM pg_replication_slots;
slot_name                  | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 |        | physical  |        |          | f         | t      |      13194 |      |              | 23/D8000060 |                     | reserved   |               | f
(1 row)

El wal_status del valor reserved significa que la cantidad de datos WAL que mantiene la slot se encuentra dentro de los límites del parámetro max_wal_size. En otras palabras, la slot de replicación tiene el tamaño adecuado. Otros posibles valores de los estados son los siguientes:

  • extended: la slot supera el ajuste max_wal_size, pero los datos de WAL se conservan.

  • unreserved: la slot ya no tiene todos los datos WAL necesarios. Parte se eliminará en el siguiente punto de control.

  • lost: se han eliminado algunos datos de WAL obligatorios. La slot ya no se puede utilizar.

Los estados unreserved y lost de wal_status solo se ven cuando max_slot_wal_keep_size no es negativo.

La vista de pg_replication_slots muestra el estado actual de las slots de replicación. Para evaluar el rendimiento de sus slots de replicación, puede utilizar Amazon CloudWatch y supervisar las siguientes métricas:

  • OldestReplicationSlotLag: muestra la ranura con más retraso, es decir, la más alejada del elemento principal. Este retraso se puede asociar a la réplica de lectura pero también a la conexión.

  • TransactionLogsDiskUsage: muestra cuánto almacenamiento se usa para los datos de WAL. Cuando una réplica de lectura se retrasa significativamente, el valor de esta métrica puede aumentar sustancialmente.

Para obtener más información acerca del uso de Amazon CloudWatch y las métricas de RDS para PostgreSQL, consulte Supervisión de métricas de Amazon RDS con Amazon CloudWatch. Para obtener más información sobre cómo supervisar la replicación de streaming en sus instancias de base de datos de RDS para PostgreSQL, consulte Best practices for Amazon RDS PostgreSQL replication en AWSDatabase Blog.

Solución de problemas de réplicas de lectura de RDS para PostgreSQL

A continuación, encontrará ideas para solucionar algunos problemas comunes de las réplicas de lectura de RDS para PostgreSQL.

Finalice la consulta que provoca el retardo de la réplica de lectura

Las transacciones activas o inactivas en un estado de transacción que se estén ejecutando durante mucho tiempo en la base de datos pueden interferir con el proceso de replicación de WAL y, por lo tanto, aumentar el retardo de la replicación. Por lo tanto, asegúrese de supervisar el tiempo de ejecución de estas transacciones con la vista pg_stat_activity de PostgreSQL.

Ejecute una consulta en la instancia principal similar a la siguiente para encontrar el ID de proceso (PID) de la consulta que lleva mucho tiempo ejecutándose: 


SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
                        
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,* 
FROM  pg_stat_activity 
WHERE state  = 'idle in transaction'
AND   xact_start is not null
ORDER BY 1 DESC;

Tras identificar el PID de la consulta, puede optar por finalizarla.

Ejecute una consulta en la instancia principal similar a la siguiente para finalizar la consulta que lleva mucho tiempo ejecutándose:

SELECT pg_terminate_backend(PID);