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 SQL exemples Aurora My suivants montrent différentes combinaisons d'opérations de redémarrage pour les instances de base de données de lecture et d'écriture dans un cluster de base de données Aurora. Après chaque redémarrage, SQL les requêtes indiquent le temps de disponibilité des instances du cluster.

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

Dans un SQL cluster Aurora My comportant plusieurs instances de base de données, il est important de savoir laquelle est l'auteur et laquelle est le lecteur. 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 SQL requête de cet exemple montre une méthode SQL spécifique à My pour vérifier le temps de disponibilité. Vous pouvez utiliser cette technique dans une application de base de données. Pour une autre technique qui utilise le AWS CLI et fonctionne pour les deux moteurs Aurora, voirVé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 My SQL version 2.09. La SQL version d'Aurora My étant inférieure à 2.10, le redémarrage de l'instance d'écriture 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 Postgre et aux SQL clusters Aurora My SQL 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 qui exécute Aurora My SQL version 2.10. Dans cette SQL version d'Aurora My et les versions ultérieures, vous pouvez redémarrer l'instance du rédacteur sans provoquer le redémarrage de toutes les instances du 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 My SQL version5.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 à Aurora My SQL 2.10, les valeurs de disponibilité de tous les lecteurs étaient réinitialisées en même temps que le rédacteur.

$ 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

Appliquer une modification de paramètre de cluster à un cluster Aurora My SQL 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 My SQL 2.10. Avec cette SQL version d'Aurora My, vous redémarrez l'instance du rédacteur et toutes les instances du lecteur indépendamment.

L'exemple utilise le paramètre My SQL configuration à titre lower_case_table_names 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 la table dans la requête soit en majuscules, en minuscules ou en majuscules, l'SQLinstruction 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 |
+--------------------------+