Solución de problemas de Amazon Aurora - Amazon Aurora
No puede conectarse a la instancia de base de datos de Problemas de seguridadRestablecimiento de la contraseña del propietario de la instancia de base de datosInterrupción o reinicio de una instancia de base de datosLos cambios de parámetros no surten efectoProblemas de memoria que se puede liberar de AuroraProblemas de replicación de Aurora MySQL

Solución de problemas de Amazon Aurora

Utilice las siguientes secciones como ayuda para solucionar los problemas que puedan presentarse con instancias de base de datos en Amazon RDS y Amazon Aurora.

Para obtener información sobre los problemas de depuración del uso de la API de Amazon RDS, consulte Solución de problemas de aplicaciones en Aurora.

No puede conectarse a la instancia de base de datos de Amazon RDS

Cuando no puede conectarse a una instancia de base de datos, estas suelen ser las causas habituales:

  • Reglas de entrada: las reglas de acceso impuestas por el firewall local y las direcciones IP a las que autorizó el acceso a la instancia de base de datos podrían no coincidir. Lo más probable es que el problema se encuentre en las reglas de entrada de su grupo de seguridad.

    De forma predeterminada, las instancias de base de datos no permiten el acceso. El acceso se concede a través de un grupo de seguridad asociado a la VPC que permite el tráfico de entrada y salida de la instancia de base de datos. Si es necesario, agregue reglas de entrada y salida al grupo de seguridad según su situación particular. Puede especificar una dirección IP, un rango de direcciones IP u otro grupo de seguridad de VPC.

    nota

    Al agregar una nueva regla de entrada, puede elegir My IP (Mi IP) en Source (Origen) para permitir el acceso a la instancia de base de datos desde la dirección IP detectada en su navegador.

    Para obtener más información acerca de la configuración de grupos de seguridad, consulte Proporcionar acceso al clúster de base de datos en la VPC mediante la creación de un grupo de seguridad.

    nota

    La conexiones de cliente desde direcciones IP en el rango 169.254.0.0/16 no están permitidas. Este es el rango de direccionamiento IP privado automático (APIPA), que se utiliza para direccionamiento de enlace local.

  • Accesibilidad pública: para conectarse a la instancia de base de datos desde fuera de la VPC, por ejemplo mediante una aplicación cliente, la instancia debe tener asignada una dirección IP pública.

    Para que la instancia sea accesible públicamente, modifíquela y elija Yes (Sí) en Public accessibility (Accesibilidad pública). Para obtener más información, consulte Cómo ocultar un clúster de base de datos en una VPC desde Internet..

  • Puerto: el puerto que especificó cuando creó la instancia de base de datos no puede usarse para enviar o recibir comunicaciones debido a las restricciones del firewall local. Para determinar si su red permite el uso del puerto especificado para comunicación de entrada y salida, consulte al administrador de red.

  • Disponibilidad: en el caso de una instancia de base de datos recién creada, esta tendrá el estado creating hasta que esté lista para el uso. Cuando el estado cambie a available, podrá conectarse a la instancia de base de datos. Dependiendo del tamaño de la instancia de base de datos, es posible que la instancia tarde hasta 20 minutos en estar disponible.

  • Gateway de Internet: para que una instancia de base de datos sea accesible públicamente, las subredes del grupo de subredes de base de datos deben tener una gateway de Internet.

    Para configurar una gateway de Internet para una subred

    1. Inicie sesión en 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 Databases (Bases de datos) y, a continuación, elija el nombre de la instancia de base de datos.

    3. En la pestaña Connectivity & security (Conectividad y seguridad), anote los valores del ID de la VPC en VPC y el ID de la subred en Subnets (Subredes).

    4. Abra la consola de Amazon VPC en https://console.aws.amazon.com/vpc/.

    5. En el panel de navegación, elija Internet Gateways (Gateways de Internet). Verifique que hay una gateway de Internet adjunta a la VPC. Si no la hay, elija Create Internet Gateway (Crear gateway de Internet) para crear una gateway de Internet. Seleccione la gateway de Internet y, después, elija Attach to VPC (Conectar a la VPC) y siga las instrucciones para adjuntarla a la VPC.

    6. En el panel de navegación, elija Subnets (Subredes) y, a continuación, seleccione la suya.

    7. En la pestaña Route Table (Tabla de ruteo), verifique que haya una ruta con 0.0.0.0/0 como destino y la gateway de Internet de la VPC como destino.

      Si está conectando con la instancia utilizando la dirección IPv6, verifique que existe una ruta para todo el tráfico IPv6 (::/0) que apunte a la gateway de Internet. De lo contrario, realice lo siguiente:

      1. Elija el ID de la tabla de ruteo (rtb-xxxxxxxx) para navegar a la tabla de ruteo.

      2. En la pestaña Routes (Rutas), elija Edit routes (Editar rutas). Elija Add route (Añadir ruta) y utilice 0.0.0.0/0 como destino y la gateway de Internet como objetivo.

        Para IPv6, elija Add route (Añadir ruta) y utilice ::/0 como destino y la gateway de Internet como objetivo.

      3. Elija Save routes (Guardar rutas).

      Además, si intenta conectarse al punto de conexión IPv6, asegúrese de que el rango de direcciones IPv6 del cliente esté autorizado para conectarse a la instancia de base de datos.

    Para obtener más información, consulte Uso de una clúster de base de datos en una VPC.

