Solución de problemas de Amazon RDS - Amazon Relational Database Service
No puede conectarse a la instancia de base de datos de Problemas de seguridadSolución de problemas de estado de red incompatibleRestablecimiento 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 efectoInstancia de base de datos sin espacio de almacenamientoInstancias de bases de datos disponibles insuficientesProblemas de memoria que se puede liberar de RDSProblemas de MySQL y MariaDBNo se puede establecer el período de retención de copia de seguridad en 0

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

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

Solución de problemas de estado de red incompatible

El estado de red incompatible significa que es posible que se puede acceder a la base de datos a nivel de base de datos, pero no es posible modificarla ni reiniciarla.

Causas

El estado de red incompatible de la instancia de base de datos podría deberse a una de las siguientes acciones:

  • Modificación de la clase de instancia de base de datos.

  • Modificación de la instancia de base de datos para utilizar una implementación de un clúster de base de datos Multi-AZ.

  • Sustitución de un host debido a un evento de mantenimiento.

  • Lanzamiento de una instancia de base de datos de reemplazo.

  • Restauración a partir de una instantánea.

  • Inicio de una instancia de base de datos que se había detenido.

Resolución

Utilice el comando start-db-instance

Para reparar una base de datos que se encuentra en un estado de red incompatible, siga estas instrucciones:

  1. Abra la https://console.aws.amazon.com/rds/ y elija Bases de datos en el panel de navegación.

  2. Elija la instancia de base de datos que se encuentra en el estado de red incompatible y tome nota del identificador de la instancia de base de datos, el ID de la VPC y los ID de subred de la pestaña Conectividad y seguridad.

  3. Utilice la AWS CLI para ejecutar el comando start-db-instance. Especifique el valor --db-instance-identifier.

    nota

    La ejecución de este comando cuando la base de datos está en modo incompatible podría provocar algo de tiempo de inactividad.

    El comando start-db-instance no resuelve este problema en el caso de instancias de base de datos de RDS para SQL Server.

El estado de la base de datos cambia a Disponible si el comando se ejecuta correctamente.

Si la base de datos se reinicia, la instancia de base de datos podría ejecutar la última operación ejecutada en la instancia antes de que pasara al estado de red incompatible. Esto podría hacer que la instancia volviera al estado de red incompatible.

Si el comando start-db-instance no funciona o la instancia vuelve al estado de red incompatible, abra la página Bases de datos en la consola de RDS y seleccione la base de datos. Vaya a la sección Registros y eventos. La sección Eventos recientes muestra pasos de resolución adicionales que puede seguir. Los mensajes se clasifican de la siguiente manera:

  • COMPROBACIÓN DE RECURSOS INTERNOS: es posible que haya problemas con sus recursos internos.

  • COMPROBACIÓN DE DNS: compruebe la resolución de DNS y los nombres de host de la VPC en la consola de la VPC.

  • COMPROBACIÓN DE ENI: es posible que la interfaz de red elástica (ENI) de esta base de datos no exista.

  • COMPROBACIÓN DE PUERTA DE ENLACE: la puerta de enlace de Internet de su base de datos disponible públicamente no está conectada a la VPC.

  • COMPROBACIÓN DE IP: no hay direcciones IP libres en sus subredes.

  • COMPROBACIÓN DE GRUPO DE SEGURIDAD: no hay grupos de seguridad asociados a la base de datos o los grupos de seguridad no son válidos.

  • COMPROBACIÓN DE SUBRED: no hay subredes válidas en su grupo de subredes de base de datos o hay problemas con la subred.

  • COMPROBACIÓN DE VPC: la VPC asociada a la base de datos no es válida.

Realizar una recuperación en un momento dado

Se recomienda tener una copia de seguridad (instantánea o lógica) en caso de que la base de datos entre en un estado de red incompatible. Consulte Introducción a las copias de seguridad. Si ha activado las copias de seguridad automáticas, detenga temporalmente cualquier escritura en la base de datos y realice una recuperación en un momento dado.

nota

Cuando una instancia pasa al estado de red incompatible, es posible que no se pueda acceder a la instancia de base de datos para realizar una copia de seguridad lógica.

