# Ejemplos de operaciones de reinicio de Aurora
En los siguientes ejemplos de Aurora MySQL, se muestran diferentes combinaciones de operaciones de reinicio de instancias de base de datos del lector y del escritor en un clúster de base de datos de Aurora. Después de cada reinicio, las consultas SQL demuestran el tiempo de actividad de las instancias del clúster.
**Topics**
+ [Búsqueda de instancias del escritor y del lector de un clúster de Aurora](#USER_Reboot.Examples.IsClusterWriter)
+ [Reinicio de una única instancia del lector](#USER_Reboot.Examples.RebootReader)
+ [Reinicio de la instancia del escritor](#USER_Reboot.Examples.RebootWriter)
+ [Reiniciar las instancias del lector y del escritor de forma independiente](#USER_Reboot.Examples.RebootAsynch)
+ [Aplicación de un cambio de parámetro de clúster a un clúster de Aurora MySQL versión 2.10](#USER_Reboot.Examples.ParamChangeNewStyle)
## Búsqueda de instancias del escritor y del lector de un clúster de Aurora
En un clúster de Aurora MySQL con varias instancias de base de datos, es importante saber cuál es el escritor y cuáles son los lectores. Las instancias del escritor y lector también pueden cambiar de rol cuando se produce una operación de conmutación por error. Por lo tanto, es mejor realizar una verificación como la siguiente antes de realizar cualquier operación que requiera una instancia del escritor o del lector. En este caso, los valores `False` para `IsClusterWriter` identifican las instancias del lector, `instance-6305` y `instance-7448`. El valor `True` identifica la instancia del escritor, `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
```
Antes de comenzar con los ejemplos de reinicio, la instancia del escritor tiene un tiempo de actividad de aproximadamente una semana. La consulta SQL de este ejemplo muestra una forma específica de MySQL de verificar el tiempo de actividad. Puede utilizar esta técnica en una aplicación de base de datos. Para obtener información sobre otra técnica que utiliza la AWS CLI y funciona para ambos motores de Aurora, consulte [Verificación del tiempo de actividad de clústeres e instancias de 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|
+----------------------------+---------+
```
## Reinicio de una única instancia del lector
En este ejemplo, se reinicia una de las instancias de base de datos del lector. Tal vez esta instancia se sobrecargó debido a una consulta enorme o a varias conexiones simultáneas. O tal vez se quedó atrás de la instancia del escritor debido a un problema de red. Después de comenzar con la operación de reinicio, el ejemplo utiliza un comando `wait` para realizar una pausa hasta que la instancia esté disponible. Para entonces, la instancia tiene un tiempo de actividad de unos minutos.
```
$ 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 |
+----------------------------+---------+
```
El reinicio de la instancia del lector no afectó al tiempo de actividad de la instancia del escritor. Aún tiene un tiempo de actividad de aproximadamente una semana.
```
$ 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 |
+----------------------------+----------+
```
## Reinicio de la instancia del escritor
En este ejemplo, se reinicia la instancia del escritor. Este clúster ejecuta la versión 2.09 de Aurora MySQL. Dado que la versión de Aurora MySQL es anterior a 2.10, al reiniciar la instancia del escritor también se reinicia cualquier instancia del lector del clúster.
Un comando `wait` realiza una pausa hasta que finaliza el reinicio. Ahora, el tiempo de actividad de esa instancia se restablece a cero. Es posible que una operación de reinicio demore tiempos significativamente diferentes para las instancias de base de datos del escritor y del lector. Las instancias de base de datos del escritor y del lector realizan diferentes tipos de operaciones de limpieza en función de sus roles.
```
$ 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 |
+----------------------------+---------+
```
Tras el reinicio de la instancia de base de datos del escritor, también se restablece el tiempo de actividad de ambas instancias de base de datos del lector. Reiniciar la instancia del escritor también reinicia las instancias del lector. Este comportamiento se aplica a los clústeres de Aurora PostgreSQL y a los clústeres de Aurora MySQL anteriores a la versión 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 |
+----------------------------+---------+
```
## Reiniciar las instancias del lector y del escritor de forma independiente
En los siguientes ejemplos, se muestra un clúster que ejecuta la versión 2.10 de Aurora MySQL. En esta versión de Aurora MySQL y en versiones posteriores, puede reiniciar la instancia del escritor sin provocar el reinicio de todas las instancias del lector. De esta forma, las aplicaciones que requieren un uso intensivo de consultas no experimentan interrupciones cuando reinicia la instancia del escritor. Puede reiniciar las instancias del lector más tarde. Puede ejecutar estos reinicios en un momento de bajo tráfico de consultas. También puede reiniciar las instancias del lector de una a la vez. De esta forma, al menos una instancia del lector siempre estará disponible para el tráfico de consultas de la aplicación.
En el ejemplo siguiente, se utiliza un clúster denominado `cluster-2393` que ejecuta la versión `5.7.mysql_aurora.2.10.0` de Aurora MySQL. Este clúster tiene una instancia del escritor denominada `instance-9404` y tres instancias del lector denominadas `instance-6772`, `instance-2470` y `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 verificación del valor del `uptime` de cada instancia de base de datos mediante el comando `mysql` muestra que cada una tiene aproximadamente el mismo tiempo de actividad. Por ejemplo, aquí está el tiempo de actividad de `instance-5138`.
```
mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime | 3866 |
+---------------+-------+
```
Mediante CloudWatch, podemos obtener la información de tiempo de actividad correspondiente sin realmente iniciar sesión en las instancias. De esta forma, un administrador puede monitorear la base de datos, pero no puede ver ni cambiar ningún dato de tabla. En este caso, especificamos un periodo que abarca cinco minutos y verificamos el valor del tiempo de actividad cada minuto. Los crecientes valores de tiempo de actividad demuestran que las instancias no se reiniciaron durante ese periodo.
```
$ 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
```
Ahora, reiniciamos una de las instancias del lecto, `instance-5138`. Esperamos que la instancia vuelva a estar disponible tras el reinicio. Ahora, el monitoreo del tiempo de actividad durante un periodo de cinco minutos muestra que el tiempo de actividad se restableció a cero durante ese tiempo. El valor de tiempo de actividad más reciente se midió cinco segundos después de que finalizó el reinicio.
```
$ 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
```
A continuación, ejecutamos un reinicio para la instancia del escrito, `instance-9404`. Comparamos los valores de tiempo de actividad de la instancia del escritor y de una de las instancias del lector. Al hacerlo, podemos ver que reiniciar el escritor no provocó un reinicio de los lectores. En versiones anteriores a la 2.10 de Aurora MySQL, los valores de tiempo de actividad de todos los lectores se restablecían al mismo tiempo que el escritor.
```
$ 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
```
Para asegurarse de que todas las instancias del lector tengan los mismos cambios en los parámetros de configuración que la instancia del escritor, reinicie todas las instancias del lector después del escritor. En este ejemplo, se reinician todos los lectores y luego se espera que todos estén disponibles antes de continuar.
```
$ 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
```
Ahora podemos ver que la instancia de base de datos del escritor tiene el mayor tiempo de actividad. El valor de tiempo de actividad de esta instancia aumentó constantemente durante todo el periodo de monitoreo. Las instancias de base de datos del lector se reiniciaron después del lector. Podemos ver el punto dentro del periodo de monitoreo en el que se reinició cada lector y su tiempo de actividad se restableció a cero.
```
$ 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
```
## Aplicación de un cambio de parámetro de clúster a un clúster de Aurora MySQL versión 2.10
En el siguiente ejemplo, se muestra cómo aplicar un cambio de parámetro a todas las instancias de base de datos del clúster de Aurora MySQL 2.10. Con esta versión de Aurora MySQL, reinicia la instancia del escritor y todas las instancias del lector de forma independiente.
En el ejemplo se utiliza el parámetro de configuración de MySQL `lower_case_table_names` como ilustración. Cuando esta configuración de parámetro es diferente entre las instancias de base de datos del escritor y del lector, es posible que una consulta no logre acceder a una tabla declarada con un nombre en mayúsculas o minúsculas mixtas. O si dos nombres de tabla difieren solo en las mayúsculas y minúsculas, una consulta podría acceder a la tabla incorrecta.
En este ejemplo, se muestra cómo determinar las instancias del escritor y del lector del clúster al examinar el atributo `IsClusterWriter` de cada instancia. El clúster se denomina `cluster-2393`. El clúster tiene una instancia del escritor denominada `instance-9404`. Las instancias del lector del clúster se denominan `instance-5138` y `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
```
Para demostrar los efectos de cambiar el parámetro `lower_case_table_names`, definimos dos grupos de parámetros de clúster de base de datos. El grupo de parámetros `lower-case-table-names-0` tiene este parámetro establecido en 0. El grupo de parámetros `lower-case-table-names-1` tiene este grupo de parámetros establecido en 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"
}
```
El valor predeterminado de `lower_case_table_names` es 0. Con esta configuración de parámetros, la tabla `foo` es distinta de la tabla `FOO`. En este ejemplo, se verifica que el parámetro mantiene su configuración predeterminada. A continuación, en el ejemplo se crean tres tablas que solo difieren en las mayúsculas y minúsculas en sus nombres.
```
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 |
+--------------------------+
```
A continuación, asociamos el grupo de parámetros de base de datos con el clúster para establecer el parámetro `lower_case_table_names` en 1. Este cambio solo tiene efecto después de reiniciar cada instancia de base de datos.
```
$ 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"
}
```
El primer reinicio que ejecutamos es para la instancia de base de datos del escritor. Luego, esperamos que la instancia vuelva a estar disponible. En ese momento, nos conectamos al punto de enlace del escritor y verificamos que la instancia del escritor tenga el valor del parámetro modificado. El comando `SHOW TABLES` confirma que la base de datos contiene las tres tablas diferentes. Sin embargo, todas las consultas que hacen referencia a tablas denominadas `foo`, `Foo` o `FOO` acceden a la tabla cuyo nombre está en minúsculas, `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
```
Ahora, las consultas que utilizan el punto de enlace del clúster muestran los efectos del cambio de parámetros. Ya sea que el nombre de la tabla de la consulta está en mayúsculas, minúsculas o ambas, la instrucción SQL accederá a la tabla cuyo nombre está en minúsculas.
```
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 |
+--------------------------+
```
En el siguiente ejemplo, se muestran las mismas consultas que la anterior. En este caso, las consultas utilizan el punto de enlace del lector y se ejecutan en una de las instancias de base de datos del lector. Todavía no se reiniciaron esas instancias. Por lo tanto, aún tienen la configuración original para el parámetro `lower_case_table_names`. Esto significa que las consultas pueden acceder a cada una de las tablas `foo`, `Foo` y `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 |
+--------------------------+
```
A continuación, reiniciamos una de las instancias del lector y esperamos que vuelva a estar 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
```
Mientras está conectado al punto de enlace de la instancia para `instance-2470`, una consulta muestra que el nuevo parámetro está activo.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 1 |
+--------------------------+
```
En este punto, las dos instancias del lector del clúster se ejecutan con diferentes configuraciones `lower_case_table_names`. Por lo tanto, cualquier conexión con el punto de enlace del lector del clúster utiliza un valor para esta configuración que es impredecible. Es importante reiniciar inmediatamente la otra instancia del lector para que ambas tengan una configuración coherente.
```
$ 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
```
En el siguiente ejemplo se confirma que todas las instancias del lector tienen la misma configuración para el parámetro `lower_case_table_names`. Los comandos verifican el valor de configuración de `lower_case_table_names` para cada instancia del lector. A continuación, el mismo comando que utiliza el punto de enlace del lector demuestra que cada conexión al punto de enlace del lector utiliza una de las instancias del lector, pero no se puede predecir cuál de ellas.
```
# 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 |
+--------------------------+--------------------------+
```
Con el cambio de parámetros aplicado en todas partes, podemos ver el efecto de la configuración `lower_case_table_names=1`. Si la tabla se denomina `foo`, `Foo` o `FOO`, la consulta convierte el nombre a `foo` y accede a la misma tabla en cada caso.
```
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 |
+--------------------------+
```