Redémarrage d'un cluster de bases de données Amazon Aurora ou d'une instance de base de données Amazon Aurora - Amazon Aurora

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Redémarrage d'un cluster de bases de données Amazon Aurora ou d'une instance de base de données Amazon Aurora

Vous devrez peut-être redémarrer votre cluster de bases de données ou certaines instances du cluster, généralement pour des raisons de maintenance. Par exemple, supposons que vous modifiiez les paramètres d'un groupe de paramètres ou que vous associiez un autre groupe de paramètres à votre cluster. Dans ce cas, vous devez redémarrer le cluster pour que les modifications prennent effet. De même, vous pouvez redémarrer une ou plusieurs instance de base de données du lecteur au sein du cluster. Vous pouvez organiser les opérations de redémarrage pour des instances individuelles afin de réduire les temps d'arrêt pour l'ensemble du cluster.

Le temps nécessaire au redémarrage de chaque instance de base de données de votre cluster dépend de l'activité de la base de données au moment du redémarrage. Il dépend également du processus de récupération de votre moteur de base de données spécifique. Si c'est pratique, réduisez l'activité de la base de données sur cette instance particulière avant de démarrer le processus de redémarrage. Cela peut réduire le temps nécessaire au redémarrage de la base de données.

Vous ne pouvez redémarrer chaque instance de base de données de votre cluster que lorsque celle-ci est à l'état disponible. Une instance de base de données peut être indisponible pour plusieurs raisons. Il s'agit notamment des situations suivantes : le cluster est à d'arrêt, une modification est appliquée à l'instance et une action de fenêtre de maintenance telle qu'une mise à niveau de version se produit.

Le redémarrage d'une instance de base de données entraîne celui du processus du moteur de base de données. Le redémarrage d'une instance de bases de données entraîne une interruption momentanée, au cours de laquelle le statut de l'instance de bases de données est défini sur redémarrage.

Note

Si une instance de base de données n'utilise pas les dernières modifications apportées à son groupe de paramètres de base de données associé, AWS Management Console affiche le groupe de paramètres de base de données avec le statut suivant : pending-reboot. Le statut de groupe de paramètres pending-reboot n'entraîne pas de redémarrage automatique lors de la fenêtre de maintenance suivante. Pour appliquer les modifications de paramètre les plus récentes apportées à cette instance de base de données, vous devez la redémarrer manuellement. Pour plus d'informations sur les groupes de paramètres, consultez Utilisation des groupes de paramètres.

Redémarrage d'une instance de base de données au sein d'un cluster Aurora

Cette procédure est l'opération la plus importante que vous effectuez lorsque vous effectuez des redémarrages avec Aurora. La plupart des procédures de maintenance impliquent le redémarrage d'une ou de plusieurs instances de base de données Aurora dans un ordre particulier.

Pour redémarrer une instance de base de données
  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Bases de données, puis l'instance de base de données à redémarrer.

  3. Pour Actions, choisissez Redémarrer.

    La page Redémarrer l'instance de bases de données s'affiche.

  4. Choisissez Redémarrer pour redémarrer votre instance de bases de données.

    Ou choisissez Cancel (Annuler).

Pour redémarrer une instance de bases de données à l'aide de l'AWS CLI, appelez la commande reboot-db-instance.

Pour LinuxmacOS, ou Unix :

aws rds reboot-db-instance \ --db-instance-identifier mydbinstance

Dans Windows :

aws rds reboot-db-instance ^ --db-instance-identifier mydbinstance

Pour redémarrer une instance de base de données à l'aide de l'API Amazon RDS, appelez l'opération RebootDBInstance.

Redémarrage d'un cluster Aurora avec disponibilité en lecture

Grâce à la fonctionnalité de disponibilité en lecture, vous pouvez redémarrer l'instance d'enregistreur de votre cluster Aurora sans redémarrer les instances de lecteur dans le cluster. Cela peut contribuer à maintenir une haute disponibilité du cluster pour les opérations de lecture pendant que vous redémarrez l'instance d'enregistreur. Vous pouvez redémarrer les instances de lecteur plus tard, selon un calendrier qui vous convient. Par exemple, dans le cas d'un cluster de production, vous pouvez redémarrer les instances de lecteur une par une, en commençant uniquement une fois le redémarrage de l'instance principale terminé. Pour chaque instance de base de données que vous redémarrez, suivez la procédure décrite dans Redémarrage d'une instance de base de données au sein d'un cluster Aurora.

La fonctionnalité de disponibilité en lecture est disponible dans Aurora MySQL 2.10 et versions supérieures.