Comprobar una conexión a una instancia de base de datos

Puede comprobar la conexión a una instancia de base de datos con las herramientas habituales de Microsoft Windows o Linux.

Desde un terminal de Linux o Unix, puede comprobar la conexión escribiendo lo siguiente. Sustituya DB-instance-endpoint por el punto de conexión y port por el puerto de la instancia de base de datos.

nc -zv DB-instance-endpoint port

Por ejemplo, a continuación se muestra un comando de ejemplo y el valor de retorno.

nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299

  Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

Los usuarios de Windows pueden usar Telnet para comprobar la conexión a una instancia de base de datos. Las acciones de Telnet solo se admiten para la comprobación de la conexión. Si la conexión es correcta, la acción no devuelve ningún mensaje. Si la conexión no es correcta, recibe un mensaje de error como el siguiente.

C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819

  Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
  connection to the host, on port 819: Connect failed

Si las acciones de Telnet indican que la conexión es correcta, el grupo de seguridad se ha configurado correctamente.

nota

Amazon RDS no acepta el tráfico del protocolo de mensaje de control de Internet (ICMP), ping incluido.

Solución de problemas de autenticación de conexión

En algunos casos, puede conectarse a su instancia de base de datos, pero recibe errores de autenticación. En estos casos, sería aconsejable restablecer la contraseña de usuario principal para la instancia de base de datos. Puede hacerlo modificando la instancia de RDS.

Problemas de seguridad de Amazon RDS

Para evitar problemas de seguridad, no utilice nunca la contraseña ni la dirección de correo electrónico del usuario raíz de Cuenta de AWS en una cuenta de usuario. El procedimiento recomendado consiste en utilizar el usuario raíz para crear usuarios y asignarlos a cuentas de usuario de base de datos. También puede utilizar el usuario raíz para crear, si fuera necesario, otras cuentas de usuario.

Para obtener información sobre cómo crear usuarios, consulte Creación de un usuario de IAM en la Cuenta de AWS. Para obtener información sobre cómo crear usuarios en AWS IAM Identity Center, consulte Manage identities in IAM Identity Center (Administrar identidades en el Centro de identidades de IAM).

Mensaje de error "No se pudieron recuperar los atributos de cuenta. Determinadas funciones de la consola pueden estar deterioradas".

Puede obtener este error por varias razones. Puede deberse a que la cuenta no tiene permisos o a que no se ha configurado correctamente. Si la cuenta es nueva, es posible que no haya esperado a que esté lista. Si se trata de una cuenta existente, podría carecer de permisos en sus políticas de acceso para realizar determinadas acciones, como crear una instancia de base de datos. Para solucionar este problema, el administrador debe proporcionar los roles necesarios a su cuenta. Para obtener más información, consulte la documentación de IAM.

Restablecimiento de la contraseña del propietario de la instancia de base de datos

Si se bloquea el clúster de base de datos, puede iniciar sesión como usuario maestro. A continuación, puede restablecer las credenciales para otros usuarios o roles administrativos. Si no puede iniciar sesión como usuario maestro, el propietario de la AWS cuenta puede restablecer la contraseña del usuario maestro. Para obtener información detallada sobre las cuentas administrativas o roles que puede tener que restablecer, consulte Privilegios de la cuenta de usuario maestro.

