Actualizaciones menores de Amazon RDS MySQL: ¡No tan rápido!

La promesa de DBaaS, así como de RDS, es reducir los gastos generales operativos (entre otras cosas) y uno de los casos estelares son las actualizaciones (mayores y menores). El procedimiento sugerido implica sólo un par de pasos. Por ejemplo, con la consola de AWS, puede habilitar la «Actualización menor automática» o modificar la instancia de base de datos y programar la actualización para que se ejecute en la próxima ventana de mantenimiento.

Sin embargo, ambas opciones son riesgosas porque el proceso de actualización comienza durante la ventana de mantenimiento, pero es NO garantiza que la actualización se completará dentro del tiempo especificado.

El problema

RDS realiza algunos pasos adicionales para garantizar la coherencia y la reversión de los datos, lo que hace que la actualización a una versión secundaria sea un proceso lento:

  • Necesita una copia de seguridad (si las copias de seguridad automáticas están habilitadas) antes de iniciar el proceso de actualización.
  • Realice el apagado lento después de la instalación innodb_fast_shutdown= 0, lo que puede llevar minutos o incluso horas si hay una gran cantidad de búfer de cambios para unirse. ¡Este es el cuello de botella más grande!
  • Se realiza otra copia de seguridad (si las copias de seguridad automáticas están habilitadas) después de finalizar la actualización.
  • Garantiza que todas las réplicas deben actualizarse a la versión de destino antes de iniciar el proceso de actualización en Master.

En una configuración típica de maestro/replicación, el tiempo de actualización se duplicará, ya que las primeras réplicas deberán completar todos los pasos anteriores y luego el maestro. Si tiene una ventana de tiempo de mantenimiento ajustada, es posible que no pueda finalizar el proceso de actualización en una sola ventana, ¡incluso si no tiene réplicas!

¿Por qué?

Las copias de seguridad son largas (y estrechas al tamaño de datadir).

Pero sobre todo porque el apagado rápido está deshabilitado. Y el cuello de botella no son ni siquiera las páginas sucias en el grupo de búfer, sino el CAMBIAR TAMPÓN. Cambiar las fusiones de búfer puede llevar de minutos a horas, según el uso (número de páginas de índice secundarias) y el tamaño.

Supervisión de las fusiones de búfer de cambios

¿Soy víctima de fusiones de amortiguadores de cambio? Aquí le mostramos cómo averiguarlo:

Registro de errores:

Es posible que vea un mensaje similar al siguiente en el registro de errores de MySQL cuando el búfer de cambios se fusiona durante el proceso de apagado lento.

Estado de InnoDB:

Echa un vistazo a la salida «MOSTRAR ESTADO DE INNODB DEL MOTOR G»:

Las dimensiones se muestran en páginas (predeterminado 16K). Los valores actuales de la memoria son los siguientes:

  • Memoria total asignada para cambiar el búfer: tamaño de segmento (34199) * Innodb_page_size (16384) = 534,35 MB
  • Memoria total utilizada por el búfer de cambio: Ibuf: tamaño (14591) * Innodb_page_size (16384) = 227,98 MB

Ejecutamos una carga de trabajo de escritura en db.m4.large para aumentar el tamaño del búfer de cambios a 227,98 MB (Ibuf: tamaño 14591). Entonces, se produjo la lenta detención. 3 horas, 15 minutos. Esto significa que la actualización de la versión secundaria para esta instancia tardará 3,25 horas más el tiempo necesario para el proceso de actualización real.

Los detalles de la instancia son los siguientes:

– Versión del motor: 5.7.22
– Multi-AZ: No.
– Clase de instancia: db.m4.large
– IOPS suministradas: 1000
– Grupo de parámetros: default.mysql5.7 (excepto innodb_buffer_pool_size: 3G)

Registros de apagado lento:

Supervisión y Gestión de Percona

Al ser una de las métricas clave en InnoDB, cuenta con su propio gráfico, donde se puede ver el comportamiento histórico:

Multi-AZ me salva?

Puede pensar que Multi-AZ evita el tiempo de inactividad en Master durante las actualizaciones de versión. Bueno, este no es el caso, ya que la actualización de la versión ocurre simultáneamente en la instancia principal y en espera e implicará un tiempo de inactividad en la instancia maestra. No hubo conmutación por error durante la actualización en el maestro.

Aceleración de las cosas

Es posible evitar un largo período de tiempo de inactividad. El truco es usar un leer réplica a Avanzado + Promocionar.

Se deben realizar los siguientes pasos para actualizar con un mínimo de tiempo de inactividad:

  • Cree una réplica de lectura (si aún no lo ha hecho)
  • Realice la actualización de la versión secundaria en la réplica de lectura.
  • Detenga la aplicación y confirme que la réplica de lectura está actualizada.
  • Promocione la réplica de lectura como el nuevo maestro.
  • Actualice la aplicación para enviar tráfico al nuevo extremo de RDS maestro.
  • Crear nuevas réplicas de lectura del nuevo Máster.

Asegúrese de que la réplica de lectura creada (y el maestro futuro) tenga el mismo tamaño de instancia, clase, almacenamiento y configuración que el maestro actual. Y no olvide hacer una pequeña limpieza para eliminar las instancias antiguas de RDS.

¿Y deshabilitar el búfer de cambio?

Configuración de InnoDB innodb_change_buffering compruebe si InnoDB está realizando cambios en el búfer o no.

Para reducir el tiempo que tarda el apagado lento, puede configurarlo innodb_change_buffering a nadie temporalmente. Sin embargo, tenga en cuenta que cambiar esto solo afectará el almacenamiento en búfer en las operaciones NUEVAS. La fusión de entradas de búfer existentes no se ve afectada. Puede esperar hasta que el tamaño del búfer de cambios se reduzca a unos pocos KB y luego iniciar el proceso de actualización.

¿Afecta esto a la instancia de Aurora RDS?

Aurora no tiene un búfer de cambio de InnoDB, por lo que no se ve afectado por esto.

Conclusiones

Amazon RDS es una gran plataforma para alojar sus bases de datos MySQL. Proporciona una opción para realizar actualizaciones menores con unos pocos clics. Sin embargo, puede ser un proceso lento y puede causar tiempo de inactividad adicional. Este blog sugiere el enfoque recomendado para planificar actualizaciones de versiones secundarias con un tiempo de inactividad mínimo.


Para obtener más información, descargue nuestra breve solución a continuación que describe la creación de instancias MySQL Amazon RDS para satisfacer las crecientes necesidades de su empresa. Amazon RDS es adecuado para cargas de trabajo de producción y también puede admitir una implementación y un desarrollo de aplicaciones rápidos debido a la facilidad de la configuración inicial.

Haga crecer su negocio con un entorno AWS RDS MySQL

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario