Reinicializar um cluster de banco de dados do Amazon Aurora ou instância de banco de dados do Amazon Aurora
Talvez seja necessário reinicializar seu cluster de banco de dados ou algumas instâncias dentro do cluster, geralmente por motivos de manutenção. Por exemplo, suponha que você modifique os parâmetros dentro de um grupo de parâmetros ou associe um grupo de parâmetros diferente ao cluster. Nesses casos, você deve reinicializar o cluster para que as alterações entrem em vigor. Da mesma forma, você pode reinicializar uma ou mais instâncias de banco de dados de leitor dentro do cluster. Você pode organizar as operações de reinicialização para instâncias individuais para minimizar o tempo de inatividade de todo o cluster.
O tempo necessário para reinicializar cada instância de banco de dados no cluster depende da atividade do banco de dados no momento da reinicialização. Também depende do processo de recuperação do seu mecanismo de banco de dados específico. Se for prático, reduza a atividade do banco de dados nessa instância específica antes de iniciar o processo de reinicialização. Isso pode reduzir o tempo necessário para reiniciar o banco de dados.
Você só pode reinicializar cada instância de banco de dados em seu cluster quando ela estiver no estado disponível. Uma instância de banco de dados pode estar indisponível por vários motivos. Isso inclui o estado do cluster que está sendo interrompido, uma modificação sendo aplicada à instância e uma ação da janela de manutenção, como uma atualização de versão.
Reiniciar uma instância de banco de dados reinicia o processo do mecanismo de banco de dados. Reinicializar uma instância de banco de dados resulta em uma interrupção momentânea, durante a qual o status da instância de banco de dados é definido como rebooting (reinicialização).
nota
Se uma instância de banco de dados não estiver usando as últimas alterações de seu grupo de parâmetros de banco de dados associado, o AWS Management Console mostrará o grupo de parâmetros de banco de dados com um status de pending-reboot (reinicialização pendente). O status pending-reboot (reinicialização pendente) do grupo de parâmetros não resultará em uma reinicialização automática durante a próxima janela de manutenção. Para aplicar as alterações de parâmetro mais recentes a essa instância de banco de dados, reinicialize-a manualmente. Para obter mais informações sobre parameter groups, consulte Trabalhar com grupos de parâmetros.
Tópicos
- Reinicializar uma instância de banco de dados em um cluster do Aurora
- Reinicializar um cluster do Aurora com disponibilidade de leitura
- Reinicializar um cluster do Aurora sem disponibilidade de leitura
- Verificar o tempo de atividade para clusters e instâncias do Aurora
- Exemplos de operações de reinicialização do Aurora
Reinicializar uma instância de banco de dados em um cluster do Aurora
Esse procedimento é a operação mais importante que você realiza ao executar reinicializações com o Aurora. Muitos dos procedimentos de manutenção envolvem a reinicialização de uma ou mais instâncias de banco de dados do Aurora em uma ordem específica.
Para reiniciar uma instância de banco de dados
-
Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/
. -
No painel de navegação, escolha Databases (Bancos de dados) e a instância de banco de dados que você deseja reiniciar.
-
Em Actions (Ações), escolha Reboot (Reiniciar).
A página Reboot DB Instance (Reinicializar instância de banco de dados) é exibida.
-
Escolha Reboot (Reinicializar) para reinicializar sua instância de banco de dados.
Ou escolha Cancel (Cancelar).
Para reinicializar uma instância de banco de dados usando a AWS CLI, chame o comando reboot-db-instance.
Para Linux, macOS ou Unix:
aws rds reboot-db-instance \ --db-instance-identifiermydbinstance
Para Windows:
aws rds reboot-db-instance ^ --db-instance-identifiermydbinstance
Para reinicializar uma instância de banco de dados usando a API do Amazon RDS, chame a operação RebootDBInstance.
Reinicializar um cluster do Aurora com disponibilidade de leitura
Com o recurso de disponibilidade de leitura, é possível reinicializar a instância do gravador do cluster do Aurora sem reinicializar as instâncias do leitor no cluster de banco de dados primário ou secundário. Isso pode ajudar a manter a alta disponibilidade do cluster para operações de leitura enquanto você reinicializa a instância do gravador. Você pode reinicializar as instâncias do leitor mais tarde, em um cronograma que seja conveniente para você. Por exemplo, em um cluster de produção, você pode reinicializar as instâncias do leitor uma de cada vez, começando somente após a conclusão da reinicialização da instância primária. Para cada instância de banco de dados que você reinicializar, siga o procedimento em Reinicializar uma instância de banco de dados em um cluster do Aurora.
O recurso de disponibilidade de leitura de clusters de banco de dados primários está disponível no Aurora MySQL versão 2.10 e posterior. A disponibilidade de leitura para clusters de banco de dados secundários está disponível no Aurora MySQL versão 3.06 e posterior.
Esse atributo está disponível para as seguintes versões do Aurora PostgreSQL:
Versão 15.2 e versões 15 posteriores
Versão 14.7 e versões 14 posteriores
Versão 13.10 e versões 13 posteriores
Versão 12.14 e versões 12 posteriores
Para obter mais informações sobre o atributo de disponibilidade de leitura no Aurora PostgreSQL, consulte Melhorar a disponibilidade de leitura das réplicas do Aurora.
Antes desse recurso, a reinicialização da instância principal fazia com que cada instância do leitor fosse reinicializada ao mesmo tempo. Se o cluster do Aurora estiver executando uma versão mais antiga, use o procedimento de reinicialização em Reinicializar um cluster do Aurora sem disponibilidade de leitura.
nota
A mudança no comportamento de reinicialização nos clusters de banco de dados do Aurora com disponibilidade de leitura é diferente para banco de dados globais do Aurora no Aurora MySQL versões anteriores a 3.06. Se você reinicializar a instância do gravador para o cluster principal em um banco de dados global do Aurora, as instâncias do leitor no cluster principal permanecerão disponíveis. No entanto, as instâncias de banco de dados em qualquer cluster secundário são reinicializadas ao mesmo tempo.
Uma versão limitada do recurso avançado de disponibilidade de leitura é compatível com o bancos de dados globais do Aurora para o Aurora PostgreSQL versões 12.16, 13.12, 14.9, 15.4 e posteriores.
Você reinicializa frequentemente o cluster depois de fazer alterações nos grupos de parâmetros do cluster. Você faz alterações nos parâmetros seguindo os procedimentos em Trabalhar com grupos de parâmetros. Suponha que você reinicialize a instância de banco de dados do gravador em um cluster do Aurora para aplicar alterações aos parâmetros do cluster. Algumas ou todas as instâncias de banco de dados do leitor podem continuar usando as configurações de parâmetros antigas. No entanto, as diferentes configurações de parâmetros não afetam a integridade dos dados do cluster. Todos os parâmetros de cluster que afetam a organização dos arquivos de dados são usados apenas pela instância de banco de dados do gravador.
Por exemplo, em um cluster do Aurora MySQL, você pode atualizar parâmetros de cluster, como binlog_format e innodb_purge_threads, na instância do gravador antes das instâncias do leitor. Somente a instância do gravador está gravando logs binários e limpando registros de desfazer. Para parâmetros que alteram a forma como as consultas interpretam instruções SQL ou a saída da consulta, talvez seja necessário ter cuidado para reinicializar as instâncias do leitor imediatamente. Você faz isso para evitar comportamentos inesperados de aplicações durante consultas. Por exemplo, suponha que você altere o parâmetro lower_case_table_names e reinicie a instância do gravador. Nesse caso, as instâncias do leitor talvez não consigam acessar uma tabela recém-criada até que todas sejam reinicializadas.
Para obter uma lista de todos os parâmetros do cluster do Aurora MySQL, consulte Parâmetros no nível do cluster.
Para obter uma lista de todos os parâmetros de cluster do Aurora PostgreSQL, consulte Parâmetros no nível do cluster do Aurora PostgreSQL.
dica
O Aurora MySQL ainda pode reinicializar algumas das instâncias do leitor junto com a instância do gravador se o cluster estiver processando uma workload com alta taxa de transferência.
A redução no número de reinicializações também se aplica durante as operações de failover. O Aurora MySQL reinicia somente a instância de banco de dados do gravador e o destino de failover durante um failover. Outras instâncias de banco de dados do leitor no cluster permanecem disponíveis para continuar processando consultas por meio de conexões com o endpoint do leitor. Assim, você pode melhorar a disponibilidade durante um failover com mais de uma instância de banco de dados de leitor em um cluster.
Reinicializar um cluster do Aurora sem disponibilidade de leitura
Sem o atributo de disponibilidade de leitura, você reinicializa um cluster de banco de dados do Aurora inteiro ao reinicializar a instância de banco de dados do leitor desse cluster. Para fazer isso, siga o procedimento em Reinicializar uma instância de banco de dados em um cluster do Aurora.
A reinicialização da instância de banco de dados do gravador também inicia uma reinicialização para cada instância de banco de dados do leitor no cluster. Dessa forma, todas as alterações de parâmetros em todo o cluster são aplicadas a todas as instâncias de banco de dados ao mesmo tempo. No entanto, a reinicialização de todas as instâncias de banco de dados causa uma breve interrupção para o cluster. As instâncias de banco de dados do leitor permanecem indisponíveis até que a instância de banco de dados do gravador termine a reinicialização e fique disponível
Esse comportamento de reinicialização aplica-se a todos os clusters de banco de dados criados no Aurora MySQL versão 2.09 e anteriores.
Para o Aurora PostgreSQL, esse comportamento se aplica às seguintes versões:
Versão 14.6 e versões 14 anteriores
Versão 13.9 e versões 13 anteriores
Versão 12.13 e versões 12 anteriores
Todas as versões 11 do PostgreSQL
No console do RDS, a instância de banco de dados do gravador tem o valor Writer na colunaFunction (Função) na página Databases (Bancos de dados). Na CLI do RDS, a saída do comando describe-db-clusters inclui uma seção DBClusterMembers. O elemento DBClusterMembers que representa a instância de banco de dados do gravador tem um valor true para o campo IsClusterWriter.
Importante
Com o atributo de disponibilidade de leitura, o comportamento de reinicialização é diferente no Aurora MySQL e Aurora PostgreSQL: as instâncias de banco de dados do leitor geralmente permanecem disponíveis enquanto você reinicia a instância do gravador. Em seguida, você pode reinicializar as instâncias do leitor em um momento conveniente. Você pode reinicializar as instâncias do leitor em uma programação escalonada se quiser que algumas instâncias do leitor estejam sempre disponíveis. Para ter mais informações, consulte Reinicializar um cluster do Aurora com disponibilidade de leitura.
Verificar o tempo de atividade para clusters e instâncias do Aurora
Você pode verificar e monitorar o período de tempo desde a última reinicialização para cada instância de banco de dados em seu cluster do Aurora. A métrica EngineUptime do Amazon CloudWatch informa o número de segundos desde a última vez que uma instância de banco de dados foi iniciada. Você pode examinar essa métrica em um momento para descobrir o tempo de atividade da instância de banco de dados. Você também pode monitorar essa métrica ao longo do tempo para detectar quando a instância é reinicializada.
Você também pode examinar a métrica EngineUptime no nível do cluster. As dimensões Minimum e Maximum relatam os menores e maiores valores de tempo de atividade para todas as instâncias de banco de dados no cluster. Para verificar o momento mais recente em que qualquer instância do leitor em um cluster foi reinicializada ou reiniciada por outro motivo, monitore a métrica no nível do cluster usando a dimensão Minimum. Para verificar qual instância no cluster passou mais tempo sem uma reinicialização, monitore a métrica no nível do cluster usando a dimensão Maximum. Por exemplo, talvez você queira confirmar que todas as instâncias de banco de dados no cluster foram reinicializadas após uma alteração de configuração.
dica
Para monitoramento de longo prazo, recomendamos monitorar a métrica EngineUptime para instâncias individuais em vez de no nível do cluster. A métrica EngineUptime no nível do cluster é definida como zero quando uma nova instância de banco de dados é adicionada ao cluster. Essas alterações de cluster podem ocorrer como parte das operações de manutenção e escalabilidade, como as realizadas pelo Auto Scaling.
Os exemplos da CLI a seguir mostram como examinar a métrica EngineUptime para as instâncias do gravador e do leitor em um cluster. Os exemplos usam um cluster chamado tpch100g. Este cluster tem uma instância de banco de dados do gravador instance-1234. Ele também tem duas instâncias de banco de dados de leitor, instance-7448 e instance-6305.
Primeiro, o comando reboot-db-instance reinicializa uma das instâncias do leitor. O comando wait aguarda até que a instância termine a reinicialização.
$ 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
O comando get-metric-statistics do CloudWatch examina a métrica EngineUptime nos últimos cinco minutos em intervalos de um minuto. O tempo de atividade da instância instance-6305 é redefinido para zero e começa a contar novamente. Esse exemplo da AWS CLI para Linux usa substituição de variáveis $() para inserir os carimbos de data/hora apropriados nos comandos da CLI. Ele também usa o comando sort para Linux para ordenar a saída no momento em que a métrica foi coletada. Esse valor de carimbo de data/hora é o terceiro campo em cada linha de saída.
$ 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 Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 231.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 291.0 2021-03-16T18:20:00+00:00 Seconds DATAPOINTS 351.0 2021-03-16T18:21:00+00:00 Seconds DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds
O tempo de atividade mínimo para o cluster é redefinido para zero porque uma das instâncias no cluster foi reinicializada. O tempo de atividade máximo para o cluster não é redefinido porque pelo menos uma das instâncias de banco de dados no cluster permaneceu disponível.
$ 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=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63099.0 2021-03-16T18:12:00+00:00 Seconds DATAPOINTS 63159.0 2021-03-16T18:13:00+00:00 Seconds DATAPOINTS 63219.0 2021-03-16T18:14:00+00:00 Seconds DATAPOINTS 63279.0 2021-03-16T18:15:00+00:00 Seconds DATAPOINTS 51.0 2021-03-16T18:16: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 Maximum \ --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \ | sort -k 3 EngineUptime DATAPOINTS 63389.0 2021-03-16T18:16:00+00:00 Seconds DATAPOINTS 63449.0 2021-03-16T18:17:00+00:00 Seconds DATAPOINTS 63509.0 2021-03-16T18:18:00+00:00 Seconds DATAPOINTS 63569.0 2021-03-16T18:19:00+00:00 Seconds DATAPOINTS 63629.0 2021-03-16T18:20:00+00:00 Seconds
Em seguida, outro comando reboot-db-instance reinicializa a instância do gravador do cluster. Outro comando wait pausa até que a instância do gravador termine a reinicialização.
$ aws rds reboot-db-instance --db-instance-identifier instance-1234 { "DBInstanceIdentifier": "instance-1234", "DBInstanceStatus": "rebooting", ... $ aws rds wait db-instance-available --db-instance-id instance-1234
Agora, a métrica EngineUptime para a instância do gravador mostra que a instância instance-1234 foi reinicializada recentemente. A instância do leitor instance-6305 também foi reinicializada automaticamente junto com a instância do gravador. Este cluster está executando o Aurora MySQL 2.09, o que não mantém as instâncias do leitor em execução à medida que a instância do gravador é reinicializada.
$ 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 Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \ | sort -k 3 EngineUptime DATAPOINTS 63749.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 63809.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 63869.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 41.0 2021-03-16T18:25:00+00:00 Seconds DATAPOINTS 101.0 2021-03-16T18:26: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 Maximum \ --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \ | sort -k 3 EngineUptime DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds DATAPOINTS 531.0 2021-03-16T18:24:00+00:00 Seconds DATAPOINTS 49.0 2021-03-16T18:26:00+00:00 Seconds
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 | +--------------------------+