La contraseña de la instancia de base de datos se puede cambiar por medio de la consola de Amazon RDS, el comando modify-db-instance de la AWS CLI o la operación de la API ModifyDBInstance. Para obtener información sobre la modificación de una instancia de base de datos en un clúster de base de datos, consulte Modificación de una instancia de base de datos en un clúster de base de datos.

Interrupción o reinicio de una instancia de base de datos de Amazon RDS

Cuando se reinicia una instancia de base de datos puede producirse una interrupción de la instancia de base de datos. También puede producirse cuando dicha instancia se pone en un estado que impide el acceso a ella y cuando se reinicia la base de datos. Puede producirse un reinicio al al reiniciar de forma manual su instancia de base de datos. Un reinicio también puede ocurrir cuando se cambia una configuración de la instancia de la base de datos que requiere un reinicio antes de que pueda surtir efecto.

El reinicio de una instancia de base de datos se produce cuando cambia una configuración que exige un reinicio o cuando efectúa un reinicio manualmente. El reinicio puede producirse inmediatamente si cambia una configuración y solicita que el cambio surta efecto de inmediato. O puede ocurrir durante el período de mantenimiento de la instancia de base de datos.

El reinicio de la instancia de base de datos se produce inmediatamente en una de las siguientes situaciones:

  • Cambie el periodo de retención de copia de seguridad de una instancia de base de datos de cero a un valor distinto de cero o de un valor distinto de cero a cero. A continuación, configure Apply Immediately (Aplicar inmediatamente) en true.

  • El usuario cambia la clase de la instancia de base de datos y Apply Immediately (Aplicar inmediatamente) se establece en true.

El reinicio de la instancia de base de datos se produce durante el período de mantenimiento en una de las siguientes situaciones:

  • El usuario cambia el período de retención de copia de seguridad de una instancia de base de datos, de cero a un valor distinto de cero o viceversa, y Apply Immediately (Aplicar inmediatamente) se establece en false.

  • El usuario cambia la clase de la instancia de base de datos y Apply Immediately (Aplicar inmediatamente) se establece en false.

Cuando se cambia un parámetro estático en un grupo de parámetros de base de datos, el cambio no surtirá efecto hasta que se reinicie la instancia de base de datos asociada al grupo. El cambio requiere un reinicio manual. La instancia de base de datos no se reinicia automáticamente durante el período de mantenimiento.

Los cambios de parámetros de base de datos de Amazon RDS no surten efecto

En algunos casos, es posible que cambie un parámetro en un grupo de parámetros de base de datos, pero no vea que los cambios surtan efecto. Si es así, es probable que necesite reiniciar la instancia de base de datos asociada con el grupo de parámetros de base de datos. Cuando se cambia un parámetro dinámico, el cambio surte efecto inmediatamente. Cuando se cambia un parámetro estático, el cambio no surtirá efecto hasta que reinicie la instancia de base de datos asociada al grupo de parámetros.

Puede reiniciar una instancia de base de datos a través de la consola de RDS. O bien, puede llamar explícitamente a la operación de la API RebootDBInstance. Puede reiniciar sin conmutación por error si la instancia de base de datos se encuentra en una implementación Multi-AZ. El requisito de reiniciar la instancia de base de datos asociada después de cambiar un parámetro estático ayuda a mitigar el riesgo de que una configuración errónea del parámetro afecte a una llamada a la API. Un ejemplo sería llamar a ModifyDBInstance para cambiar la clase de instancia de base de datos. Para obtener más información, consulte Modificación de los parámetros de un grupo de parámetros de base de datos en Amazon Aurora.

Problemas de memoria que se puede liberar en Amazon Aurora

La memoria que se puede liberar es el total de memoria de acceso aleatorio (RAM) de una instancia de base de datos que se puede poner a disposición del motor de base de datos. Es la suma de la memoria libre del sistema operativo (SO) y de la memoria intermedia y la memoria caché de página disponibles. El motor de base de datos utiliza la mayor parte de la memoria del host, pero los procesos del sistema operativo también utilizan algo de RAM. La memoria actualmente asignada al motor de base de datos o que utilizan los procesos del sistema operativo no está incluida en la memoria que se puede liberar. Cuando el motor de base de datos se queda sin memoria, la instancia de base de datos puede utilizar el espacio temporal que normalmente se usa para el almacenamiento en búfer y en caché. Como se mencionó anteriormente, este espacio temporal se incluye en la memoria que se puede liberar.

La métrica FreeableMemory de Amazon CloudWatch se utiliza para supervisar la memoria que se puede liberar. Para obtener más información, consulte Información general de la supervisión de métricas en Amazon Aurora.

