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.
# 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.
**Topics**
+ [Recherche des instances d'enregistreur et de lecteur pour un cluster Aurora](#USER_Reboot.Examples.IsClusterWriter)
+ [Redémarrage d'une instance de lecteur unique](#USER_Reboot.Examples.RebootReader)
+ [Redémarrage de l'instance d'enregistreur](#USER_Reboot.Examples.RebootWriter)
+ [Redémarrage indépendant de l'enregistreur et des lecteurs](#USER_Reboot.Examples.RebootAsynch)
+ [Application d'une modification de paramètre de cluster à un cluster Aurora MySQL version 2.10](#USER_Reboot.Examples.ParamChangeNewStyle)
## 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` et`instance-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](USER_Reboot.Uptime.md).
```
$ 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 sur le temps de disponibilité correspondantes sans se 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 |
+--------------------------+
```