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.
Temas
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.
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -umy-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 -umy-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 -umy-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 -umy-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 -umy-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 -umy-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 \ -umy-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 \ -umy-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 \ -umy-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 \ -umy-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 | +--------------------------+