Si su instancia de base de datos se queda constantemente sin memoria que se pueda liberar o utiliza espacio de intercambio, considere la psibilidad de escalar verticalmente a una clase de instancia de base de datos más grande. Para obtener más información, consulte Clases de instancia de base de datos de Amazon Aurora.

También puede cambiar la configuración de memoria. Por ejemplo, en Aurora MySQL , podría ajustar el tamaño del parámetro innodb_buffer_pool_size. Este parámetro está establecido de forma predeterminada al 75 % de la memoria física. Para obtener más consejos sobre la solución de problemas de MySQL, consulte How can I troubleshoot low freeable memory in an Amazon RDS para MySQL database? (¿Cómo puedo solucionar un problema de poca memoria que se puede liberar en una base de datos de Amazon RDS para MySQL?).

En el caso de Aurora Serverless v2, FreeableMemory representa la cantidad de memoria sin utilizar que está disponible cuando la instancia de base de datos de Aurora Serverless v2 se escala a su capacidad máxima. Puede tener la instancia reducida verticalmente a una capacidad relativamente baja, pero sigue notificando un valor alto para FreeableMemory, porque la instancia se puede escalar verticalmente. Esa memoria no está disponible en este momento, pero puede obtenerla si la necesita.

Para cada unidad de capacidad de Aurora (ACU) cuya capacidad actual esté por debajo de la capacidad máxima, FreeableMemory aumenta este valor aproximadamente 2 GiB. Por lo tanto, esta métrica no se aproxima a cero hasta que la instancia de base de datos se amplía al máximo posible.

Si esta métrica se aproxima a un valor de 0, la instancia de base de datos se ha escalado al punto máximo posible. Se acerca al límite de la memoria disponible. Considere aumentar la configuración máxima de ACU para el clúster. Si esta métrica se aproxima a un valor de 0 en una instancia de base de datos de lector, considere agregar instancias de base de datos de lector adicionales al clúster. De esta forma, puede distribuir la parte de solo lectura entre más instancias de base de datos, reduciendo el uso de memoria en cada instancia de base de datos de lector. Para obtener más información, consulte Métricas importantes de Amazon CloudWatch para Aurora Serverless v2.

Para Aurora Serverless v1, puede cambiar el intervalo de capacidad para utilizar más ACU. Para obtener más información, consulte Modificación de un clúster de bases de datos de Aurora Serverless v1.

Problemas de replicación de Amazon Aurora MySQL

Algunos problemas de replicación de MySQL también se aplican a Aurora MySQL. Puede diagnosticar y corregir estos problemas.

Diagnóstico y resolución de retardos entre réplicas de lectura

Después de crear una réplica de lectura de MySQL y de que dicha réplica esté disponible, Amazon RDS replica en primer lugar los cambios realizados en la instancia de base de datos de origen desde el momento en que se inició la operación de creación de réplica de lectura. Durante esta fase, el retraso de replicación para la réplica de lectura es mayor que 0. También puede monitorizar este retardo en Amazon CloudWatch viendo la métrica AuroraBinlogReplicaLag de Amazon RDS.

La métrica AuroraBinlogReplicaLag indica el valor del campo Seconds_Behind_Master del comando SHOW REPLICA STATUS de MySQL. Para obtener más información, consulte HOW REPLICA STATUS Statement (Instrucción HOW REPLICA STATUS) en la documentación de MySQL.

Cuando la métrica AuroraBinlogReplicaLag llegue a 0, la réplica estará funcionando al mismo ritmo que la instancia de base de datos de origen. Si la métrica AuroraBinlogReplicaLag devuelve -1, la replicación podría no estar activa. Para solucionar problemas de error de replicación, consulte Diagnóstico y solución de un error de replicación de lectura de MySQL. Un valor AuroraBinlogReplicaLag de -1 también puede significar que el valor Seconds_Behind_Master no se puede determinar o es NULL.

nota

Versiones anteriores de Aurora MySQL utilizaban SHOW SLAVE STATUS en lugar de SHOW REPLICA STATUS. Si usa una versión de Aurora MySQL 1 o 2, utilice SHOW SLAVE STATUS. Use SHOW REPLICA STATUS para Aurora MySQL, versión 3 o posterior

