Solución de problemas de Amazon RDS - Amazon Relational Database Service

Solución de problemas de Amazon RDS

Utilice las siguientes secciones como ayuda para solucionar los problemas que puedan presentarse con instancias de base de datos en Amazon RDS y 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 Amazon RDS.

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 a la instancia 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 una instancia 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 la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

    2. En el panel de navegación, elija 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.

      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.

      3. Elija Save routes (Guardar rutas).

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

Para obtener información sobre problemas de conexión específicos del motor, consulte los temas siguientes:

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 enlace y port por el puerto de su 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

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

Para obtener más información acerca de la modificación de una instancia de base de datos de , consulte Modificación de una instancia de base de datos de Amazon RDS.

Problemas de seguridad de Amazon RDS

Para evitar problemas de seguridad, no utilice nunca el AWS nombre de usuario maestro y contraseña para una cuenta de usuario. La práctica recomendada consiste en utilizar la AWS cuenta maestra para crear usuarios AWS Identity and Access Management (IAM) y asignarlos a cuentas de usuario de base de datos. También puede utilizar su cuenta maestra para crear, si fuera necesario, otras cuentas de usuario.

Para obtener más información sobre la creación de usuarios de IAM, consulte Creación de un usuario 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 de IAM 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 la instancia 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 más información acerca de la modificación de una instancia de base de datos de , consulte Modificación de una instancia de base de datos de Amazon RDS.

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. El reinicio puede producirse cuando reinicia manualmente la instancia de base de datos o cuando cambia una configuración de la instancia de base de datos que exige un reinicio para 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 bien puede producirse 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:

  • 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 true.

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

  • Puede cambiar el tipo de almacenamiento de Magnetic (Standard) (Magnético [estándar]) a General Purpose (SSD) (Propósito general [SSD]) o Provisioned IOPS (SSD) (IOPS provisionadas [SSD]), o de Provisioned IOPS (SSD) (IOPS provisionadas [SSD]) o General Purpose (SSD) (Propósito general [SSD]) a Magnetic (Standard) (Magnético [estándar]).

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.

Para ver una tabla que muestra acciones de la instancia de base de datos y el efecto que tiene configurar el valor Apply Immediately, consulte Modificación de una instancia de base de datos de Amazon RDS.

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 utilizando la consola de RDS o llamando explícitamente a la operación RebootDBInstance de la API (sin conmutación por error, si la instancia de base de datos está en un Multi-AZ deployment). 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 parámetros de un grupo de parámetros de base de datos.

La instancia de base de datos de Amazon RDS se está quedando sin espacio de almacenamiento

Si su instancia de base de datos se queda sin espacio de almacenamiento, es posible que ya no esté disponible. Recomendamos encarecidamente que monitoree de manera regular la métrica de FreeStorageSpace publicada en CloudWatch para asegurarse de que la instancia de base de datos tenga suficiente espacio de almacenamiento libre.

Si la instancia de base de datos se queda sin espacio de almacenamiento, su estado cambia a storage-full. Por ejemplo, una llamada a la operación de la API DescribeDBInstances para la instancia de base de datos que ha utilizado todo su espacio de almacenamiento produce lo siguiente.

aws rds describe-db-instances --db-instance-identifier mydbinstance DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Para recuperarse de esta situación, agregue más espacio de almacenamiento a su instancia mediante la operación de la API ModifyDBInstance o el siguiente comando de la AWS CLI.

Para Linux, macOS o Unix:

aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --allocated-storage 60 \ --apply-immediately

Para Windows:

aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --allocated-storage 60 ^ --apply-immediately
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Ahora, cuando describa su instancia de base de datos, verá que esta tendrá el estado modifying, lo que indica el escalado del almacenamiento.

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 50 sa modifying mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Una vez que se ha completado el escalado de almacenamiento, el estado de la instancia de base de datos cambia a available.

aws rds describe-db-instances --db-instance-identifier mydbinstance
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m5.large mysql8.0 60 sa available mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql8.0 in-sync

Puede recibir notificaciones cuando se ha agotado su espacio de almacenamiento mediante la operación DescribeEvents. Por ejemplo, en esta situación, si realiza una llamada DescribeEvents después de estas operaciones, verá el siguiente resultado.

aws rds describe-events --source-type db-instance --source-identifier mydbinstance
2009-12-22T23:44:14.374Z mydbinstance Allocated storage has been exhausted db-instance 2009-12-23T00:14:02.737Z mydbinstance Applying modification to allocated storage db-instance 2009-12-23T00:31:54.764Z mydbinstance Finished applying modification to allocated storage

Capacidad de la instancia de base de datos insuficiente de Amazon RDS

