Comment fonctionne réellement la sauvegarde / instantané Amazon RDS?

Je suis un client Amazon RDS et je rencontre quotidiennement des pics de latence d'écriture Amazon RDS, correspondant à peu près à la fenêtre de sauvegarde. Je verrai également des pics à la fin d'un instantané (exemple: exécuter un instantané prend environ 1 heure et dans les 5 dernières minutes, écrire des pics de latence). J'exécute un déploiement multi-AZ m1.large.

Y a-t-il quelqu'un sur Stack qui peut expliquer comment la sauvegarde Amazon RDS fonctionne réellement ? J'ai lu les documents Amazon RDS et, pour autant que je sache, Amazon RDS ne se comporte pas conformément aux spécifications. Plus précisément, ces opérations de sauvegarde / instantané devraient frapper mon réplica, et donc ne causer aucun temps d'arrêt / performance, du moins je le pensais.

Je peux distiller mon problème en six questions:

• Que se passe-t-il techniquement pendant un instantané et une sauvegarde, et en quoi sont-ils différents? (Si vous répondez à cette question, veuillez me dire si vous êtes en mesure de confirmer empiriquement votre réponse ou si vous me citez simplement de la documentation).
• Faut-il s'attendre à un pic de latence d'écriture pendant la fenêtre de sauvegarde sur un déploiement multi-AZ?
• Faut-il s'attendre à un pic de latence d'écriture à la fin d'un instantané sur un déploiement multi-AZ?
• Mon pic de latence en écriture serait-il encore plus élevé si je n'étais pas multi-AZ?
• Architecturalement, pourrais-je éviter ces pics de latence d'écriture si je roulais ma propre base de données sur deux instances m1.large EC2?
• Y a-t-il des configurations que je peux utiliser pour éviter ces pics de latence d'écriture tout en hébergeant ma base de données avec RDS, ou suis-je effectivement à la merci d'Amazon?

Question bonus: où et comment hébergez-vous votre base de données mysql?

Je peux dire que je suis généralement satisfait de RDS, sauf pour ces problèmes quotidiens de latence d'écriture. J'adore la surveillance de la base de données intégrée et c'était assez simple à configurer et à démarrer.

Merci!

Nous exécutons également plusieurs instances RDS, en plus de MySQL sur certaines machines que nous gérons nous-mêmes. Je ne peux pas faire de commentaire spécifique, car je ne suis pas un ingénieur Amazon, mais plusieurs choses que j'ai apprises pourraient expliquer ce que vous voyez:

• Bien qu'Amazon ne partage pas à 100% les détails du backend, nous soupçonnons fortement qu'ils utilisent leur système EBS pour sauvegarder les bases de données RDS.

• Cet article explique les limitations d'EBS et la fonctionnalité de snapshot http://blog.rightscale.com/2008/08/20/amazon-ebs-explained/ Encore une fois, même si ce n'est pas explicite, il serait logique qu'Amazon utilise cette infrastructure pour fournir des services RDS.

• En règle générale, une sauvegarde MySQL, contrairement à un instantané, implique l'utilisation d'un outil comme mysqldump pour créer un fichier d'instructions SQL qui reproduira ensuite la base de données. La base de données n'a pas besoin d'être gelée pour ce faire. Avec un backend EBS, la meilleure pratique consiste à geler la base de données (suspendre toutes les transactions) pendant que vous effectuez un instantané pour éviter la corruption des données.

• Les pics que vous voyez aux extrémités de la fenêtre de sauvegarde. Si la réplication est suspendue par Amazon pendant l'instantané de votre réplique, la réplique devra alors «rattraper» les transactions lorsque l'instantané est terminé. Cela provoquerait un pic de latence.

• La réplication sur un déploiement multi-AZ est intrinsèquement plus lente qu'un déploiement AZ unique. Le prix à payer pour une meilleure redondance.

Amazon a révélé l'architecture de base qu'ils utilisent dans les déploiements Multi AZ. Cela peut aider les gens à prendre des décisions

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