La métrica AuroraBinlogReplicaLag devuelve -1 durante una interrupción de la red o cuando se aplica un parche durante el período de mantenimiento. En este caso, espere a que se restaure la conectividad de la red o a que finalice el período de mantenimiento antes de volver a comprobar la métrica AuroraBinlogReplicaLag.

La tecnología de replicación de lectura de MySQL es asíncrona. Por lo tanto, cabe esperar aumentos ocasionales para la métrica BinLogDiskUsage en la instancia de base de datos de origen y para la métrica AuroraBinlogReplicaLag en la réplica de lectura. Por ejemplo, considere una situación en la que se pueden realizar en paralelo un gran volumen de operaciones de escritura en la instancia de base de datos de origen. Al mismo tiempo, las operaciones de escritura en la réplica de lectura se serializan utilizando un único subproceso de E/S. Tal situación puede provocar un retraso entre la instancia de origen y la réplica de lectura.

Para obtener más información acerca de las réplicas de lectura y MySQL, consulte Replication Implementation Details en la documentación de MySQL.

Puede hacer varias cosas para reducir el retraso entre las actualizaciones de una instancia de base de datos de origen y las actualizaciones posteriores de la réplica de lectura:

  • Configure la clase de instancia de base de datos de la réplica de lectura para que tenga un tamaño de almacenamiento comparable al de la instancia de base de datos de origen.

  • Asegúrese de que la configuración de parámetros de los grupos de parámetros de base de datos utilizados en la instancia de base de datos de origen y la réplica de lectura sean compatibles. Para obtener más información y un ejemplo, consulte el análisis del parámetro max_allowed_packet en la siguiente sección.

  • Deshabilite la caché de consultas. Para tablas que se modifican a menudo, el uso de la caché de consultas puede aumentar el retardo de réplica porque la caché se bloquea y actualiza con frecuencia. Si esto fuera así, podría ver menos retardo de réplica si deshabilita la caché de consultas. Puede deshabilitar la caché de consultas estableciendo query_cache_type parameter en 0 en el grupo de parámetros de base de datos para la instancia de base de datos. Para obtener más información sobre la caché de consultas, consulte Query Cache Configuration.

  • Active el grupo de búferes en la réplica de lectura de InnoDB para MySQL . Por ejemplo, suponga que tiene un conjunto pequeño de tablas que se actualiza con frecuencia y está utilizando el esquema de tablas InnoDB o XtraDB. En este caso, puede volcar esas tablas en la réplica de lectura. Al hacer esto, el motor de base de datos examina las filas de esas tablas desde el disco y, a continuación, las almacena en la caché en el grupo del búfer. Este enfoque puede reducir el retraso de la réplica. A continuación se muestra un ejemplo.

    Para Linux, macOS o:Unix

    PROMPT> mysqldump \
    -h <endpoint> \
    --port=<port> \
    -u=<username> \
    -p <password> \
    database_name table1 table2 > /dev/null

    En:Windows

    PROMPT> mysqldump ^
    -h <endpoint> ^
    --port=<port> ^
    -u=<username> ^
    -p <password> ^
    database_name table1 table2 > /dev/null

Diagnóstico y solución de un error de replicación de lectura de MySQL

Amazon RDS supervisa el estado de replicación de las réplicas de lectura. RDS actualiza el campo Replication State (Estado de replicación) de la instancia de réplica de lectura a Error si la replicación se detiene por cualquier motivo. Puede revisar los detalles del error asociado que muestran los motores de MySQL visualizando el campo Replication Error (Error de replicación). También se generan eventos que indican el estado de la réplica de lectura, entre los que se incluyen RDS-EVENT-0045, RDS-EVENT-0046 y RDS-EVENT-0057. Para obtener más información acerca de los eventos y la suscripción a ellos, consulte Uso de notificaciones de eventos de Amazon RDS. Si aparece un mensaje de error de MySQL, compruebe el error en la documentación de mensajes de error de MySQL.

