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 IOPS fourni.

En tant que DBA de la vieille école, je suis au courant de 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", "ajout d'IOPS fournies".

Essayé cela sur l'instance de test RDS, le temps d'indisponibilité est trop long, IMHO: environ 5 min pour une mise à niveau moyenne à petite, et 30 min (!!!) pour le passage à l'IOPS fourni.

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

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

Il semble exister 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 l'application de correctifs au système d'exploitation ou la mise à l'échelle d'instances de base de données, ces opérations sont d'abord appliquées en mode veille, avant le basculement automatique. Par conséquent, votre impact sur la disponibilité est limité au temps nécessaire à la réalisation du basculement automatique.

^{- http://aws.amazon.com/rds/multi-az/}

Cela devrait fournir une voie de migration rapide et transparente, bien que je n’aie pas eu l’occasion de tester cette capacité. "Modifier" dans la console apparaît pour vous permettre de convertir une instance en Multi-AZ. Cela entraînerait vraisemblablement un bref gel des entrées / sorties lors du clonage de l'instance. Je vous recommanderais donc 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 un esclave; promouvoir en maître; changer de client", ce qui devrait également vous permettre d'obtenir une conversion avec un 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ées
• 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 les coordonnées du journal binlog correspondant sur le maître et le réplica pour vous assurer que toutes les écritures d'application ont été répliquées.
• Fractionner les systèmes avec "Promouvoir la lecture du réplica" sur le nouveau réplica 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/

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

Il est également POSSIBLE d'éviter tout temps d'arrêt pendant la mise à niveau. Pour ce faire, lancez brièvement un nouveau RDS à partir d'un instantané de réplica en lecture et configurez-le en tant que réplication active / active de maître à maître. Une fois qu'il est configuré, vous pouvez basculer le trafic des applications sur un serveur APP à la fois sans interruption. Nous utilisons cette approche chaque fois qu'AWS annonce des maintenances RDS pour éviter les temps d'immobilisation, 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'Orignal

R1 - Réplique de lecture du M1

SNAP1 - Instantané de la R1

M2 - Nouveau Master

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 l' — master_data2option sur le M1. Au lieu de cela, nous lançons R1 pour obtenir la position binlog du M1 à partir de celui-ci. Créez ensuite un instantané (SNAP1) à partir du R1, puis lancez M2 à partir du SNAP1.

• Créez deux groupes de paramètres RDS distincts 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 du SNAP1 avec les attributs obtenus à partir de M1

• Affecter un groupe de paramètres à M2 avec un décalage auto_increment_ différent de M1 pour éviter les conflits de clé 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. Mise à niveau de M2 ​​via AWS Console

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

7. Effectuer une commutation en douceur sur M2

Une fois la réplication M / M configurée avec succès, nous sommes prêts à procéder à la maintenance de la base de données sans interruption de service en commutant 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

Cela fonctionnerait, mais vous devez vous assurer que les noeuds finaux 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 d'extrémité.