El error InsufficientDBInstanceCapacity se puede devolver cuando intenta crear o modificar una instancia de base de datos o cuando intenta restaurar una desde una instantánea de base de datos. A continuación se muestran motivos habituales por los que se devuelve un error:

  • La clase de instancia de base de datos específica no está disponible en la zona de disponibilidad solicitada. Puede intentar una de las siguientes propuestas para resolver el problema:

    • Volver a intentar la solicitud con una clase de instancia de base de datos distinta.

    • Volver a intentar la solicitud con una zona de disponibilidad distinta.

    • Volver a intentar la solicitud sin especificar una zona de disponibilidad explícita.

    Para obtener más información acerca de la solución de problemas relacionados con la capacidad de la instancia para Amazon EC2, consulte Capacidad de las instancias insuficiente en la Guía del usuario de Amazon Elastic Compute Cloud.

  • La instancia de base de datos se encuentra en la plataforma EC2-Classic y, por lo tanto, no en una VPC. Algunas clases de instancia de base de datos requieren una VPC. Por ejemplo, si está en la plataforma EC2-Classic e intenta aumentar la capacidad cambiando a una clase de instancia de base de datos que requiera una VPC, se produce este error. Para obtener información sobre los tipos de instancias de Amazon EC2 que están disponibles en una VPC, consulte Tipos de instancia disponibles en EC2-Classic en la Guía de usuario de Amazon Elastic Compute Cloud. Para corregir el problema, puede desplazar la instancia de base de datos a una VPC. Para obtener más información, consulte Traslado de una instancia de base de datos que no está en una VPC a una VPC.

Para obtener más información acerca de la modificación de una instancia de base de datos , consulte Modificación de una instancia de base de datos de Amazon RDS.

Problemas de MySQL y MariaDB

Puede diagnosticar y corregir problemas con las instancias de base de datos MySQL y MariaDB.

Máximo de conexiones de MySQL y MariaDB

El número máximo de conexiones permitidas a una instancia de base de datos de RDS for MySQL o de RDS for MariaDB se basa en la cantidad de memoria disponible para la clase de instancia de base de datos. Una clase de instancia de base de datos con más memoria disponible da como resultado un mayor número de conexiones disponibles. Para obtener más información acerca de las clases de instancias de bases de datos, consulte Clases de instancia de base de datos.

El límite de conexiones para una instancia de base de datos se define de forma predeterminada en el número máximo para la clase de instancia de base de datos. Puede limitar el número de conexiones simultáneas a cualquier valor hasta el número máximo de conexiones permitidas. Utilice el parámetro max_connections en el grupo de parámetros para la instancia de base de datos. Para obtener más información, consulte Número máximo de conexiones de base de datos y Trabajo con los grupos de parámetros de base de datos.

Puede recuperar el número máximo de conexiones permitidas para una instancia de base de datos de MySQL o MariaDB ejecutando la siguiente consulta.

SELECT @@max_connections;

Puede recuperar el número de conexiones activas para una instancia de base datos de MySQL o MariaDB ejecutando la siguiente consulta.

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

Diagnóstico y resolución del estado de parámetros incompatibles para un límite de memoria

Una instancia de base de datos de MariaDB o MySQL puede colocarse en el estado de parámetros incompatibles para un límite de memoria cuando se cumplen las dos condiciones siguientes:

  • La instancia de base de datos se reinicia al menos tres veces en una hora o al menos cinco veces en un día, o se produce un error al intentar reiniciar la instancia de base de datos.

  • El uso potencial de memoria de la instancia de base de datos supera 1,2 veces la memoria asignada a su clase de instancia de base de datos.

Cuando una instancia de base de datos se reinicia por tercera vez en una hora o por quinta vez en un día, Amazon RDS for MySQL realiza una comprobación del uso de memoria. La comprobación realiza el cálculo a del uso potencial de memoria de la instancia de base de datos. El valor devuelto por el cálculo es la suma de los siguientes valores:

  • Valor 1 – La suma de los siguientes parámetros:

    • innodb_additional_mem_pool_size

    • innodb_buffer_pool_size

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size ( versiones 5.6 y 5.7 de MySQL únicamente)

    • tmp_table_size

  • Valor 2 – El parámetro max_connections multiplicado por la suma de los siguientes parámetros:

    • binlog_cache_size

    • join_buffer_size

    • read_buffer_size

    • read_rnd_buffer_size

    • sort_buffer_size

    • thread_stack

  • Valor 3 – Si el parámetro performance_schema está habilitado, multiplique el parámetro max_connections por 257700.

    Si el parámetro performance_schema está deshabilitado, entonces este valor es cero.