Pour Aurora PostgreSQL, cette fonctionnalité est disponible par défaut dans les versions suivantes :

  • Versions 15.2 et 15 ultérieures

  • Versions 14.7 et 14 ultérieures

  • Versions 13.10 et 13 ultérieures

  • Versions 12.14 et 12 ultérieures

Pour plus d'informations sur la fonctionnalité de disponibilité en lecture dans Aurora PostgreSQL, consultez Amélioration de la disponibilité en lecture des réplicas Aurora.

Avant cette fonctionnalité, le redémarrage de l'instance principale entraînait un redémarrage de chaque instance de lecteur au même moment. Si votre cluster Aurora exécute une version plus ancienne, utilisez plutôt la procédure de redémarrage dans Redémarrage d'un cluster Aurora sans disponibilité en lecture.

Important

La modification du comportement de redémarrage dans le cluster Aurora avec fonctionnalité de disponibilité en lecture est différente pour les bases de données globales Aurora. Si vous redémarrez l'instance d'enregistreur pour le cluster principal dans une base de données globale Aurora, les instances de lecteur du cluster principal restent disponibles. Toutefois, les instances de base de données de tous les clusters secondaires redémarrent en même temps.

Vous redémarrez fréquemment le cluster après avoir apporté des modifications aux groupes de paramètres du cluster. Vous modifiez les paramètres en suivant les procédures décrites dans Utilisation des groupes de paramètres. Supposons que vous redémarriez l'instance de base de données d'enregistreur dans un cluster Aurora pour appliquer des modifications aux paramètres du cluster. Certaines ou toutes les instances de base de données de lecteur peuvent continuer à utiliser les anciens paramètres. Toutefois, les différents paramètres de paramètres n'affectent pas l'intégrité des données du cluster. Tous les paramètres de cluster qui affectent l'organisation des fichiers de données sont uniquement utilisés par l'instance de base de données d'enregistreur.

Par exemple, dans un cluster Aurora MySQL, vous pouvez mettre à jour des paramètres de cluster tels que binlog_format et innodb_purge_threads sur l'instance d'enregistreur avant les instances de lecteur. Seule l'instance d'enregistreur écrit des journaux binaires et purge les enregistrements d'annulation. Pour les paramètres qui modifient la façon dont les requêtes interprètent les instructions SQL ou la sortie de requête, vous devrez peut-être redémarrer immédiatement les instances de lecteur. Vous procédez de cette façon pour éviter tout comportement inattendu de l'application lors des requêtes. Par exemple, supposons que vous modifiiez le paramètre lower_case_table_names et que vous redémarriez l'instance d'enregistreur. Dans ce cas, il se peut que les instances de lecteur ne puissent pas accéder à une table récemment créée tant qu'elles n'ont pas toutes été redémarrées.

Pour obtenir la liste de tous les paramètres du cluster Aurora MySQL, veuillez consulter Paramètres de niveau cluster.

Pour obtenir la liste de tous les paramètres de cluster Aurora PostgreSQL, consultez Paramètres de niveau cluster d'Aurora PostgreSQL.

Astuce

Aurora MySQL peut encore redémarrer certaines instances de lecteur avec l'instance d'enregistreur si votre cluster traite une application à haut débit.

La réduction du nombre de redémarrages s'applique également lors des opérations de basculement. Lors d'un basculement, Aurora MySQL redémarre uniquement l'instance de base de données du scripteur et la cible de basculement. D'autres instances de bases de données de lecteur dans le cluster restent disponibles pour continuer le traitement des requêtes par le biais de connexions au point de terminaison du lecteur. Vous pouvez donc améliorer la disponibilité lors d'un basculement en disposant de plusieurs instances de base de données de lecteur dans un cluster.

Redémarrage d'un cluster Aurora sans disponibilité en lecture

Grâce à la fonctionnalité de disponibilité en lecture, vous redémarrez un cluster de bases de données Aurora complet en redémarrant l'instance de base de données d'enregistreur de ce cluster. Pour ce faire, suivez la procédure décrite dans Redémarrage d'une instance de base de données au sein d'un cluster Aurora.

Le redémarrage de l'instance de base de données d'enregistreur déclenche également un redémarrage pour chaque instance de base de données d'enregistreur dans le cluster. De cette façon, tous les changements de paramètres à l'échelle du cluster sont appliqués simultanément à toutes les instances de base de données. Toutefois, le redémarrage de toutes les instances de base de données entraîne une brève interruption du cluster. Les instances de base de données de lecteur restent indisponibles jusqu'à ce que l'instance de base de données d'enregistreur ait fini de redémarrer et soit disponible.

