Exemplos de operações de reinicialização do Aurora
Os exemplos do Aurora MySQL a seguir mostram diferentes combinações de operações de reinicialização para instâncias de banco de dados de leitor e gravador em um cluster de banco de dados do Aurora. Após cada reinicialização, as consultas SQL demonstram o tempo de atividade das instâncias no cluster.
Tópicos
Localizar as instâncias do gravador e do leitor para um cluster do Aurora
Em um cluster do Aurora MySQL com várias instâncias de banco de dados, é importante saber qual delas é o gravador e quais são os leitores. As instâncias do gravador e do leitor também podem mudar de função quando ocorre uma operação de failover. Assim, é melhor executar uma verificação como a seguinte antes de fazer qualquer operação que exija uma instância de gravador ou leitor. Nesse caso, os valores de False para IsClusterWriter identificam as instâncias do leitor instance-6305 e instance-7448. O valor True identifica a instância do gravador, 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 iniciarmos os exemplos de reinicialização, a instância do gravador tem um tempo de atividade de aproximadamente uma semana. A consulta SQL neste exemplo mostra uma maneira específica do MySQL de verificar o tempo de atividade. Você pode usar essa técnica em uma aplicação de banco de dados. Para outra técnica que usa a AWS CLI e funciona para os dois mecanismos do Aurora, consulte Verificar o tempo de atividade para clusters e instâncias do 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| +----------------------------+---------+
Reinicializar uma única instância do leitor
Esse exemplo reinicia uma das instâncias de banco de dados do leitor. Talvez essa instância tenha sido sobrecarregada por uma consulta enorme ou por muitas conexões simultâneas. Ou talvez tenha ficado atrás da instância do escritor por causa de um problema de rede. Depois de iniciar a operação de reinicialização, o exemplo usa um comando wait para pausar até que a instância fique disponível. A essa altura, a instância tem um tempo de atividade de alguns 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 | +----------------------------+---------+
A reinicialização da instância do leitor não afetou o tempo de atividade da instância do gravador. Ele ainda tem um tempo de atividade de cerca de uma 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 | +----------------------------+----------+
Reinicializar a instância do gravador
Este exemplo reinicia a instância do gravador. Esse cluster está executando o Aurora MySQL versão 2.09. Como a versão do Aurora MySQL é inferior à 2.10, a reinicialização da instância do gravador também reinicializa qualquer instância de leitor no cluster.
Um comando wait pausa até que a reinicialização seja concluída. Agora, o tempo de atividade dessa instância é redefinido para zero. É possível que uma operação de reinicialização possa levar momentos substancialmente diferentes para instâncias de banco de dados de gravador e leitor. As instâncias de banco de dados do gravador e do leitor executam diferentes tipos de operações de limpeza, dependendo de suas funções.
$ 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 | +----------------------------+---------+
Após a reinicialização da instância de banco de dados do gravador, ambas as instâncias de banco de dados do leitor também têm seu tempo de atividade redefinido. A reinicialização da instância do gravador fazia com que as instâncias do leitor fossem reinicializadas também. Esse comportamento se aplica a clusters do Aurora PostgreSQL e a clusters do Aurora MySQL antes da versão 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 | +----------------------------+---------+
Reinicializar o gravador e os leitores independentemente
Esses próximos exemplos mostram um cluster que executa o Aurora MySQL versão 2.10. Nessa versão do Aurora MySQL e nas posteriores, você pode reinicializar a instância do gravador sem causar reinicializações para todas as instâncias do leitor. Dessa forma, suas aplicações com uso intensivo de consultas não sofrem nenhuma interrupção quando você reinicializa a instância do gravador. Você pode reinicializar as instâncias do leitor mais tarde. Você pode fazer essas reinicializações em um momento de baixo tráfego de consulta. Você também pode reinicializar as instâncias do leitor uma de cada vez. Dessa forma, pelo menos uma instância do leitor está sempre disponível para o tráfego de consulta da aplicação.
O exemplo a seguir usa um cluster chamado cluster-2393, executando a versão 5.7.mysql_aurora.2.10.0 do Aurora MySQL. Esse cluster tem uma instância de gravador chamada instance-9404 e três instâncias de leitor chamadas instance-6772, instance-2470 e 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
Verificar o valor uptime de cada instância de banco de dados por meio do comando mysql mostra que cada uma tem aproximadamente o mesmo tempo de atividade. Por exemplo, aqui está o tempo de atividade para instance-5138.
mysql> SHOW GLOBAL STATUS LIKE 'uptime'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Uptime | 3866 | +---------------+-------+
Ao usar o CloudWatch, podemos obter as informações de tempo de atividade correspondentes sem realmente fazer login nas instâncias. Dessa forma, um administrador pode monitorar o banco de dados, mas não pode exibir ou alterar nenhum dado da tabela. Nesse caso, especificamos um período de tempo que abrange cinco minutos e verificamos o valor do tempo de atividade a cada minuto. Os valores crescentes de tempo de atividade demonstram que as instâncias não foram reiniciadas durante esse período.
$ 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
Agora reinicializamos uma das instâncias do leitor, instance-5138. Esperamos que a instância fique disponível novamente após a reinicialização. Agora, monitorar o tempo de atividade durante um período de cinco minutos mostra que o tempo de atividade foi redefinido para zero durante esse tempo. O valor de tempo de atividade mais recente foi medido cinco segundos após o término da reinicialização.
$ 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
Em seguida, realizamos uma reinicialização para a instância do gravador, instance-9404. Comparamos os valores de tempo de atividade para a instância do gravador e uma das instâncias do leitor. Ao fazer isso, podemos ver que a reinicialização do escritor não causou uma reinicialização para os leitores. Nas versões anteriores a Aurora MySQL 2.10, os valores de tempo de atividade para todos os leitores seriam redefinidos ao mesmo tempo que o gravador.
$ 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 garantir que todas as instâncias do leitor tenham todas as mesmas alterações nos parâmetros de configuração que a instância do gravador, reinicie todas as instâncias do leitor após o gravador. Este exemplo reinicia todos os leitores e aguarda até que todos eles estejam disponíveis antes de prosseguir.
$ 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
Agora podemos ver que a instância de banco de dados do gravador tem o maior tempo de atividade. O valor do tempo de atividade dessa instância aumentou de forma constante durante todo o período de monitoramento. As instâncias de banco de dados do leitor foram todas reinicializadas após o leitor. Podemos ver o ponto dentro do período de monitoramento em que cada leitor foi reinicializado e seu tempo de atividade foi redefinido para zero.
$ 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
Aplicando uma alteração de parâmetro de cluster a um cluster do Aurora MySQL versão 2.10
O exemplo a seguir demonstra como aplicar uma alteração de parâmetro a todas as instâncias de banco de dados em seu cluster do Aurora MySQL 2.10. Com essa versão do Aurora MySQL, você reinicializa a instância do gravador e todas as instâncias do leitor de forma independente.
O exemplo usa o parâmetro de configuração lower_case_table_names do MySQL para ilustração. Quando essa configuração de parâmetro é diferente entre as instâncias de banco de dados do gravador e do leitor, talvez uma consulta não consiga acessar uma tabela declarada com um nome maiúsculo ou misto. Ou se dois nomes de tabela diferirem apenas em termos de letras maiúsculas e minúsculas, uma consulta pode acessar a tabela errada.
Este exemplo mostra como determinar as instâncias do gravador e do leitor no cluster examinando o atributo IsClusterWriter de cada instância. O cluster é chamado cluster-2393. O cluster tem uma instância de gravador chamada instance-9404. As instâncias do leitor no cluster são chamadas instance-5138 e 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 demonstrar os efeitos da alteração do parâmetro lower_case_table_names, configuramos dois grupos de parâmetros de cluster de banco de dados. O grupo de parâmetros lower-case-table-names-0 tem esse parâmetro definido como 0. O grupo de parâmetros lower-case-table-names-1 tem esse grupo de parâmetros definido como 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" }
O valor padrão de lower_case_table_names é 0. Com essa configuração de parâmetro, a tabela foo é distinta da tabela FOO. Este exemplo verifica se o parâmetro ainda está em sua configuração padrão. Em seguida, o exemplo cria três tabelas que diferem apenas em letras maiúsculas e minúsculas em seus nomes.
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 | +--------------------------+
Em seguida, associamos o grupo de parâmetros de banco de dados ao cluster para definir o parâmetro lower_case_table_names como 1. Essa alteração só entra em vigor após cada instância de banco de dados ser reinicializada.
$ 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" }
A primeira reinicialização que fazemos é para a instância de banco de dados do gravador. Em seguida, esperamos que a instância se torne disponível novamente. Nesse ponto, nos conectamos ao endpoint do gravador e verificamos se a instância do gravador tem o valor do parâmetro alterado. O comando SHOW TABLES confirma que o banco de dados contém as três tabelas diferentes. No entanto, as consultas que se referem às tabelas chamadas foo, Foo ou FOO, todas acessam a tabela com o nome todo em 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
Agora, as consultas que usam o endpoint do cluster mostram os efeitos da alteração de parâmetro. Se o nome da tabela na consulta estiver em maiúsculas, minúsculas ou combinação de ambas, a instrução SQL acessa a tabela cujo nome está em 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 | +--------------------------+
O próximo exemplo mostra as mesmas consultas que a anterior. Nesse caso, as consultas usam o endpoint do leitor e são executadas em uma das instâncias de banco de dados do leitor. Essas instâncias ainda não foram reinicializadas. Assim, eles ainda têm a configuração original para o parâmetro lower_case_table_names. Isso significa que as consultas podem acessar cada uma das tabelas foo, Foo e 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 | +--------------------------+
Em seguida, reinicializamos uma das instâncias do leitor e aguardamos que ela se torne disponível novamente.
$ 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
Enquanto conectado ao endpoint da instância para instance-2470, uma consulta mostra que o novo parâmetro está em vigor.
mysql> select @@lower_case_table_names; +--------------------------+ | @@lower_case_table_names | +--------------------------+ | 1 | +--------------------------+
Nesse ponto, as duas instâncias do leitor no cluster estão sendo executadas com configurações lower_case_table_names diferentes. Assim, qualquer conexão com o endpoint do leitor do cluster usa um valor para essa configuração que é imprevisível. É importante reinicializar imediatamente a outra instância do leitor para que ambas tenham configurações consistentes.
$ 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
O exemplo a seguir confirma que todas as instâncias do leitor têm a mesma configuração para o parâmetro lower_case_table_names. Os comandos verificam o valor da configuração lower_case_table_names em cada instância do leitor. Em seguida, o mesmo comando que usa o endpoint do leitor demonstra que cada conexão com o endpoint do leitor usa uma das instâncias do leitor, mas qual delas não é previsível.
# 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 | +--------------------------+--------------------------+
Com a mudança de parâmetro aplicada em todos os lugares, podemos ver o efeito da configuração lower_case_table_names=1. Se a tabela é referida como foo, Foo ou FOO, a consulta converte o nome para foo e acessa a mesma tabela em 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 | +--------------------------+