Por lo tanto, el valor devuelto por el cálculo es el siguiente:

Value 1 + Value 2 + Value 3

Cuando este valor supera 1,2 veces la memoria asignada a la clase de instancia de base de datos utilizada por la instancia de base de datos, la instancia de base de datos se coloca en el estado de parámetros incompatibles. Para obtener información acerca de la memoria asignada a las clases de instancia de base de datos, consulte Especificaciones de hardware para clases de instancia de base de datos .

El cálculo multiplica el valor del parámetro max_connections por la suma de varios parámetros. Si el parámetro max_connections se establece en un valor grande, podría hacer que la comprobación devuelva un valor extremadamente alto del uso potencial de memoria de la instancia de base de datos. En este caso, considere bajar el valor del parámetro max_connections.

Para resolver el problema, siga los pasos siguientes:

  1. Ajuste los parámetros de memoria en el grupo de parámetros de base de datos asociado a la instancia de base de datos para que el uso potencial de memoria sea inferior a 1,2 veces la memoria asignada a su clase de instancia de base de datos.

    Para obtener información acerca de cómo configurar los parámetros, consulte Modificación de parámetros de un grupo de parámetros de base de datos.

  2. Reinicie la instancia de base de datos.

    Para obtener información acerca de cómo configurar los parámetros, consulte Inicio de una instancia de base de datos de Amazon RDS parada previamente.

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

Después de crear una réplica de lectura de MySQL o MariaDB 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 ReplicaLag de Amazon RDS.

La métrica ReplicaLag indica el valor del campo Seconds_Behind_Master del comando SHOW REPLICA STATUS de MariaDB o MySQL. Para obtener más información, consulte SHOW REPLICA STATUS (MOSTRAR ESTADO DE RÉPLICA). Cuando la métrica ReplicaLag llegue a 0, la réplica estará funcionando al mismo ritmo que la instancia de base de datos de origen. Si la métrica ReplicaLag 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 o MariaDB. Un valor ReplicaLag de -1 también puede significar que el valor Seconds_Behind_Master no se puede determinar o es NULL.

nota

Versiones anteriores de MariaDB y MySQL utilizaban SHOW SLAVE STATUS en lugar de SHOW REPLICA STATUS. Si usa una versión de MariaDB anterior a la 10.5 o una versión de MySQL anterior a la 8.0.23, utilice SHOW SLAVE STATUS.

La métrica ReplicaLag 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 ReplicaLag .

La tecnología de replicación de lectura de MySQL y MariaDB 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 ReplicaLag 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. Para obtener más información acerca de las réplicas de lectura y MariaDB, consulte Replication Overview en la documentación de MariaDB.

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 o MariaDB. 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

    Para 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 o MariaDB

Amazon RDS monitorea el estado de la replicación de las réplicas de lectura. Actualiza el campo Replication State (Estado de replicación) de la instancia de la 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 o MariaDB 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-0047. Para obtener más información acerca de los eventos y la suscripción a ellos, consulte Uso de las 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. Si aparece un mensaje de error de MariaDB, compruebe el error en la documentación de mensajes de error de MariaDB.

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. Si el valor de max_allowed_packet para la instancia de base de datos de origen es superior al valor de max_allowed_packet para la réplica de lectura, el proceso de replicación puede generar un 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 MySQL o MariaDB 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 de la réplica con el comando mysql_rds_next_master_log. La instancia de base de datos MySQL o MariaDB debe estar ejecutando una versión que admita el comando mysql_rds_next_master_log 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 enlace 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 réplicas de lectura de MySQL.

La creación de desencadenadores con registro binario habilitado exige privilegios SUPER

Al intentar crear desencadenadores en una instancia de base de datos de RDS for MySQL o RDS for MariaDB, podría recibir el siguiente error.

"You do not have the SUPER privilege and binary logging is enabled"

Para utilizar desencadenadores cuando el registro binario está habilitado, se necesitan privilegios SUPER, que están restringidos para las instancias de base de datos de RDS for MySQL y RDS for MariaDB. Puede crear disparadores cuando el registro binario está habilitado sin privilegios SUPER estableciendo el parámetro log_bin_trust_function_creators en true. Para establecer log_bin_trust_function_creators en true, cree un grupo de parámetros de base de datos nuevo o modifique un grupo existente.

Para crear un grupo de parámetros de base de datos nuevo que le permita crear desencadenadores en su instancia de base de datos de RDS for MySQL o RDS for MariaDB con el registro binario habilitado, utilice los siguientes comandos de la CLI. Para modificar un grupo de parámetros existente, comience por el paso 2.