Estas son algunas de las situaciones comunes que pueden causar errores de replicación:

  • El valor para el parámetro max_allowed_packet para una réplica de lectura es inferior al parámetro max_allowed_packet para la instancia de base de datos de origen.

    El parámetro max_allowed_packet es un parámetro personalizado que puede establecer en un grupo de parámetros de base de datos. El parámetro max_allowed_packet se utiliza para especificar el tamaño máximo del lenguaje de manipulación de datos (DML) que se puede ejecutar en la base de datos. En algunos casos, el valor de max_allowed_packet de la instancia de base de datos de origen puede ser superior al valor de max_allowed_packet para la réplica de lectura. Si es así, el proceso de replicación puede generar el error y detener la replicación. El error más común es packet bigger than 'max_allowed_packet' bytes. Puede resolver el error haciendo que el origen y la réplica de lectura usen grupos de parámetros de base de datos con los mismos valores del parámetro max_allowed_packet.

  • Escritura en tablas en una réplica de lectura. Si desea crear índices en una réplica de lectura, debe establecer el parámetro read_only en 0 para crear los índices. Si se escribe en las tablas de la réplica de lectura, puede interrumpirse la replicación.

  • Uso de un motor de almacenamiento no transaccional como MyISAM. Las réplicas de lectura requieren un motor de almacenamiento transaccional. La reproducción solo se admite para los siguientes motores de almacenamiento: InnoDB for MySQL o MariaDB.

    Puede convertir una tabla MyISAM a InnoDB con el siguiente comando:

    alter table <schema>.<table_name> engine=innodb;

  • Uso de consultas no deterministas que no sean seguras, como SYSDATE(). Para obtener más información, consulte Determination of Safe and Unsafe Statements in Binary Logging en la documentación de MySQL.

Los siguientes pasos pueden ayudar a solucionar su error de replicación:

  • Si se encuentra ante un error lógico y decide que es seguro hacer caso omiso, siga los pasos que se describen en Omisión del error de replicación actual. La instancia de base de datos de Aurora MySQL debe estar ejecutando una versión que incluya el procedimiento mysql_rds_skip_repl_error. Para obtener más información, consulte mysql_rds_skip_repl_error.

  • Si se encuentra ante un problema de posición de registro binario (binlog), puede cambiar la posición de reproducción. Para hacerlo, utilice el comando mysql.rds_next_master_log para Aurora MySQL, versiones 1 y 2. Para hacerlo, utilice el comando mysql.rds_next_source_log para Aurora MySQL, versiones 3 y posteriores. La instancia de base de datos de Aurora MySQL debe estar ejecutando una versión que admita este comando para cambiar la posición de reproducción de la réplica. Para obtener información sobre la versión, consulte mysql_rds_next_master_log.

  • Si se encuentra ante un problema de rendimiento temporal debido a una carga de DML elevada, puede establecer el parámetro innodb_flush_log_at_trx_commit en 2 en el grupo de parámetros de base de datos en la réplica de lectura. Hacer esto puede ayudar a la réplica de lectura a ponerse al corriente, si bien reduce temporalmente las propiedades de atomicidad, coherencia, aislamiento y durabilidad (ACID).

  • Puede eliminar la réplica de lectura y crear una instancia con el mismo identificador de instancias de bases de datos. De este modo, el punto de conexión seguirá siendo el mismo que en la réplica de lectura antigua.

Si se corrige un error de replicación, Replication State cambia a replicating. Para obtener más información, consulte Solución de problemas de una réplica de lectura de MySQL o MariaDB.

Error de replicación detenida

Cuando llame al comando mysql.rds_skip_repl_error, es posible que reciba un mensaje de error en el que se indique que la reproducción tiene un error o está deshabilitada.

Este mensaje de error aparece porque la replicación se ha detenido y no se puede reiniciar.

Si tiene que omitir un número de errores elevado, el retardo de réplica puede aumentar por encima del periodo de retención predeterminado para los archivos de registro binarios. En este caso, puede producirse un error fatal debido a que los archivos de registro binario se están limpiando antes de reproducirse de nuevo en la réplica. Esta limpieza hace que la replicación se detenga y ya no se puede llamar al comando mysql.rds_skip_repl_error para omitir los errores de replicación.

Puede mitigar este problema incrementando el número de horas que los archivos de registro binarios se retienen en el origen de la replicación. Después de incrementar el tiempo de retención de los archivos binlog, puede reiniciar la replicación y llamar al comando mysql.rds_skip_repl_error si es necesario.

Para establecer el tiempo de retención del binlog, utilice el procedimiento mysql_rds_set_configuration. Especifique un parámetro de configuración de “horas de retención del binlog” junto con el número de horas de retención de los archivos binlog en el clúster de base de datos, hasta un máximo de 2160 (90 días). El valor predeterminado para Aurora MySQL es 24 (1 día). El ejemplo siguiente define el periodo de retención de los archivos binlog en 48 horas.

CALL mysql.rds_set_configuration('binlog retention hours', 48);