web-dev-qa-db-fra.com

Quelle est la façon optimale de mettre à niveau l'instance RDS de production?

J'ai une petite instance RDS MySQL dans le cadre de mon système de production et je souhaite la mettre à niveau vers une instance moyenne avec les IOPS fournis.

En tant que DBA à l'ancienne, je connais la méthode "ajouter un esclave; promouvoir en maître; changer de client", mais AWS promet de fournir un chemin de mise à niveau magique en un clic, c'est-à-dire "instance de mise à niveau", "ajouter les IOPS fournis".

J'ai essayé ceci sur une instance de test RDS, le temps d'arrêt est trop long, à mon humble avis: environ 5 min pour une mise à niveau petite-> moyenne et 30 min (!!!) pour passer aux IOPS fournis.

  • Est-ce un comportement normal?
  • Existe-t-il un moyen d'exécuter la mise à niveau sur le RDS de production sans interruption?
  • Recommandez-vous la méthode "arrêter; créer un instantané; restaurer à partir d'un instantané vers une instance plus grande"?
mysqlamazon-rds
35
Vitaly

La mise à niveau d'une instance dans RDS signifie que RDS migrera physiquement la base de données vers une nouvelle instance, probablement sur un hôte physique différent, de sorte que les temps d'arrêt ne seraient pas évitables. La migration vers des IOPS provisionnés signifierait probablement que vos données seraient migrées vers un nouveau volume EBS (et le serveur pourrait également être migré vers une nouvelle instance avec cette modification, selon que, en interne, les machines capables d'accéder aux volumes EBS avec des IOPS provisionnées sont physiquement séparés des machines qui ne le sont pas, afin qu'ils puissent être sur une classe différente de matériel réseau), de sorte que les temps d'arrêt seraient à nouveau inévitables.

Il semble y avoir un moyen d'éviter cette interruption: un déploiement Multi-AZ, qui crée une réplique invisible et inaccessible (pour vous) dans une autre zone de disponibilité de la région.

Dans le cas de mises à niveau du système telles que les correctifs du système d'exploitation ou la mise à l'échelle de l'instance DB, ces opérations sont appliquées en premier sur le standby, avant le basculement automatique. Par conséquent, votre impact sur la disponibilité est limité uniquement au temps requis pour que le basculement automatique se termine.

- http://aws.Amazon.com/rds/multi-az/

Cela devrait fournir un chemin de migration rapide et transparent, même si je n'ai pas eu l'occasion de tester cette capacité. "Modifier" dans la console apparaît pour vous permettre de convertir une instance en Multi-AZ. Vraisemblablement, cela entraînerait un bref gel des E/S lors du clonage de l'instance, je recommande donc bien sûr de tester toutes ces fonctionnalités avant de l'essayer.

Alternativement, RDS prend en charge un mécanisme interne qui devrait vous permettre d'émuler l'opération "ajouter esclave; promouvoir en maître; changer de client", et cela devrait également vous permettre d'obtenir une conversion de temps d'indisponibilité proche de zéro:

  • Créez une réplique de lecture RDS réelle de votre base de données avec la classe d'instance souhaitée
  • Attendez que la réplique soit en ligne et synchronisée avec le maître
  • Modifier la configuration de la réplique pour ajouter des IOPS provisionnés
  • Attendez que la réplique soit en ligne et synchronisée avec le maître
  • Vérifiez que les deux systèmes ont des données identiques à l'aide d'outils tiers
  • Déconnectez votre application de l'ancien maître
  • Vérifiez la correspondance des coordonnées binlog sur le maître et la réplique pour vous assurer que toutes les écritures d'application ont été répliquées
  • Fractionnez les systèmes avec "Promouvoir la réplique en lecture" sur la nouvelle réplique dans RDS
  • Connectez votre application au nouveau maître

http://aws.Amazon.com/about-aws/whats-new/2012/10/11/Amazon-rds-mysql-rr-promotion/

38
Michael - sqlbot

Même avec un environnement multi-AZ, vous aurez un 60-120s de panne. Ce fut le cas lorsque j'ai frappé à plusieurs reprises nos instances RDS lors d'une mise à niveau d'un PostgreSQL db.m3.medium vers un db .m3.large.

4
Wayn E

Il est également POSSIBLE d'éviter tout temps d'arrêt pendant la mise à niveau. La façon de le faire est de lancer brièvement un nouveau RDS à partir d'un instantané de réplique de lecture et de le configurer comme réplication active/active de maître à maître. Une fois qu'il est configuré, vous pouvez basculer le trafic d'application sur un serveur APP à la fois sans aucun temps d'arrêt. Nous utilisons l'approche chaque fois qu'AWS annonce des maintenances RDS pour éviter les temps d'arrêt ainsi que pendant nos maintenances planifiées.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Voici les détails:

M1 - Maître d'origine

R1 - Lecture de la réplique du M1

SNAP1 - Instantané du R1

M2 - Nouveau maître

Séquence de création M2: M1 → R1 → SNAP1 → M2

  • Comme nous ne pouvons pas utiliser le privilège SUPER sur RDS, nous n'utilisons pas mysqldump avec — master_data2 option sur le M1. Au lieu de cela, nous lançons R1 pour en obtenir la position binlog du M1 . Créez ensuite un instantané (SNAP1) à partir du R1, puis lancez M2 à partir du SNAP1.

  • Créez deux groupes de paramètres RDS séparés avec les décalages suivants pour éviter les conflits PK:

    M1: auto_increment_ increment = 4 and auto_increment_offset = 1

    M2: auto_increment_ increment = 4 and auto_increment_offset = 2

  • Créer un utilisateur de réplication sur M1

    GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. Créer R1 à partir de M1 

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. Créer SNAP1 à partir de R1

  • Créer M2 à partir de SNAP1 avec les attributs obtenus à partir de M1

  • Affectez un groupe de paramètres à M2 avec un décalage auto_increment_ différent de M1 pour éviter les conflits de clés de réplication M/M

4. Configurer la réplication M/M 

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master ('m1.xyxy24.us-east-1.rds.amazonaws.com', 3306, 'repl', 'mypassword', 'mysql-bin.000622', 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master ('m2.xyxy24.us-east-1.rds.amazonaws.com', 3306 , 'repl', 'mypassword', 'mysql-bin.004444', 6666622, 0);
CALL mysql.rds_start_replication;

5. Supprimez R1 et SNAP1 car ils ne sont plus nécessaires

6. Mettre à niveau M2 via AWS Console

Utilisez la procédure standard pour modifier l'instance selon vos besoins.

7. Effectuez une transition gracieuse vers M2

Comme la réplication M/M est configurée avec succès, nous sommes prêts à procéder à la maintenance de la base de données sans temps d'arrêt en changeant gracieusement les serveurs d'applications un à la fois.

Voici plus de détails sur son fonctionnement.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

3
Dmitriy Royzenberg

Cela fonctionnerait, mais vous devez vous assurer que les points de terminaison de l'instance RDS ne sont pas configurés dans votre application en tant qu'entrée statique. L'échange de RDS changera les points de terminaison.

1
Anup Singh