Parada de mantenimiento de emergencia

Actualización: acabó satisfactoriamente a las 2:35, o 0:35 UTC. Disculpad las molestias.

Resumen

Esta madrugada, 20 de setiembre a las 2 AM hora española continental una menos en Canarias, o mejor, a las 00:00 horas UTC cortaremos el servicio por mantenimiento urgente de la base de datos. Esperamos que no tarde más de media hora, pero como el procedimiento es relativamente complejo, podría tomar hasta una hora.

Explicación larga

Llevábamos varias semanas con microcortes (y algunos no tan micro) en Menéame. Se debían a una sobrecarga de la base de datos. Después de optimizar todo lo optimizable, logramos reducir la frecuencia y el efecto negativo, pero aún así, aparecen unas pocas veces al día.

La base de datos central (tenemos otra esclava) es un sistema RDS Multi AZ, consiste de dos servidores, uno siempre es el primario y el otro el secundario. Si el primario falla, automáticamente se migra (failover) al otro que está sincronizado y listo para hacer de nuevo máster.

Nuestro problema eran saturaciones repentinas de la base de datos Multi AZ. Aunque abrimos incidencias y explicamos a soporte de Amazon AWS, aseguraban no encontrar el problema, hasta esta mañana que después que le pasamos más datos. Se pusieron a analizar en profundidad y encontraron el problema: el que tenemos de secundario ahora tiene problemas de hardware que le hace bajar el rendimiento, como está sincronizado con el principal, a veces le provoca esos picos que no puede manejar. Para solucionarlo tenemos que librarnos de ese secundario y hacer que se arranque con uno diferente, es el procedimiento que nos han pedido que hagamos (abajo la explicación del técnico de Amazon).

Para evitar seguir teniendo estos problemas (que sabemos ocurrirán) mañana o los días que demoremos, hemos decidido hacerlo esta misma madrugada, en poco más de dos horas.

Disculpas por esta interrupción, y disculpas por las molestias ocasionadas las últimas semanas. Esperamos que a partir de esta madrugada las cosas funcionen mucho más suavemente.

De nuevo, disculpas.

As you pointed out with the CloudWatch metrics that you noted, your RDS database instance has been experiencing some occasions of increased and unexpected write latencies, which also correlate to a dramatic increase in database connections, and then resulting in issues with the ability to use the database. We drilled down deeper in to the metrics for your RDS instance, and found that a data volume on the Multi-AZ Secondary host system for your RDS database instance has been under-performing. As transactions in a Multi-AZ RDS setup are synchronous, this would cause performance issues to been experienced throughout the transaction process when they happen, such as during your experience.

Given the Mutli-AZ structure of your RDS instance, you do have the ability to take steps to help remedy the situation from your side. We recommend taking the following steps during a time when you can perform database maintenance for your application:
1) Take a database backup snapshot – this is always recommended before performing any maintenance. Also check that your read replica is in-synch for added backup.
2) Update your RDS database instance from Multi-AZ to Single-AZ – this will disconnect and remove the Secondary host system which is currently seen to have the under-performing data volume. It will also place your RDS instance in a state of not having fail-over redundancy, so be sure to have taken a backup snapshot.
3) Once the change to Single-AZ is complete, update your RDS database instance back to Multi-AZ – this will rebuild a new Secondary host system for your RDS database instance, synchronize your data, and restore the fail-over redundancy.

Anuncios

Un pensamiento en “Parada de mantenimiento de emergencia

  1. Pingback: Parada de mantenimiento de emergencia

Los comentarios están cerrados.