Para crear un grupo de parámetros nuevo que permita disparadores con el registro binario habilitado mediante la CLI

  1. Cree un nuevo grupo de parámetros.

    Para Linux, macOS o Unix:

    aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql8.0 \ --description "parameter group allowing triggers"

    Para Windows:

    aws rds create-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --db-parameter-group-family mysql8.0 ^ --description "parameter group allowing triggers"
  2. Modifique el grupo de parámetros de base de datos para permitir disparadores.

    Para Linux, macOS o Unix:

    aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

    Para Windows:

    aws rds modify-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"
  3. Modifique su instancia de base de datos para usar el nuevo grupo de parámetros de base de datos.

    Para Linux, macOS o Unix:

    aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --db-parameter-group-name allow-triggers \ --apply-immediately

    Para Windows:

    aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --db-parameter-group-name allow-triggers ^ --apply-immediately
  4. Para que los cambios surtan efecto, reinicie manualmente la instancia de base de datos.

    aws rds reboot-db-instance --db-instance-identifier mydbinstance

Diagnóstico y resolución de errores de restauración a un momento dado

Restauración de una instancia de base de datos que incluye tablas temporales

Al intentar una restauración a un momento dado (PITR) de una instancia de base de datos MySQL o MariaDB, podría recibir el siguiente error.

Database instance could not be restored because there has been incompatible database activity for restore functionality. Common examples of incompatible activity include using temporary tables, in-memory tables, or using MyISAM tables. In this case, use of Temporary table was detected.

PITR usa instantáneas de copia de seguridad y registros binarios (binlogs) de MySQL o MariaDB para restaurar su instancia de base de datos a un momento específico. La información de las tablas temporales podría no ser fiable en binlogs y causar un error de PITR. Si utiliza tablas temporales en su instancia de base de datos MySQL o MariaDB, puede reducir al mínimo las posibilidades de un error de PITR realizando copias de seguridad más frecuentes. Un error de PITR es más probable en el tiempo que transcurre entre la creación de la tabla temporal y la siguiente instantánea de copia de seguridad.

Restauración de una instancia de base de datos que incluye tablas en memoria

Podría encontrarse con un problema al restaurar una base de datos que tiene tablas en memoria. Las tablas en memoria se purgan durante un reinicio. Como consecuencia, sus tablas en memoria podrían estar vacías después de un reinicio. Recomendamos que cuando utilice tablas en memoria, diseñe su solución para que controle tablas vacías en caso de producirse un reinicio. Si utiliza tablas en memoria con instancias de base de datos replicadas, tal vez deba recrear las réplicas de lectura después de un reinicio. Esto puede ser necesario si una réplica de lectura se reinicia y no puede restaurar datos de una tabla en memoria vacía.

Para obtener más información acerca de copias de seguridad y PITR, consulte Trabajo con copias de seguridad y Restauración de una instancia de base de datos a un momento especificado.

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 720 (30 días). 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);

Se produce un error en la creación de la réplica de lectura o la replicación se interrumpe con el error grave 1236

Después de cambiar los valores de los parámetros predeterminados para una instancia de base de datos MySQL o MariaDB, podría encontrarse ante uno de los siguientes problemas:

  • No puede crear una réplica de lectura para la instancia de base de datos.

  • Error de replicación con fatal error 1236

Algunos valores de parámetros predeterminados para instancias de base de datos MySQL o MariaDB ayudan a garantizar que la base de datos cumple las propiedades ACID y que las réplicas de lectura están a prueba de bloqueo. Esto se logra asegurándose de que cada confirmación esté totalmente sincronizada mediante la escritura de la transacción en el registro binario antes de su confirmación. Cambiar los valores predeterminados de estos parámetros para mejorar el rendimiento puede provocar un error en la replicación si no se ha escrito una transacción en el registro binario.

Para resolver este problema, establezca los siguientes valores de parámetros:

  • sync-binlog = 1

  • innodb_support_xa = 1

  • innodb_flush_log_at_trx_commit = 1

No se puede establecer el período de retención de copia de seguridad en 0

Existen varios motivos por los que es posible que tenga que establecer el período de retención de copia de seguridad en 0. Por ejemplo, puede deshabilitar las copias de seguridad automáticas inmediatamente estableciendo el período de retención en 0.

En algunos casos, podría establecer el valor en 0 y recibir un mensaje indicando que el período de retención debe estar entre 1 y 35. En estos casos, compruebe que no ha configurado una réplica de lectura para la instancia. Las réplicas de lectura requieren copias de seguridad para administrar los registros de réplica de lectura y, por lo tanto, no puede establecer el período de retención de 0.