¿Cómo funciona realmente la copia de seguridad / instantánea de Amazon RDS?

Soy cliente de Amazon RDS y estoy experimentando picos diarios de latencia de escritura de Amazon RDS, que corresponden aproximadamente a la ventana de respaldo. También veré picos al final de una instantánea (ejemplo: ejecutar una instantánea toma aproximadamente 1 hora, y en los últimos 5 minutos, escribir picos de latencia). Estoy ejecutando una implementación m1.large multi-AZ.

¿Hay alguien en Stack que pueda explicar cómo funciona realmente la copia de seguridad de Amazon RDS ? He leído los documentos de Amazon RDS y, por lo que puedo decir, Amazon RDS no se comporta de acuerdo con las especificaciones. Específicamente, estas operaciones de copia de seguridad / instantáneas deberían afectar mi réplica y, por lo tanto, no causar ningún tiempo de inactividad / impacto en el rendimiento, o eso pensé.

Puedo resumir mi problema en seis preguntas:

• ¿Qué está sucediendo técnicamente durante una instantánea y una copia de seguridad, y en qué se diferencian? (Si responde esta pregunta, dígame si puede confirmar empíricamente su respuesta o simplemente me está citando documentación).
• ¿Se espera un aumento en la latencia de escritura durante la ventana de respaldo en una implementación de varias zonas de disponibilidad?
• ¿Se espera un aumento en la latencia de escritura al final de una instantánea en una implementación de varias zonas de disponibilidad?
• ¿Mi pico de latencia de escritura sería aún mayor si no fuera multi-AZ?
• Arquitectónicamente, ¿podría evitar estos picos de latencia de escritura si lanzara mi propia base de datos ejecutándose en dos instancias EC2 m1.large?
• ¿Hay alguna configuración que pueda usar que evite estos picos de latencia de escritura mientras aún alojo mi base de datos con RDS, o estoy efectivamente a merced de Amazon?

Pregunta adicional: ¿dónde y cómo aloja su base de datos mysql?

Puedo decir que en general he estado satisfecho con RDS, excepto por estos problemas diarios de latencia de escritura. Me encanta la supervisión de la base de datos incorporada y fue bastante simple de configurar y comenzar.

¡Gracias!

También ejecutamos varias instancias de RDS, además de MySQL en algunas máquinas que administramos nosotros mismos. No puedo comentar específicamente, ya que no soy un ingeniero de Amazon, pero he aprendido varias cosas que podrían explicar lo que estás viendo:

• Aunque Amazon no comparte los detalles del backend al 100%, sospechamos fuertemente que están usando su sistema EBS para respaldar las bases de datos RDS.

• Este artículo ayuda a explicar las limitaciones de EBS y la funcionalidad de instantáneas http://blog.rightscale.com/2008/08/20/amazon-ebs-explained/ Nuevamente, aunque no es explícito, tendría sentido que Amazon utilizara esta infraestructura para proporcionar servicios RDS.

• Por lo general, una copia de seguridad de MySQL, a diferencia de una instantánea, implica el uso de una herramienta como mysqldump para crear un archivo de declaraciones SQL que luego reproducirá la base de datos. No es necesario congelar la base de datos para hacer esto. Con un backend de EBS, la mejor práctica es congelar la base de datos (pausar todas las transacciones) mientras realiza instantáneas para evitar la corrupción de datos.

• Los picos que está viendo al final de la ventana de copia de seguridad. Si Amazon detiene la replicación durante la instantánea de su réplica, la réplica deberá "ponerse al día" con las transacciones cuando la instantánea esté completa. Esto provocaría un pico de latencia.

• La replicación en una implementación de varias zonas de disponibilidad es inherentemente más lenta que una implementación de una sola zona de disponibilidad. El precio que paga por una mejor redundancia.

Amazon reveló la arquitectura básica que utilizan en las implementaciones Multi AZ. Esto puede ayudar a las personas a tomar decisiones.

https://aws.amazon.com/blogs/database/amazon-rds-under-the-hood-multi-az/