Si no ha activado las copias de seguridad automáticas, cree una nueva instancia de base de datos. A continuación, migre los datos mediante AWS Database Migration Service (AWS DMS) o mediante una herramienta de copia de seguridad y restauración.

Si esto no resuelve el problema, contacte con AWS Support para obtener ayuda adicional.

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

  • 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 aprovisionadas [SSD]), o de Provisioned IOPS (SSD) (IOPS aprovisionadas [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 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 RDS.

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

En: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

Instancias de bases de datos de Amazon RDS disponibles insuficientes

El error InsufficientDBInstanceCapacity se puede devolver cuando intenta crear, iniciar o modificar una instancia de base de datos. También se puede devolver cuando intenta restaurar una instancia de base de datos a partir de una instantánea de base de datos. Cuando se recibe este error, una causa común es que 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 el tema sobre capacidad insuficiente de las instancias en la guía del usuario de Amazon EC2.

Para obtener más información sobre 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 memoria que se puede liberar en Amazon RDS

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 Supervisión de herramientas de Amazon RDS.

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 .

También puede cambiar la configuración de memoria. Por ejemplo, en RDS para 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?).

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 para MySQL o de RDS para 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 de .

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 Grupos de parámetros para Amazon RDS.

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 tener el estado incompatible-parameters para un límite de memoria cuando se cumplen las 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, cuando el estado de la instancia de base de datos es Disponible.

  • Se produce un error al intentar reiniciar la instancia de base de datos porque una acción de mantenimiento o un proceso de monitorización no han podido 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, realiza una comprobación del uso de memoria. La comprobación realiza el cálculo 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

      Puede cambiar el valor de innodb_buffer_pool_size. Sin embargo, el valor no siempre coincidirá con lo que introduzca. Esta falta de coincidencia se produce por varias razones. En primer lugar, si la instancia de base de datos es una microinstancia de base de datos, sustituimos el valor predeterminado y lo establecemos en 256 MB. Para obtener más información, consulte Anulación de innodb_buffer_pool_size.

      En segundo lugar, nos aseguramos de reservar 500 MB de memoria en la instancia de base de datos para el administrador del host, el motor, el sistema operativo y el kernel.

      Por último, optimizamos innodb_buffer_pool_size dividiéndolo en unidades. El administrador del host redondea hacia abajo al múltiplo más cercano de esas unidades. Las unidades se calculan multiplicando innodb_buffer_pool_chunk_size por innodb_buffer_pool_instances. Para obtener más información, consulte Configuring InnoDB Buffer Pool Size en la documentación de MySQL.

      El valor predeterminado para innodb_buffer_pool_instances es 8, a menos que innodb_buffer_pool_size sea inferior a 1 GB. Si innodb_buffer_pool_size es inferior a 1 GB, el valor predeterminado para innodb_buffer_pool_instances es 1. El valor predeterminado para innodb_buffer_pool_chunk_size es de 128 MB.

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size (versión 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 429498.

    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 del grupo de parámetros de base de datos asociado a la instancia de base de datos. Hágalo de forma 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 los parámetros de un grupo de parámetros de base de datos en Amazon RDS.

  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 HOW REPLICA STATUS Statement (Instrucción HOW REPLICA STATUS) en la documentación de MySQL.

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 Descripción de replicación 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

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

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 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-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. 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. 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 de RDS para MySQL. 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.

  • Es posible que encuentre un problema de rendimiento temporal debido a la alta carga de DML. Si es así, puede establecer el parámetro innodb_flush_log_at_trx_commit en 2 en el grupo de parámetros de base de datos de 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 para MySQL o RDS para 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 para MySQL y RDS para 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.

Puede crear un nuevo grupo de parámetros de base de datos para poder crear desencadenadores en su instancia de base de datos de RDS para MySQL o RDS para MariaDB con el registro binario activado. Para ello, utilice los siguientes comandos de 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"

    En: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"

    En: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

    En: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 de MySQL o MariaDB, puede reducir 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 Introducción a las copias de seguridad y Restauración de una instancia de base de datos a un momento especificado para Amazon RDS.

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 co 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.