Ce comportement de redémarrage s'applique à tous les clusters de bases de données créés dans Aurora MySQL version 2.09 et antérieures.

Pour Aurora PostgreSQL, ce comportement s'applique aux versions suivantes :

  • Version 14.6 et versions 14 antérieures

  • Version 13.9 et versions 13 antérieures

  • Version 12.13 et versions 12 antérieures

  • Toutes les versions de PostgreSQL 11

Dans la console RDS, l'instance de base de données d'enregistreur a la valeur Writer (Enregistreur ) sous la colonneRole (Rôle) de la page Databases (Bases de données). Dans l'interface de ligne de commande CLI RDS, la sortie de la commande describe-db-clusters comprend une section DBClusterMembers. L'élément DBClusterMembers représentant l'instance de base de données d'enregistreur a la valeur true du champ IsClusterWriter.

Important

Avec la fonctionnalité de disponibilité en lecture, le comportement de redémarrage est différent dans Aurora MySQL et Aurora PostgreSQL : les instances de base de données de lecteur restent généralement disponibles pendant que vous redémarrez l'instance d'enregistreur. Vous pouvez ensuite redémarrer les instances de lecteur à un moment opportun. Vous pouvez redémarrer les instances de lecteur selon un calendrier échelonné si vous souhaitez que certaines de ses instances soient toujours disponibles. Pour plus d'informations, consultez Redémarrage d'un cluster Aurora avec disponibilité en lecture.

Vérification de la disponibilité des clusters et des instances Aurora

Vous pouvez vérifier et surveiller la durée écoulé depuis le dernier redémarrage de chaque instance de base de données de votre cluster Aurora. La CloudWatch métrique Amazon EngineUptime indique le nombre de secondes écoulées depuis le dernier démarrage d'une instance de base de données. Vous pouvez examiner cette métrique à un moment donné pour connaître le temps de disponibilité de l'instance de base de données. Vous pouvez également contrôler cette métrique au fil du temps pour détecter le moment où l'instance est redémarrée.

Vous pouvez également examiner la métrique EngineUptime au niveau du cluster. Les dimensions Minimum et Maximum indiquent les valeurs de disponibilité les plus petites et les plus importantes pour toutes les instances de base de données du cluster. Pour vérifier le moment le plus récent où une instance du lecteur d'un cluster a été redémarrée, ou a été redémarrée pour une autre raison, contrôlez la métrique au niveau du cluster à l'aide de la dimension Minimum. Pour vérifier quelle instance du cluster est restée le plus longtemps sans redémarrage, contrôlez la métrique au niveau du cluster à l'aide de la dimension Maximum. Par exemple, vous pouvez confirmer que toutes les instances de base de données du cluster ont été redémarrées après une modification de la configuration.

Astuce

Pour la surveillance à long terme, nous recommandons de contrôler la métrique EngineUptime pour des instances individuelles, plutôt qu'au niveau du cluster. La métrique EngineUptime au niveau du cluster est définie sur zéro lorsqu'une nouvelle instance de base de données est ajoutée au cluster. Ces modifications de cluster peuvent se produire dans le cadre d'opérations de maintenance et de mise à l'échelle, telles que celles effectuées par Auto Scaling.

Les exemples d'interface de ligne de commande CLI suivants montrent comment examiner la métrique EngineUptime pour les instances d'enregistreur et de lecteur dans un cluster. Les exemples utilisent un cluster nommé tpch100g. Ce cluster possède une instance de base de données d'enregistreur instance-1234. Il dispose également de deux instances de base de données de lecteur, instance-7448 etinstance-6305.

Tout d'abord, la commande reboot-db-instance redémarre l'une des instances de lecteur. La commande wait attend que le redémarrage de l'instance soit terminé.

$ aws rds reboot-db-instance --db-instance-identifier instance-6305 { "DBInstance": { "DBInstanceIdentifier": "instance-6305", "DBInstanceStatus": "rebooting", ... $ aws rds wait db-instance-available --db-instance-id instance-6305

La CloudWatch get-metric-statistics commande examine la EngineUptime métrique au cours des cinq dernières minutes à intervalles d'une minute. Le temps de disponibilité de l'instance instance-6305 est remis à zéro et recommence un compte à rebours. Cet exemple d'AWS CLI pour Linux utilise la substitution de variable $() pour insérer les horodatages appropriés dans les commandes CLI. Il utilise également la commande sort Linux pour ordonner la sortie au moment où la métrique a été collectée. Cette valeur d'horodatage est le troisième champ de chaque ligne de sortie.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 231.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 291.0 2021-03-16T18:20:00+00:00 Seconds DATAPOINTS 351.0 2021-03-16T18:21:00+00:00 Seconds DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds

La durée de disponibilité minimale du cluster est remise à zéro, car l'une des instances du cluster a été redémarrée. La durée de disponibilité maximale du cluster n'est pas réinitialisée, car au moins une des instances de base de données du cluster est restée disponible.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Minimum \ --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63099.0 2021-03-16T18:12:00+00:00 Seconds DATAPOINTS 63159.0 2021-03-16T18:13:00+00:00 Seconds DATAPOINTS 63219.0 2021-03-16T18:14:00+00:00 Seconds DATAPOINTS 63279.0 2021-03-16T18:15:00+00:00 Seconds DATAPOINTS 51.0 2021-03-16T18:16:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63389.0 2021-03-16T18:16:00+00:00 Seconds DATAPOINTS 63449.0 2021-03-16T18:17:00+00:00 Seconds DATAPOINTS 63509.0 2021-03-16T18:18:00+00:00 Seconds DATAPOINTS 63569.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 63629.0 2021-03-16T18:20:00+00:00 Seconds

Ensuite, une autre commande reboot-db-instance redémarre l'instance d'enregistreur du cluster. Une autre commande wait s'arrête jusqu'à ce que l'instance d'enregistreur ait terminé le redémarrage.

$ aws rds reboot-db-instance --db-instance-identifier instance-1234 { "DBInstanceIdentifier": "instance-1234", "DBInstanceStatus": "rebooting", ... $ aws rds wait db-instance-available --db-instance-id instance-1234

La métrique EngineUptimede l'instance d'enregistreur indique désormais que l'instance instance-1234 a été redémarrée récemment. L'instance de lecteur instance-6305 a également été redémarrée automatiquement avec l'instance d'enregistreur. Ce cluster exécute Aurora MySQL 2.09, ce qui ne permet pas de maintenir les instances de lecteur en cours d'exécution au redémarrage de l'instance d'enregistreur.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \ | sort -k 3 EngineUptime DATAPOINTS 63749.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 63809.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 63869.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 41.0 2021-03-16T18:25:00+00:00 Seconds DATAPOINTS 101.0 2021-03-16T18:26:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \ --period 60 --namespace "AWS/RDS" --statistics Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 531.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 49.0 2021-03-16T18:26:00+00:00 Seconds

Exemples d'opérations de redémarrage Aurora

Les exemples Aurora MySQL suivants illustrent différentes combinaisons d'opérations de redémarrage pour les instances de base de données de lecteur et d'enregistreur dans un cluster de bases de données Aurora. Après chaque redémarrage, les requêtes SQL indiquent le temps de disponibilité des instances du cluster.

Recherche des instances d'enregistreur et de lecteur pour un cluster Aurora

Dans un cluster Aurora MySQL comportant plusieurs instances de base de données, il est important de savoir laquelle est l'enregistreur et lesquelles sont les lecteurs. Les instances d'enregistreur et de lecteur peuvent également changer de rôle lorsqu'une opération de basculement se produit. Il est donc préférable d'effectuer une vérification telle que la suivante avant d'effectuer toute opération nécessitant une instance d'enregistreur ou de lecteur. Dans ce cas, les valeurs False pour IsClusterWriter identifient les instances de lecteur instance-6305 etinstance-7448. La valeur True identifie l'instance d'enregistreur instance-1234.

$ aws rds describe-db-clusters --db-cluster-id tpch100g \ --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \ --output text Cluster: tpch100g Instance: instance-6305 False Instance: instance-7448 False Instance: instance-1234 True

Avant d'entamer les exemples de redémarrage, l'instance d'enregistreur a un temps de disponibilité d'environ une semaine. La requête SQL de cet exemple montre un moyen spécifique à MySQL de vérifier la disponibilité. Vous pouvez utiliser cette technique dans une application de base de données. Pour une autre technique qui utilise l'AWS CLI et fonctionne pour les deux moteurs Aurora, consultez Vérification de la disponibilité des clusters et des instances Aurora.

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status -> where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-08 17:49:06.000000 | 174h 42m| +----------------------------+---------+

Redémarrage d'une instance de lecteur unique

Cet exemple montre comment redémarrer l'une des instances de base de données de lecteur. Peut-être que cette instance a été surchargée par une requête trop importante ou par de nombreuses connexions simultanées. Elle est peut-être également restée derrière l'instance d'enregistreur en raison d'un problème de réseau. Après le lancement de l'opération de redémarrage, l'exemple utilise une commande wait pour effectuer une mise en pause jusqu'à ce que l'instance soit disponible. À ce moment-là, le temps de disponibilité de l'instance est de quelques minutes.

$ aws rds reboot-db-instance --db-instance-identifier instance-6305 { "DBInstance": { "DBInstanceIdentifier": "instance-6305", "DBInstanceStatus": "rebooting", ... } } $ aws rds wait db-instance-available --db-instance-id instance-6305 $ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status -> where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:35:02.000000 | 00h 03m | +----------------------------+---------+

Le redémarrage de l'instance de lecteur n'a pas affecté le temps de disponibilité de l'instance d'enregistreur. Elle a encore un temps de disponibilité d'environ une semaine.

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+----------+ | Last Startup | Uptime | +----------------------------+----------+ | 2021-03-08 17:49:06.000000 | 174h 49m | +----------------------------+----------+

Redémarrage de l'instance d'enregistreur

Cet exemple montre comment redémarrer l'instance d'enregistreur. Ce cluster exécute Aurora MySQL version 2.09. Étant donné que la version de Aurora MySQL est inférieure à la version 2.10, le redémarrage de l'instance d'enregistreur redémarre également toutes les instances de lecteur du cluster.

Une commande wait s'arrête jusqu'à ce que le redémarrage soit terminé. Le temps de disponibilité de cette instance est maintenant remis à zéro. Il est possible qu'une opération de redémarrage prenne des temps sensiblement différents pour les instances de base de données d'enregistreur et de lecteur. Les instances de base de données d'enregistreur et de lecteur effectuent différents types d'opérations de nettoyage en fonction de leurs rôles.

$ aws rds reboot-db-instance --db-instance-identifier instance-1234 { "DBInstance": { "DBInstanceIdentifier": "instance-1234", "DBInstanceStatus": "rebooting", ... } } $ aws rds wait db-instance-available --db-instance-id instance-1234 $ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:27.000000 | 00h 00m | +----------------------------+---------+

Après le redémarrage de l'instance de base de données d'enregistreur, les deux instances de base de données de lecteur ont également réinitialisé leur temps de disponibilité. Le redémarrage de l'instance d'enregistreur a également provoqué le redémarrage des instances de lecteur. Ce comportement s'applique aux clusters Aurora PostgreSQL et aux clusters Aurora MySQL antérieurs à la version 2.10.

$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:35.000000 | 00h 00m | +----------------------------+---------+ $ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p ... mysql> select date_sub(now(), interval variable_value second) "Last Startup", -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime" -> from performance_schema.global_status where variable_name='Uptime'; +----------------------------+---------+ | Last Startup | Uptime | +----------------------------+---------+ | 2021-03-16 00:40:33.000000 | 00h 01m | +----------------------------+---------+

Redémarrage indépendant de l'enregistreur et des lecteurs

Les exemples suivants montrent un cluster exécutant Aurora MySQL version 2.10. Dans cette version d'Aurora MySQL et les versions ultérieures, vous pouvez redémarrer l'instance d'enregistreur sans provoquer de redémarrage pour toutes les instances de lecteur. De cette façon, vos applications exigeantes en requêtes ne subissent aucune panne lorsque vous redémarrez l'instance d'enregistreur. Vous pouvez redémarrer les instances de lecteur ultérieurement. Vous pouvez effectuer ces redémarrages à un moment où le trafic de requêtes est faible. Vous pouvez également redémarrer les instances de lecteur une par une. De cette façon, au moins une instance de lecteur est toujours disponible pour le trafic de requêtes de votre application.

L'exemple suivant utilise un cluster nommé cluster-2393 exécutant Aurora MySQL version 5.7.mysql_aurora.2.10.0. Ce cluster possède une instance d'enregistreur nommée instance-9404 et trois instances de lecteur nommées instance-6772 instance-2470 et instance-5138.

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \ --query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \ --output text Cluster: cluster-2393 Instance: instance-5138 False Instance: instance-2470 False Instance: instance-6772 False Instance: instance-9404 True

La vérification de la valeur uptime de chaque instance de base de données à l'aide de la commande mysql montre que chacune a à peu près le même temps de disponibilité. Par exemple, voici le temps de disponibilité pour instance-5138.

mysql> SHOW GLOBAL STATUS LIKE 'uptime'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Uptime | 3866 | +---------------+-------+

En utilisant CloudWatch, nous pouvons obtenir les informations de disponibilité correspondantes sans réellement nous connecter aux instances. De cette façon, un administrateur peut contrôler la base de données, mais il ne peut ni afficher ni modifier aucune donnée de table. Dans ce cas, nous spécifions une période de cinq minutes et nous vérifions la valeur du temps de disponibilité à chaque minute. Les valeurs de temps de disponibilité croissantes démontrent que les instances n'ont pas été redémarrées au cours de cette période.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4648.0 2021-03-17T23:42:00+00:00 Seconds DATAPOINTS 4708.0 2021-03-17T23:43:00+00:00 Seconds DATAPOINTS 4768.0 2021-03-17T23:44:00+00:00 Seconds DATAPOINTS 4828.0 2021-03-17T23:45:00+00:00 Seconds DATAPOINTS 4888.0 2021-03-17T23:46:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4315.0 2021-03-17T23:42:00+00:00 Seconds DATAPOINTS 4375.0 2021-03-17T23:43:00+00:00 Seconds DATAPOINTS 4435.0 2021-03-17T23:44:00+00:00 Seconds DATAPOINTS 4495.0 2021-03-17T23:45:00+00:00 Seconds DATAPOINTS 4555.0 2021-03-17T23:46:00+00:00 Seconds

Maintenant, nous redémarrons l'une des instances de lecteu, instance-5138. Nous attendons que l'instance soit de nouveau disponible après le redémarrage. À présent, la surveillance du temps de disponibilité sur une période de cinq minutes montre que ce dernier a été remis à zéro pendant cette période. La valeur de disponibilité la plus récente a été mesurée cinq secondes après la fin du redémarrage.

$ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-5138 $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \ --output text | sort -k 3 EngineUptime DATAPOINTS 4500.0 2021-03-17T23:46:00+00:00 Seconds DATAPOINTS 4560.0 2021-03-17T23:47:00+00:00 Seconds DATAPOINTS 4620.0 2021-03-17T23:48:00+00:00 Seconds DATAPOINTS 4680.0 2021-03-17T23:49:00+00:00 Seconds DATAPOINTS 5.0 2021-03-17T23:50:00+00:00 Seconds

Ensuite, nous effectuons un redémarrage pour l'instance d'enregistreur, instance-9404. Nous comparons les valeurs de temps de disponibilité de l'instance d'enregistreur et de l'une des instances de lecteur. Ce faisant, nous pouvons constater que le redémarrage de l'enregistreur n'a pas provoqué de redémarrage pour les lecteurs. Dans les versions antérieures à la version Aurora MySQL 2.10, les valeurs de temps de disponibilité de tous les lecteurs seraient réinitialisées en même temps que pour l'enregistreur.

$ aws rds reboot-db-instance --db-instance-identifier instance-9404 { "DBInstanceIdentifier": "instance-9404", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-9404 $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 371.0 2021-03-17T23:57:00+00:00 Seconds DATAPOINTS 431.0 2021-03-17T23:58:00+00:00 Seconds DATAPOINTS 491.0 2021-03-17T23:59:00+00:00 Seconds DATAPOINTS 551.0 2021-03-18T00:00:00+00:00 Seconds DATAPOINTS 37.0 2021-03-18T00:01:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \ --output text | sort -k 3 EngineUptime DATAPOINTS 5215.0 2021-03-17T23:57:00+00:00 Seconds DATAPOINTS 5275.0 2021-03-17T23:58:00+00:00 Seconds DATAPOINTS 5335.0 2021-03-17T23:59:00+00:00 Seconds DATAPOINTS 5395.0 2021-03-18T00:00:00+00:00 Seconds DATAPOINTS 5455.0 2021-03-18T00:01:00+00:00 Seconds

Pour vous assurer que toutes les instances de lecteur ont toutes les mêmes modifications apportées aux paramètres de configuration que l'instance d'enregistreur, redémarrez toutes les instances de lecteur après l'enregistreur. Cet exemple redémarre tous les lecteurs, puis attend qu'ils soient tous disponibles avant de continuer.

$ aws rds reboot-db-instance --db-instance-identifier instance-6772 { "DBInstanceIdentifier": "instance-6772", "DBInstanceStatus": "rebooting" } $ aws rds reboot-db-instance --db-instance-identifier instance-2470 { "DBInstanceIdentifier": "instance-2470", "DBInstanceStatus": "rebooting" } $ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-6772 $ aws rds wait db-instance-available --db-instance-id instance-2470 $ aws rds wait db-instance-available --db-instance-id instance-5138

Nous pouvons maintenant constater que l'instance de base de données d'enregistreur a le temps de disponibilité le plus élevé. La valeur de temps de disponibilité de cette instance a augmenté régulièrement tout au long de la période de surveillance. Les instances de base de données du lecteur ont toutes été redémarrées après le lecteur. Nous pouvons voir le moment où chaque lecteur a été redémarré et où son temps de disponibilité a été remis à zéro pendant la période de surveillance.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \ --output text | sort -k 3 EngineUptime DATAPOINTS 457.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 517.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 577.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 637.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 697.0 2021-03-18T00:12:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \ --output text | sort -k 3 EngineUptime DATAPOINTS 5819.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 35.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 95.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 155.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 215.0 2021-03-18T00:12:00+00:00 Seconds $ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \ --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \ --output text | sort -k 3 EngineUptime DATAPOINTS 1085.0 2021-03-18T00:08:00+00:00 Seconds DATAPOINTS 1145.0 2021-03-18T00:09:00+00:00 Seconds DATAPOINTS 1205.0 2021-03-18T00:10:00+00:00 Seconds DATAPOINTS 49.0 2021-03-18T00:11:00+00:00 Seconds DATAPOINTS 109.0 2021-03-18T00:12:00+00:00 Seconds

Application d'une modification de paramètre de cluster à un cluster Aurora MySQL version 2.10

L'exemple suivant montre comment appliquer une modification de paramètre à toutes les instances de base de données de votre cluster Aurora MySQL 2.10. Avec cette version d'Aurora MySQL, vous redémarrez indépendamment l'instance d'enregistreur et toutes les instances de lecteur.

L'exemple utilise le paramètre de configuration de MySQL lower_case_table_names à titre d'illustration. Lorsque ce paramètre est différent entre les instances de base de données d'enregistreur et de lecteur, il se peut qu'une requête ne soit pas en mesure d'accéder à une table déclarée avec un nom en majuscules ou à casse mixte. Ou, si deux noms de table ne diffèrent que par des majuscules et des minuscules, une requête peut accéder à la mauvaise table.

Cet exemple montre comment déterminer les instances d'enregistreur et de lecteur dans le cluster en examinant l'attribut IsClusterWriter de chaque instance. Le cluster se nomme cluster-2393. Le cluster possède une instance d'enregistreur nommée instance-9404. Les instances de lecteur du cluster sont nommées instance-5138 et instance-2470.

$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \ --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \ --output text cluster-2393 instance-5138 False instance-2470 False instance-9404 True

Pour démontrer les effets de la modification du paramètre lower_case_table_names, nous avons configuré deux groupes de paramètres de cluster de bases de données. Ce paramètre est défini sur 0 pour le groupe de paramètres lower-case-table-names-0. Le groupe de paramètres lower-case-table-names-1 est défini sur 1.

$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \ --db-parameter-group-family aurora-mysql5.7 \ --db-cluster-parameter-group-name lower-case-table-names-0 { "DBClusterParameterGroup": { "DBClusterParameterGroupName": "lower-case-table-names-0", "DBParameterGroupFamily": "aurora-mysql5.7", "Description": "lower-case-table-names-0" } } $ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \ --db-parameter-group-family aurora-mysql5.7 \ --db-cluster-parameter-group-name lower-case-table-names-1 { "DBClusterParameterGroup": { "DBClusterParameterGroupName": "lower-case-table-names-1", "DBParameterGroupFamily": "aurora-mysql5.7", "Description": "lower-case-table-names-1" } } $ aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name lower-case-table-names-0 \ --parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "lower-case-table-names-0" } $ aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name lower-case-table-names-1 \ --parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "lower-case-table-names-1" }

La valeur par défaut de lower_case_table_names est 0. Avec ce paramètre, la table foo est distincte de la table FOO. Cet exemple vérifie que le paramètre est toujours à sa valeur par défaut. Ensuite, l'exemple crée trois tables qui ne diffèrent que par des lettres majuscules et minuscules dans leur nom.

mysql> create database lctn; Query OK, 1 row affected (0.07 sec) mysql> use lctn; Database changed mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 0 | +--------------------------+ mysql> create table foo (s varchar(128)); mysql> insert into foo values ('Lowercase table name foo'); mysql> create table Foo (s varchar(128)); mysql> insert into Foo values ('Mixed-case table name Foo'); mysql> create table FOO (s varchar(128)); mysql> insert into FOO values ('Uppercase table name FOO'); mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +---------------------------+ | s | +---------------------------+ | Mixed-case table name Foo | +---------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Uppercase table name FOO | +--------------------------+

Ensuite, nous associons le groupe de paramètres de base de données au cluster pour définir le paramètre lower_case_table_names sur 1. Cette modification ne prend effet qu'après le redémarrage de chaque instance de base de données.

$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \ --db-cluster-parameter-group-name lower-case-table-names-1 { "DBClusterIdentifier": "cluster-2393", "DBClusterParameterGroup": "lower-case-table-names-1", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.0" }

Le premier redémarrage que nous effectuons concerne l'instance de base de données d'enregistreur. Ensuite, nous attendons que l'instance soit de nouveau disponible. À ce stade, nous nous connectons au point de terminaison de l'enregistreur et vérifions que l'instance d'enregistreur présente la valeur du paramètre modifiée. La commande SHOW TABLES confirme que la base de données contient les trois tables différentes. Toutefois, les requêtes qui font référence à des tables nommées foo, Foo ou FOO accèdent toutes à la table dont le nom est entièrement en minuscules, foo.

# Rebooting the writer instance $ aws rds reboot-db-instance --db-instance-identifier instance-9404 $ aws rds wait db-instance-available --db-instance-id instance-9404

Désormais, les requêtes utilisant le point de terminaison du cluster montrent les effets de la modification de paramètre. Que le nom de table de la requête soit en majuscules, en minuscules ou en casse mixte, l'instruction SQL accède à la table dont le nom est entièrement en minuscules.

mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 1 | +--------------------------+ mysql> use lctn; mysql> show tables; +----------------+ | Tables_in_lctn | +----------------+ | FOO | | Foo | | foo | +----------------+ mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+

L'exemple suivant montre les mêmes requêtes que le précédent. Dans ce cas, les requêtes utilisent le point de terminaison du lecteur et s'exécutent sur l'une des instances de base de données de lecteur. Ces instances n'ont pas encore été redémarrées. Ainsi, elles ont toujours le réglage d'origine du paramètre lower_case_table_names. Cela signifie que les requêtes peuvent accéder à chacune des tables foo, Foo et FOO.

mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 0 | +--------------------------+ mysql> use lctn; mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +---------------------------+ | s | +---------------------------+ | Mixed-case table name Foo | +---------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Uppercase table name FOO | +--------------------------+

Ensuite, nous redémarrons l'une des instances de lecteur et nous attendons qu'elle soit à nouveau disponible.

$ aws rds reboot-db-instance --db-instance-identifier instance-2470 { "DBInstanceIdentifier": "instance-2470", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-2470

Lorsqu'elle est connectée au point de terminaison de l'instance pour instance-2470, une requête indique que le nouveau paramètre est en vigueur.

mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 1 | +--------------------------+

À ce stade, les deux instances de lecteur du cluster sont exécutées avec des paramètres lower_case_table_names différents. Ainsi, toute connexion au point de terminaison du lecteur du cluster utilise une valeur imprévisible pour ce paramètre. Il est important de redémarrer immédiatement l'autre instance de lecteur afin qu'elles aient toutes les deux des paramètres cohérents.

$ aws rds reboot-db-instance --db-instance-identifier instance-5138 { "DBInstanceIdentifier": "instance-5138", "DBInstanceStatus": "rebooting" } $ aws rds wait db-instance-available --db-instance-id instance-5138

L'exemple suivant confirme que toutes les instances de lecteur ont le même paramètre lower_case_table_names. Les commandes vérifient la valeur du paramètre lower_case_table_names sur chaque instance de lecteur. Ensuite, la même commande utilisant le point de terminaison de lecteur montre que chaque connexion au point de terminaison du lecteur utilise l'une des instances de lecteur, mais il n'est pas possible de prévoir laquelle.

# Check lower_case_table_names setting on each reader instance. $ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-5138 | 1 | +--------------------------+--------------------------+ $ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-2470 | 1 | +--------------------------+--------------------------+ # Check lower_case_table_names setting on the reader endpoint of the cluster. $ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-5138 | 1 | +--------------------------+--------------------------+ # Run query on writer instance $ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \ -u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names' +--------------------------+--------------------------+ | @@aurora_server_id | @@lower_case_table_names | +--------------------------+--------------------------+ | instance-9404 | 1 | +--------------------------+--------------------------+

Avec le changement de paramètre appliqué partout, nous pouvons voir l'effet du réglage lower_case_table_names=1. S'il est fait référence à la table en tant que foo, Foo ou FOO, la requête convertit le nom en foo et accède à la même table dans chacun des cas.

mysql> use lctn; mysql> select * from foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from Foo; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+ mysql> select * from FOO; +--------------------------+ | s | +--------------------------+ | Lowercase table name foo | +--------------------------+