# Como gerenciar o Amazon Aurora MySQL
As seguintes seções abordam como gerenciar um cluster de banco de dados do Amazon Aurora MySQL.
**Topics**
+ [Gerenciar a performance e a escalabilidade do Amazon Aurora MySQL](AuroraMySQL.Managing.Performance.md)
+ [Retroceder um cluster de banco de dados Aurora](AuroraMySQL.Managing.Backtrack.md)
+ [Testar o Amazon Aurora MySQL usando consultas de injeção de falhas](AuroraMySQL.Managing.FaultInjectionQueries.md)
+ [Alterar tabelas no Amazon Aurora usando a DDL rápida](AuroraMySQL.Managing.FastDDL.md)
+ [Exibir o status do volume para um cluster de banco de dados Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md)
# Gerenciar a performance e a escalabilidade do Amazon Aurora MySQL
## Dimensionar instâncias de bancos de dados Aurora MySQL
Você pode escalar instâncias de banco de dados Aurora MySQL de duas maneiras: com escalabilidade de instância e escalabilidade de leitura. Para obter mais informações sobre a escalabilidade de leitura, consulte [Escalabilidade de leitura](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling).
Você pode escalar o cluster de bancos de dados Aurora MySQL modificando a classe da instância de banco de dados para cada instância de banco de dados do cluster. O Aurora MySQL é compatível com várias classes de instância de banco de dados otimizada para o Aurora. Não use classes de instância db.t2 ou db.t3 para clusters do Aurora maiores com tamanho superior a 40 TB. Para obter as especificações das classes de instância de banco de dados compatíveis com o Aurora MySQL, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md).
**nota**
Recomendamos usar as classes de instância de banco de dados T somente para servidores de desenvolvimento e teste, ou outros servidores que não sejam de produção. Para obter mais detalhes sobre as classes de instâncias T, consulte [Uso de classes de instância T para desenvolvimento e testes](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
## Número máximo de conexões com uma instância de bancos de dados Aurora MySQL
O número máximo de conexões permitido para uma instância de bancos de dados Aurora MySQL é determinado pelo parâmetro `max_connections` no grupo de parâmetros do nível da instância para a instância de banco de dados.
A tabela a seguir lista o valor padrão resultante de `max_connections` para cada classe de instância de banco de dados disponível para o Aurora MySQL. É possível aumentar o número máximo de conexões da instância de bancos de dados Aurora MySQL dimensionando a instância até uma classe de instância de banco de dados com mais memória ou definindo um valor maior para o parâmetro `max_connections` no grupo de parâmetros de banco de dados da instância, de até 16.000.
**dica**
Se suas aplicações abrem e fecham conexões com frequência ou mantêm um grande número de conexões de longa duração abertas, recomendamos usar o Amazon RDS Proxy. O RDS Proxy é um proxy de banco de dados totalmente gerenciado e altamente disponível que usa grupos de conexões para compartilhar conexões de banco de dados de forma segura e eficiente. Para saber mais sobre o RDS Proxy, consulte [Amazon RDS Proxypara Aurora](rds-proxy.md).
Para obter detalhes sobre como as instâncias do Aurora Serverless v2 lidam com esse parâmetro, consulte [Conexões máximas do Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections).
| Classe de instância | Valor padrão de max\$1connections |
| --- | --- |
| db.t2.small | 45 |
| db.t2.medium | 90 |
| db.t3.small | 45 |
| db.t3.medium | 90 |
| db.t3.large | 135 |
| db.t4g.medium | 90 |
| db.t4g.large | 135 |
| db.r3.large | 1000 |
| db.r3.xlarge | 2000 |
| db.r3.2xlarge | 3000 |
| db.r3.4xlarge | 4000 |
| db.r3.8xlarge | 5000 |
| db.r4.large | 1000 |
| db.r4.xlarge | 2000 |
| db.r4.2xlarge | 3000 |
| db.r4.4xlarge | 4000 |
| db.r4.8xlarge | 5000 |
| db.r4.16xlarge | 6000 |
| db.r5.large | 1000 |
| db.r5.xlarge | 2000 |
| db.r5.2xlarge | 3000 |
| db.r5.4xlarge | 4000 |
| db.r5.8xlarge | 5000 |
| db.r5.12xlarge | 6000 |
| db.r5.16xlarge | 6000 |
| db.r5.24xlarge | 7000 |
| db.r6g.large | 1000 |
| db.r6g.xlarge | 2000 |
| db.r6g.2xlarge | 3000 |
| db.r6g.4xlarge | 4000 |
| db.r6g.8xlarge | 5000 |
| db.r6g.12xlarge | 6000 |
| db.r6g.16xlarge | 6000 |
| db.r6i.large | 1000 |
| db.r6i.xlarge | 2000 |
| db.r6i.2xlarge | 3000 |
| db.r6i.4xlarge | 4000 |
| db.r6i.8xlarge | 5000 |
| db.r6i.12xlarge | 6000 |
| db.r6i.16xlarge | 6000 |
| db.r6i.24xlarge | 7000 |
| db.r6i.32xlarge | 7000 |
| db.r7g.large | 1000 |
| db.r7g.xlarge | 2000 |
| db.r7g.2xlarge | 3000 |
| db.r7g.4xlarge | 4000 |
| db.r7g.8xlarge | 5000 |
| db.r7g.12xlarge | 6000 |
| db.r7g.16xlarge | 6000 |
| db.r7i.large | 1000 |
| db.r7i.xlarge | 2000 |
| db.r7i.2xlarge | 3000 |
| db.r7i.4xlarge | 4000 |
| db.r7i.8xlarge | 5000 |
| db.r7i.12xlarge | 6000 |
| db.r7i.16xlarge | 6000 |
| db.r7i.24xlarge | 7000 |
| db.r7i.48xlarge | 8000 |
| db.r8g.large | 1000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3000 |
| db.r8g.4xlarge | 4000 |
| db.r8g.8xlarge | 5000 |
| db.r8g.12xlarge | 6000 |
| db.r8g.16xlarge | 6000 |
| db.r8g.24xlarge | 7000 |
| db.r8g.48xlarge | 8000 |
| db.x2g.large | 2000 |
| db.x2g.xlarge | 3000 |
| db.x2g.2xlarge | 4000 |
| db.x2g.4xlarge | 5000 |
| db.x2g.8xlarge | 6000 |
| db.x2g.12xlarge | 7000 |
| db.x2g.16xlarge | 7000 |
**dica**
O cálculo do parâmetro `max_connections` usa o log base 2 (diferente do logaritmo natural) e o valor `DBInstanceClassMemory` em bytes para a classe de instância selecionada do Aurora MySQL. O parâmetro aceita somente valores inteiros, com partes decimais truncadas dos cálculos. A fórmula implementa os limites de conexão da seguinte forma:
Incremento de 1.000 conexões para instâncias R3, R4 e R5 maiores
Incremento de 45 conexões para variantes de memória de instância T2 e T3
Exemplo: para db.r6g.large, enquanto a fórmula calcula 1069,2, o sistema implementa 1000 para manter padrões incrementais consistentes.
Se você criar um novo grupo de parâmetros para personalizar seu próprio padrão para o limite de conexão, verá que o limite da conexão padrão é derivado usando uma fórmula baseada no valor `DBInstanceClassMemory`. Como mostra a tabela anterior, a fórmula gera limites de conexão que aumentam em 1000 à medida que a memória é duplicada entre as instâncias progressivamente maiores R3, R4 e R5, e em 45 para tamanhos de memórias diferentes das instâncias T2 e T3.
Consulte [Especificação de parâmetros de banco de dados](USER_ParamValuesRef.md) para obter mais detalhes sobre como é feito o cálculo de `DBInstanceClassMemory`.
As instâncias de banco de dados Aurora MySQL e RDS para MySQL têm diferentes quantidades de sobrecarga de memória. Portanto, o valor de `max_connections` pode ser diferente para instâncias de banco de dados Aurora MySQL e RDS para MySQL que usam a mesma classe de instância. Os valores na tabela só se aplicam a instâncias de banco de dados Aurora MySQL.
**nota**
Os limites de conectividade bem mais baixos das instâncias T2 e T3 ocorrem porque com o Aurora essas classes de instâncias são destinadas apenas para cenários de desenvolvimento e teste, e não para cargas de trabalho de produção.
Os limites de conexão padrão são ajustados pelos sistemas que usam os valores padrão para outros grandes consumidores de memória, como grupo de buffers e cache de consulta. Se você alterar essas outras configurações de seu cluster, considere o ajuste do limite de conexão para levar em conta o aumento ou a redução da memória disponível nas instâncias de banco de dados.
## Limites de armazenamento temporário para o Aurora MySQL
O Aurora MySQL armazena tabelas e índices no subsistema de armazenamento do Aurora. O Aurora MySQL usa armazenamento temporário separado ou local para arquivos temporários não persistentes e tabelas temporárias não InnoDB. O armazenamento local também inclui arquivos que são usados para fins como classificar grandes conjuntos de dados durante o processamento de consultas ou para operações de compilação de índice. Ele não inclui tabelas temporárias do InnoDB.
Para obter mais informações sobre tabelas temporárias no Aurora MySQL versão 3, consulte [Novo comportamento de tabela temporária no Aurora MySQL versão 3](ams3-temptable-behavior.md). Para obter mais informações sobre tabelas temporárias na versão 2, consulte [Comportamento de espaço de tabela temporário no Aurora MySQL versão 2](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.TempTables57).
Os dados e os arquivos temporários nesses volumes são perdidos ao iniciar e interromper a instância de banco de dados e durante a substituição do host.
Esses volumes de armazenamento local são apoiados pelo Amazon Elastic Block Store (EBS) e podem ser estendidos utilizando uma classe de instância de banco de dados maior. Para ter mais informações sobre armazenamento, consulte [Armazenamento do Amazon Aurora](Aurora.Overview.StorageReliability.md).
O armazenamento local também é usado para importar dados do Amazon S3 usando `LOAD DATA FROM S3` ou `LOAD XML FROM S3` e exportar dados para o S3 usando SELECT INTO OUTFILE S3. Para ter mais informações sobre como importar e exportar dados para o S3, consulte o seguinte:
+ [Carregar dados em um cluster de banco de dados do Amazon Aurora MySQL a partir de arquivos de texto em um bucket do Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md)
+ [Salvar dados a partir de um cluster de banco de dados do Amazon Aurora MySQL em arquivos de texto de um bucket do Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md)
O Aurora MySQL usa armazenamento permanente separado para logs de erros, logs gerais, logs de consultas lentas e logs de auditoria para a maioria das classes de instância de banco de dados do Aurora MySQL (sem incluir tipos de classe de instância de desempenho expansível, como db.t2, db.t3 e db.t4g). Os dados nesse volume são retidos ao iniciar e interromper a instância de banco de dados e durante a substituição do host.
Esse volume de armazenamento permanente também conta com o suporte do Amazon EBS e tem um tamanho fixo de acordo com a classe de instância de banco de dados. Não é possível ampliá-lo utilizando uma classe de instância de banco de dados maior.
A tabela a seguir mostra a quantidade máxima de armazenamento temporário e permanente disponível para cada classe de instância de banco de dados do Aurora MySQL. Para ter mais informações sobre o suporte a classes de instância de banco de dados para o Aurora, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md).
| Classe de instância de banco de dados | Armazenamento temporário/local máximo disponível (GiB) | Armazenamento máximo adicional disponível para arquivos de log (GiB) |
| --- | --- | --- |
| db.x2g.16xlarge | 1.280 | 500 |
| db.x2g.12xlarge | 960 | 500 |
| db.x2g.8xlarge | 640 | 500 |
| db.x2g.4xlarge | 320 | 500 |
| db.x2g.2xlarge | 160 | 60 |
| db.x2g.xlarge | 80 | 60 |
| db.x2g.large | 40 | 60 |
| db.r8g.48xlarge | 3840 | 500 |
| db.r8g.24xlarge | 1920 | 500 |
| db.r8g.16xlarge | 1.280 | 500 |
| db.r8g.12xlarge | 960 | 500 |
| db.r8g.8xlarge | 640 | 500 |
| db.r8g.4xlarge | 320 | 500 |
| db.r8g.2xlarge | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.large | 32 | 60 |
| db.r7i.48xlarge | 3840 | 500 |
| db.r7i.24xlarge | 1920 | 500 |
| db.r7i.16xlarge | 1.280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8xlarge | 640 | 500 |
| db.r7i.4xlarge | 320 | 500 |
| db.r7i.2xlarge | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.large | 32 | 60 |
| db.r7g.16xlarge | 1.280 | 500 |
| db.r7g.12xlarge | 960 | 500 |
| db.r7g.8xlarge | 640 | 500 |
| db.r7g.4xlarge | 320 | 500 |
| db.r7g.2xlarge | 160 | 60 |
| db.r7g.xlarge | 80 | 60 |
| db.r7g.large | 32 | 60 |
| db.r6i.32xlarge | 2560 | 500 |
| db.r6i.24xlarge | 1920 | 500 |
| db.r6i.16xlarge | 1.280 | 500 |
| db.r6i.12xlarge | 960 | 500 |
| db.r6i.8xlarge | 640 | 500 |
| db.r6i.4xlarge | 320 | 500 |
| db.r6i.2xlarge | 160 | 60 |
| db.r6i.xlarge | 80 | 60 |
| db.r6i.large | 32 | 60 |
| db.r6g.16xlarge | 1.280 | 500 |
| db.r6g.12xlarge | 960 | 500 |
| db.r6g.8xlarge | 640 | 500 |
| db.r6g.4xlarge | 320 | 500 |
| db.r6g.2xlarge | 160 | 60 |
| db.r6g.xlarge | 80 | 60 |
| db.r6g.large | 32 | 60 |
| db.r5.24xlarge | 1920 | 500 |
| db.r5.16xlarge | 1.280 | 500 |
| db.r5.12xlarge | 960 | 500 |
| db.r5.8xlarge | 640 | 500 |
| db.r5.4xlarge | 320 | 500 |
| db.r5.2xlarge | 160 | 60 |
| db.r5.xlarge | 80 | 60 |
| db.r5.large | 32 | 60 |
| db.r4.16xlarge | 1.280 | 500 |
| db.r4.8xlarge | 640 | 500 |
| db.r4.4xlarge | 320 | 500 |
| db.r4.2xlarge | 160 | 60 |
| db.r4.xlarge | 80 | 60 |
| db.r4.large | 32 | 60 |
| db.t4g.large | 32 | – |
| db.t4g.medium | 32 | – |
| db.t3.large | 32 | – |
| db.t3.medium | 32 | – |
| db.t3.small | 32 | – |
| db.t2.medium | 32 | – |
| db.t2.small | 32 | – |
**Importante**
Esses valores representam a quantidade teórica máxima de armazenamento gratuito em cada instância de banco de dados. O armazenamento local real disponível para você pode ser menor. O Aurora usa um pouco do armazenamento local para seus processos de gerenciamento, e a instância de banco de dados usa um pouco do armazenamento local antes mesmo de você carregar dados. É possível monitorar o armazenamento temporário disponível para uma instância de banco de dados específica com a métrica `FreeLocalStorage` do CloudWatch, descrita em [Métricas do Amazon CloudWatch para o Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Você pode verificar a quantidade de armazenamento gratuito no momento atual. Você também pode mapear a quantidade de armazenamento gratuito ao longo do tempo. Monitorar o armazenamento gratuito ao longo do tempo ajuda você a determinar se o valor está aumentando ou diminuindo, ou a encontrar os valores mínimo, máximo ou médio.
(Isso não se aplica ao Aurora Serverless v2.)
# Retroceder um cluster de banco de dados Aurora
Com o Amazon Aurora Edição compatível com MySQL, é possível retroceder um cluster de banco de dados a um período específico, sem restaurar os dados de um backup.
**Contents**
+ [Visão geral do retrocesso](#AuroraMySQL.Managing.Backtrack.Overview)
+ [Janela de retrocesso](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackWindow)
+ [Tempo de retrocesso](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackTime)
+ [Limitações de retrocesso](#AuroraMySQL.Managing.Backtrack.Limitations)
+ [Disponibilidade de regiões e versões](#AuroraMySQL.Managing.Backtrack.Availability)
+ [Considerações de atualização para clusters habilitados para o retrocesso](#AuroraMySQL.Managing.Backtrack.Upgrade)
+ [Configurar o retrocesso de um cluster de banco de dados do Aurora MySQL](AuroraMySQL.Managing.Backtrack.Configuring.md)
+ [Realizar um retrocesso de um cluster de banco de dados do Aurora MySQL](AuroraMySQL.Managing.Backtrack.Performing0.md)
+ [Monitorar o retrocesso de um cluster de banco de dados do Aurora MySQL](AuroraMySQL.Managing.Backtrack.Monitoring.md)
+ [Assinar um evento de retrocesso com o console](#AuroraMySQL.Managing.Backtrack.Event.Console)
+ [Recuperar retrocessos existentes](#AuroraMySQL.Managing.Backtrack.Retrieving)
+ [Desativar o retrocesso de um cluster de banco de dados do Aurora MySQL](AuroraMySQL.Managing.Backtrack.Disabling.md)
## Visão geral do retrocesso
O retrocesso retrocede o cluster de banco de dados ao período que você especificar. O retrocesso não é um substituto para o backup do cluster de banco de dados, para que você possa restaurá-lo para um período específico. No entanto, o retrocesso fornece as seguintes vantagens em relação ao backup e à restauração tradicionais:
+ É possível desfazer erros facilmente. Se, por engano, você executar uma ação destrutiva, como, por exemplo, um DELETE sem uma cláusula WHERE, é possível retroceder o cluster de banco de dados a um período anterior à ação destrutiva, com interrupção mínima do serviço.
+ É possível retroceder um cluster de banco de dados rapidamente. Restaurar um cluster de banco de dados para um período específico ativa um novo cluster de banco de dados e o restaura a partir de dados de backup ou de um snapshot de cluster de banco de dados, o que pode levar horas. O retrocesso de um cluster de banco de dados não requer um novo cluster de banco de dados e o retrocede em minutos.
+ É possível explorar alterações de dados anteriores. Você pode voltar e avançar o retrocesso de um cluster de banco de dados repetidamente para ajudar a determinar quando uma alteração de dados específica ocorreu. Por exemplo, você pode retroceder um cluster de banco de dados três horas e, em seguida, avançar uma hora. Nesse caso, o período do retrocesso é duas horas antes do período original.
**nota**
Para obter informações sobre como restaurar um cluster de banco de dados para um período específico, consulte [Visão geral do backup e da restauração de um cluster de banco de dados do Aurora](Aurora.Managing.Backups.md).
### Janela de retrocesso
Com o retrocesso, há uma janela de retrocesso de destino e uma janela de retrocesso real:
+ A *janela de retrocesso de destino* é a quantidade de tempo que você deseja poder retroceder seu cluster de banco de dados. Ao habilitar o retrocesso, você especifica uma *janela de retrocesso de destino*. Por exemplo, você pode especificar uma janela de retrocesso de destino de 24 horas se quiser retroceder o cluster de banco de dados um dia.
+ A *janela de retrocesso real* é a quantidade real de tempo para a qual você pode retroceder seu cluster de banco de dados, que pode ser menor que a janela de retrocesso de destino. A janela de retrocesso real é baseada em sua workload e no armazenamento disponível para armazenar informações sobre alterações no banco de dados, denominadas *registros de alterações.*
Ao atualizar seu cluster de banco de dados Aurora com o retrocesso habilitado, você gera registros de alterações. O Aurora retém os registros de alterações da janela de retrocesso de destino, e você paga uma taxa por hora para armazená-los. A janela de retrocesso de destino e a workload em seu cluster de banco de dados determinam o número de registros de alterações armazenados. A workload é o número de alterações feitas em seu cluster de banco de dados em um determinado período de tempo. Se sua workload for pesada, você armazenará mais registros de alterações em sua janela de retrocesso do que se sua workload for leve.
Você pode pensar em sua janela de retrocesso de destino como a meta para o período máximo de tempo que deseja retroceder seu cluster de banco de dados. Na maioria dos casos, você pode retroceder o tempo máximo que especificou. No entanto, em alguns casos, o cluster de banco de dados não pode armazenar registros de alterações suficientes para retroceder a quantidade máxima de tempo, além da janela de retrocesso real ser menor do que a meta. Normalmente, a janela de retrocesso real é menor que a meta quando você tem uma workload extremamente pesada em seu cluster de banco de dados. Quando a janela de retrocesso atual é menor que sua meta, enviamos uma notificação.
Quando o retrocesso é ativado para um cluster de banco de dados e você exclui uma tabela armazenada nele, o Aurora mantém essa tabela nos registros de alterações de retrocesso. Ele faz isso para que você possa reverter a um período anterior à exclusão da tabela. Se você não tiver espaço suficiente na sua janela de retrocesso para armazenar a tabela, ela poderá ser removida dos registros de alterações de retrocesso eventualmente.
### Tempo de retrocesso
O Aurora sempre retrocede a um período que seja consistente para o cluster de banco de dados. Isso elimina a possibilidade de transações não confirmadas quando o retrocesso é concluído. Quando você especifica um período para um retrocesso, o Aurora escolhe automaticamente o período consistente mais próximo possível. Essa abordagem significa que o retrocesso concluído pode não corresponder exatamente ao período especificado, mas você pode determinar o período exato para um retrocesso usando o comando [describe-db-cluster-backtracks ](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) da CLI da AWS. Para obter mais informações, consulte [Recuperar retrocessos existentes](#AuroraMySQL.Managing.Backtrack.Retrieving).
### Limitações de retrocesso
As limitações a seguir se aplicam ao retrocesso:
+ O retrocesso somente está disponível em clusters de banco de dados que foram criados com o recurso Retrocesso habilitado. Não é possível modificar um cluster de banco de dados para habilitar o recurso Backtrack. É possível habilitar o recurso Retrocesso ao criar um cluster de banco de dados ou restaurar um snapshot de um cluster de banco de dados.
+ O limite para uma janela de retrocesso é de 72 horas.
+ O retrocesso afeta todo o cluster de banco de dados. Por exemplo, você não pode seletivamente retroceder uma única tabela ou uma única atualização de dados.
+ Não é possível criar réplicas de leitura entre regiões usando um cluster habilitado para retrocesso, mas você pode habilitar a replicação de log binário (binlog) no cluster. Além disso, quando você tenta retroceder um cluster de banco de dados para o qual o registro em log binário está habilitado, normalmente ocorre um erro, a menos que você opte por forçar o retrocesso. Qualquer tentativa de forçar um retrocesso interromperá as réplicas de leitura posteriores e interferirá em outras operações, como implantações azul/verde.
+ Não é possível retroceder um clone do banco de dados a um período anterior à criação dele. No entanto, você pode usar o banco de dados original para retroceder a um período anterior à criação do clone. Para obter mais informações sobre clonagem de banco de dados, consulte [Clonar um volume para um cluster de banco de dados do Amazon Aurora](Aurora.Managing.Clone.md).
+ O retrocesso causa uma breve interrupção da instância de banco de dados. É necessário parar ou pausar seus aplicativos antes de iniciar uma operação de retrocesso para garantir que não haja novas solicitações de leitura ou gravação. Durante a operação de retrocesso, o Aurora pausa o banco de dados, fecha todas as conexões abertas e elimina leituras e gravações não confirmadas. Em seguida, aguarda a conclusão da operação de retrocesso.
+ Não é possível restaurar um snapshot entre regiões de um cluster habilitado para retrocesso em uma região da AWS que não oferece suporte ao retrocesso.
+ Se você executar um upgrade local para um cluster habilitado para retrocesso do Aurora MySQL versão 2 para a versão 3, não poderá retroceder a um ponto no tempo antes do upgrade.
## Disponibilidade de regiões e versões
O backtrack não está disponível para o Aurora PostgreSQL.
Veja a seguir os mecanismos compatíveis e a disponibilidade de regiões para o retrocesso com o Aurora MySQL.
| Região | Aurora MySQL versão 3 | Aurora MySQL versão 2 |
| --- | --- | --- |
| Leste dos EUA (Norte da Virgínia) | Todas as versões | Todas as versões |
| Leste dos EUA (Ohio) | Todas as versões | Todas as versões |
| Oeste dos EUA (Norte da Califórnia) | Todas as versões | Todas as versões |
| Oeste dos EUA (Oregon) | Todas as versões | Todas as versões |
| Africa (Cape Town) | – | – |
| Ásia-Pacífico (Hong Kong) | – | – |
| Ásia-Pacífico (Jacarta) | – | – |
| Ásia-Pacífico (Malásia) | – | – |
| Ásia-Pacífico (Melbourne) | – | – |
| Ásia-Pacífico (Mumbai) | Todas as versões | Todas as versões |
| Ásia-Pacífico (Nova Zelândia) | – | – |
| Ásia-Pacífico (Osaka) | Todas as versões | Versão 2.07.3 e posterior |
| Ásia-Pacífico (Seul) | Todas as versões | Todas as versões |
| Ásia-Pacífico (Singapura) | Todas as versões | Todas as versões |
| Ásia-Pacífico (Sydney) | Todas as versões | Todas as versões |
| Ásia-Pacífico (Taipei) | – | – |
| Ásia-Pacífico (Tailândia) | – | – |
| Ásia-Pacífico (Tóquio) | Todas as versões | Todas as versões |
| Canadá (Central) | Todas as versões | Todas as versões |
| Oeste do Canadá (Calgary) | – | – |
| China (Beijing) | – | – |
| China (Ningxia) | – | – |
| Europa (Frankfurt) | Todas as versões | Todas as versões |
| Europa (Irlanda) | Todas as versões | Todas as versões |
| Europa (Londres) | Todas as versões | Todas as versões |
| Europe (Milan) | – | – |
| Europe (Paris) | Todas as versões | Todas as versões |
| Europa (Espanha) | – | – |
| Europa (Estocolmo) | – | – |
| Europa (Zurique) | – | – |
| Israel (Tel Aviv) | – | – |
| México (Central) | – | – |
| Oriente Médio (Bahrein) | – | – |
| Oriente Médio (Emirados Árabes Unidos) | – | – |
| South America (São Paulo) | – | – |
| AWS GovCloud (Leste dos EUA) | – | – |
| AWS GovCloud (Oeste dos EUA) | – | – |
## Considerações de atualização para clusters habilitados para o retrocesso
Você pode fazer upgrade de um cluster de banco de dados habilitar para retrocesso do Aurora MySQL versão 2 para a versão 3, porque todas as versões secundárias do Aurora MySQL versão 3 são compatíveis com o recurso de retrocesso.
# Configurar o retrocesso de um cluster de banco de dados do Aurora MySQL
Para usar o recurso Retrocesso, é necessário ativar o retrocesso e especificar uma janela de retrocesso de destino. Caso contrário, o retrocesso será desativado.
Na janela de retrocesso de destino, especifique o tempo que você deseja retroceder em seu banco de dados usando Backtrack (Retrocesso). O Aurora tenta reter registros de alteração suficientes para suportar essa janela de tempo.
## Console
Você pode usar o console para configurar o retrocesso ao criar um novo cluster de banco de dados. Você também pode modificar um cluster de banco de dados para alterar a janela de retrocesso de um cluster habilitado para o retrocesso. Se você desativar totalmente o retrocesso em um cluster definindo a janela de retrocesso como 0, não poderá ativar o retrocesso novamente nesse cluster.
**Topics**
+ [Configurar o retrocesso com o console ao criar um cluster de banco de dados](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Creating)
+ [Configurar o retrocesso com o console ao modificar um cluster de banco de dados](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Modifying)
### Configurar o retrocesso com o console ao criar um cluster de banco de dados
Quando você cria um novo cluster de banco de dados Aurora MySQL, o retrocesso é configurado quando você escolhe **Enable Backtrack (Habilitar retrocesso)** e especifica um valor na **Target Backtrack window (Janela de retrocesso de destino)** que seja maior que zero na seção **Backtrack (Retrocesso)**.
Para criar um cluster de banco de dados, siga as instruções em [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md). A imagem a seguir mostra a seção **Retrocesso**.
![\[Habilitar o retrocesso durante a criação do cluster de banco de dados com o console\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-create.png)
Ao criar um novo cluster de banco de dados, o Aurora não possui dados para a workload do cluster de banco de dados. Portanto, não é possível estimar um custo especificamente para o novo cluster de banco de dados. Em vez disso, o console apresenta um custo de usuário típico na janela de retrocesso de destino especificada com base em uma workload comum. O custo típico serve para fornecer uma referência geral para o custo do recurso Retrocesso.
**Importante**
Seu custo real pode não corresponder ao custo típico, pois o custo real é baseado na workload do cluster de banco de dados.
### Configurar o retrocesso com o console ao modificar um cluster de banco de dados
Você pode modificar o retrocesso de um cluster de banco de dados usando o console.
**nota**
Atualmente, é possível modificar o retrocesso somente para um cluster de banco de dados que tenha o recurso Retrocesso habilitado. A seção **Backtrack (Retrocesso)** não é exibida para um cluster de banco de dados que foi criado com o recurso Retrocesso desabilitado ou se o recurso Retrocesso foi desabilitado para o cluster de banco de dados.
**Para modificar o retrocesso de um cluster de banco de dados usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Databases (Bancos de dados)**.
1. Escolha o cluster que deseja modificar e escolha **Modify (Modificar)**.
1. A **Target Backtrack window (Janela de retrocesso de destino)**, modifica a quantidade de tempo que você deseja retroceder seu cluster de banco de dados. O limite é de 72 horas.
![\[Modificar o retrocesso com o console\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-modify.png)
O console mostra o custo estimado da quantidade de tempo especificada com base na workload anterior do cluster de banco de dados:
+ Se o retrocesso foi desabilitado no cluster de banco de dados, a estimativa de custo é baseada na métrica `VolumeWriteIOPS` do cluster de banco de dados no Amazon CloudWatch.
+ Se o retrocesso foi ativado anteriormente no cluster de banco de dados, a estimativa de custo é baseada na métrica `BacktrackChangeRecordsCreationRate` do cluster de banco de dados no Amazon CloudWatch.
1. Escolha **Continue**.
1. Em **Scheduling of Modifications (Programação de modificações)**, selecione uma das seguintes opções:
+ **Apply during the next scheduled maintenance window (Aplicar durante a próxima janela de manutenção programada)** – esperar para aplicar a modificação da **Target Backtrack window (Janela de retrocesso de destino)** na próxima janela de manutenção.
+ **Apply immediately (Aplicar imediatamente)** – aplicar a modificação da **Target Backtrack window (Janela de retrocesso de destino)** o mais breve possível.
1. Selecione **Modify Cluster (Modificar cluster)**.
## AWS CLI
Ao criar um novo cluster de banco de dados Aurora MySQL usando o comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) da AWS CLI, o retrocesso é configurado quando você especifica um valor para `--backtrack-window` que seja maior que zero. O valor `--backtrack-window` especifica a janela de retrocesso de destino. Para obter mais informações, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md).
Você também pode especificar o valor de `--backtrack-window` usando os seguintes comandos da CLI da AWS:
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
+ [restore-db-cluster-from-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html)
+ [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)
O procedimento a seguir descreve como modificar a janela de retrocesso de destino para um cluster de banco de dados usando a AWS CLI.
**Para modificar a janela de retrocesso de destino para um cluster de banco de dados usando a AWS CLI**
+ Chame o comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) da CLI da AWS e forneça os seguintes valores:
+ `--db-cluster-identifier` – o nome do cluster de banco de dados.
+ `--backtrack-window` – o número máximo de segundos que você deseja retroceder o cluster de banco de dados.
O exemplo a seguir define a janela de retrocesso de destino do `sample-cluster` como um dia (86.400 segundos).
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 86400
```
Para Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 86400
```
**nota**
No momento, você pode ativar o retrocesso apenas para um cluster de banco de dados criado com o recurso Retrocesso ativado.
## API do RDS
Ao criar um novo cluster de banco de dados Aurora MySQL usando a operação [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) da API do Amazon RDS, o retrocesso é configurado ao especificar um valor para `BacktrackWindow` que seja maior que zero. O valor `BacktrackWindow` especifica a janela de retrocesso de destino para o cluster de banco de dados especificado no valor do `DBClusterIdentifier`. Para obter mais informações, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md).
Também é possível especificar o valor `BacktrackWindow` usando as seguintes operações da API:
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [RestoreDBClusterFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
+ [RestoreDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [RestoreDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
**nota**
No momento, você pode ativar o retrocesso apenas para um cluster de banco de dados criado com o recurso Retrocesso ativado.
# Realizar um retrocesso de um cluster de banco de dados do Aurora MySQL
Você pode retroceder um cluster de banco de dados a um time stamp de retrocesso especificado. Se o time stamp do retrocesso não for anterior ao período do retrocesso mais antigo possível, e não for um período futuro, o cluster de banco de dados será retrocedido a esse time stamp.
Caso contrário, geralmente ocorre um erro. Além disso, se você tentar retroceder um cluster de banco de dados para o qual o log binário está habilitado, um erro normalmente ocorre, a menos que você tenha optado por forçar que o retrocesso ocorra. Forçar que um retrocesso ocorra pode interferir em outras operações que usam o log binário.
**Importante**
O retrocesso não gera entradas de log binário para as alterações que ele faz. Se você tiver o log binário ativado para o cluster de banco de dados, o retrocesso poderá não ser compatível com sua implementação do log binário.
**nota**
Para clones de banco de dados, não é possível retroceder o cluster de banco de dados antes da data e da hora em que o clone foi criado. Para obter mais informações sobre clonagem de banco de dados, consulte [Clonar um volume para um cluster de banco de dados do Amazon Aurora](Aurora.Managing.Clone.md).
## Console
O procedimento a seguir descreve como executar uma operação de retrocesso para um cluster de banco de dados usando o console.
**Para executar uma operação de retrocesso usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Instances** (Instâncias).
1. Selecione a instância primária do cluster de banco de dados que deseja retroceder.
1. Em **Actions (Ações)**, escolha **Backtrack DB cluster (Retroceder cluster de banco de dados)**.
1. Na página **Backtrack DB cluster (Retroceder cluster de banco de dados)**, digite o timestamp do retrocesso para o qual retroceder o cluster de banco de dados.
![\[Retroceder cluster de banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-db-cluster.png)
1. Escolha **Backtrack DB cluster (Retroceder cluster de banco de dados)**
## AWS CLI
O procedimento a seguir descreve como retroceder um cluster de banco de dados usando a AWS CLI.
**Para retroceder um cluster de banco de dados usando a AWS CLI**
+ Chame o comando [backtrack-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/backtrack-db-cluster.html) da CLI da AWS e forneça os seguintes valores:
+ `--db-cluster-identifier` – o nome do cluster de banco de dados.
+ `--backtrack-to` – o time stamp de retrocesso segundo o qual você deseja retroceder o cluster de banco de dados, especificado no formato ISO 8601.
O exemplo a seguir retrocede o cluster de banco de dados `sample-cluster` a 19 de março de 2018, às 10h.
Para Linux, macOS ou Unix:
```
aws rds backtrack-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-to 2018-03-19T10:00:00+00:00
```
Para Windows:
```
aws rds backtrack-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-to 2018-03-19T10:00:00+00:00
```
## API do RDS
Para retroceder um cluster de banco de dados usando a API do Amazon RDS, use a ação [BacktrackDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BacktrackDBCluster.html). Essa ação retrocede o cluster de banco de dados especificado no valor do `DBClusterIdentifier` ao período especificado.
# Monitorar o retrocesso de um cluster de banco de dados do Aurora MySQL
Você pode visualizar informações de retrocesso e monitorar métricas de retrocesso para um cluster de banco de dados.
## Console
**Para visualizar informações de retrocesso e monitorar métricas de retrocesso usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Databases (Bancos de dados)**.
1. Escolha o nome do cluster de banco de dados para abrir informações sobre ele.
As informações de retrocesso estão na seção **Retrocesso**.
![\[Detalhes de retrocesso de um cluster de banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-details.png)
Quando o retrocesso é ativado, as seguintes informações ficam disponíveis:
+ **Target window (Janela de destino)** – o tempo especificado no momento para a janela de retrocesso de destino. O destino é o tempo máximo que você pode retroceder se houver armazenamento suficiente.
+ **Actual window (Janela real)** – o tempo real que você pode retroceder, que pode ser menor que a janela de retrocesso de destino. A janela de retrocesso real é baseada em sua workload e no armazenamento disponível para reter registros de alterações de retrocesso.
+ **Earliest backtrack time (Período de retrocesso mais antigo)** – o tempo de retrocesso mais antigo possível do cluster de banco de dados. Não é possível retroceder o cluster de banco de dados a um período anterior ao período exibido.
1. Faça o seguinte para visualizar métricas de retrocesso para o cluster de banco de dados:
1. No painel de navegação, escolha **Instances** (Instâncias).
1. Selecione o nome da instância primária do cluster de banco de dados para exibir seus detalhes.
1. Na seção **CloudWatch**, digite **Backtrack** na caixa **CloudWatch** para mostrar apenas as métricas do Retrocesso.
![\[Métricas de retrocesso\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-metrics.png)
As seguintes métricas são exibidas:
+ **Backtrack Change Records Creation Rate (Count) (Taxa de criação de registros de alterações de retrocesso (contagem))** – essa métrica mostra o número de registros de alterações de retrocesso criados no período de cinco minutos para o cluster de banco de dados. Você pode usar essa métrica para estimar o custo de retrocesso para a janela de retrocesso de destino.
+ **[Billed] Backtrack Change Records Stored (Count) ([Faturado] Registros de alterações de retrocesso armazenados (contagem))** – essa métrica mostra o número real de registros de alterações de retrocesso usados pelo cluster de banco de dados.
+ **Backtrack Window Actual (Minutes) (Janela de retrocesso real (minutos))** – essa métrica mostra se há uma diferença entre a janela de retrocesso de destino e a janela de retrocesso real. Por exemplo, se a janela de retrocesso de destino for de 2 horas (120 minutos) e essa métrica mostrar que a janela de retrocesso real é de 100 minutos, a janela de retrocesso real será menor que o destino.
+ **Backtrack Window Alert (Count) (Alerta da janela de retrocesso (contagem))** – essa métrica mostra com que frequência a janela de retrocesso real é menor que a janela de retrocesso de destino em um determinado período.
**nota**
As métricas a seguir podem atrasar o período atual:
**Backtrack Change Records Creation Rate (Count) (Taxa de criação de registros de alterações de retrocesso (contagem)**
**[Billed] Backtrack Change Records Stored (Count) ([Faturado] Registros de alterações de retrocesso armazenados (contagem)**
## AWS CLI
O procedimento a seguir descreve como visualizar as informações de retrocesso para um cluster de banco de dados usando a AWS CLI.
**Para visualizar informações de retrocesso para um cluster de banco de dados usando a AWS CLI**
+ Chame o comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) da CLI da AWS e forneça os seguintes valores:
+ `--db-cluster-identifier` – o nome do cluster de banco de dados.
O exemplo a seguir lista informações de retrocesso para o `sample-cluster`.
Para Linux, macOS ou Unix:
```
aws rds describe-db-clusters \
--db-cluster-identifier sample-cluster
```
Para Windows:
```
aws rds describe-db-clusters ^
--db-cluster-identifier sample-cluster
```
## API do RDS
Para visualizar informações de retrocesso para um cluster de banco de dados usando a API do Amazon RDS, use a operação [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html). Esta ação retorna informações de retrocesso para o cluster de banco de dados especificado no valor de `DBClusterIdentifier`.
## Assinar um evento de retrocesso com o console
O procedimento a seguir descreve como assinar um evento de retrocesso usando o console. O evento envia um email ou uma notificação de texto quando a janela de retrocesso real for menor que a janela de retrocesso de destino.
**Para visualizar informações de retrocesso usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Selecione **Event subscriptions (Assinaturas de eventos)**.
1. Selecione **Criar assinatura de evento**.
1. Na caixa **Name (Nome)**, digite um nome para a assinatura do evento e verifique se **Yes (Sim)** está selecionado para **Enabled (Ativado)**.
1. Na seção **Target (Destino)**, selecione **New email topic (Novo tópico de email)**.
1. Em **Topic name (Nome do tópico)**, digite um nome para o tópico e, em **With these recipients (Com estes destinatários)**, insira os endereços de e-mail ou números de telefone para receber as notificações.
1. Na seção **Source (Origem)**, selecione **Instances (Instâncias)** para **Source type (Tipo de origem)**.
1. Em **Instances to include (Instâncias a serem incluídas)**, selecione **Select specific instances (Selecionar instâncias específicas)** e escolha a instância de banco de dados.
1. Em **Event categories to include (Categorias de eventos a serem incluídas)**, selecione **Select specific event categories (Selecionar categorias de eventos específicos)** e escolha **backtrack (retrocesso)**.
A página deve ser semelhante à página a seguir.
![\[Assinatura de evento de retrocesso\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-event.png)
1. Escolha **Criar**.
## Recuperar retrocessos existentes
Você pode recuperar informações sobre retrocessos existentes para um cluster de banco de dados. Essas informações incluem o identificador exclusivo do retrocesso, a data e a hora para as quais e a partir das quais foi feito o retrocesso, a data e a hora em que o retrocesso foi solicitado e o status atual do retrocesso.
**nota**
Atualmente, não é possível recuperar retrocessos existentes usando o console.
### AWS CLI
O procedimento a seguir descreve como recuperar retrocessos existentes para um cluster de banco de dados usando a AWS CLI.
**Para recuperar retrocessos existentes usando a AWS CLI**
+ Chame o comando [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) da CLI da AWS e forneça os seguintes valores:
+ `--db-cluster-identifier` – o nome do cluster de banco de dados.
O exemplo a seguir recupera retrocessos existentes para o `sample-cluster`.
Para Linux, macOS ou Unix:
```
aws rds describe-db-cluster-backtracks \
--db-cluster-identifier sample-cluster
```
Para Windows:
```
aws rds describe-db-cluster-backtracks ^
--db-cluster-identifier sample-cluster
```
### API do RDS
Para recuperar informações sobre retrocessos para um cluster de banco de dados usando a API do Amazon RDS, use a operação [DescribeDBClusterBacktracks](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterBacktracks.html). Esta operação retorna informações sobre retrocessos para o cluster de banco de dados especificado no valor do `DBClusterIdentifier`.
# Desativar o retrocesso de um cluster de banco de dados do Aurora MySQL
É possível desativar o recurso Retrocesso para um cluster de banco de dados.
## Console
Você pode desativar o retrocesso para um cluster de banco de dados usando o console. Depois de desativar totalmente o retrocesso em um cluster, não será possível ativá-lo novamente nesse cluster.
**Para desativar o recurso de Retrocesso para um cluster de banco de dados usando o console.**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Databases (Bancos de dados)**.
1. Escolha o cluster que você deseja modificar e escolha **Modify (Modificar)**.
1. Na seção **Backtrack (Retrocesso)**, selecione **Disable Backtrack (Desativar retrocesso)**.
1. Escolha **Continue**.
1. Em **Scheduling of Modifications (Programação de modificações)**, selecione uma das seguintes opções:
+ **Apply during the next scheduled maintenance window (Aplicar durante a próxima janela de manutenção programada)** – esperar para aplicar a modificação na próxima janela de manutenção.
+ **Apply immediately (Aplicar imediatamente)** – aplicar a modificação o mais breve possível.
1. Escolha **Modify Cluster**.
## AWS CLI
Você pode desabilitar o recurso Retrocesso para um cluster de banco de dados usando a AWS CLI ao definir a janela de retrocesso de destino como `0` (zero). Depois de desativar totalmente o retrocesso em um cluster, não será possível ativá-lo novamente nesse cluster.
**Para modificar a janela de retrocesso de destino para um cluster de banco de dados usando a AWS CLI**
+ Chame o comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) da CLI da AWS e forneça os seguintes valores:
+ `--db-cluster-identifier` – o nome do cluster de banco de dados.
+ `--backtrack-window` – especificar `0` para desativar o retrocesso.
O exemplo a seguir desativa o recurso Retrocesso para o `sample-cluster` ao definir a `--backtrack-window` como `0`.
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 0
```
Para Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 0
```
## API do RDS
Para desabilitar o recurso Retrocesso para um cluster de banco de dados usando a API do Amazon RDS, use a operação [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Defina o valor da `BacktrackWindow` como `0` (zero) e especifique o cluster de banco de dados no valor do `DBClusterIdentifier`. Depois de desativar totalmente o retrocesso em um cluster, não será possível ativá-lo novamente nesse cluster.
# Testar o Amazon Aurora MySQL usando consultas de injeção de falhas
Você pode testar a tolerância a falhas do cluster de banco de dados Aurora MySQL usando consultas de injeção de falha. Consultas de injeção de falhas são emitidas como comandos SQL para uma instância do Amazon Aurora. Eles permitem que você agende uma ocorrência simulada de um dos seguintes eventos:
+ Uma falha de uma instância de banco de dados de gravação ou leitura
+ Uma falha de uma réplica do Aurora
+ Uma falha de disco
+ Congestionamento de disco
Quando uma consulta de injeção de falha especifica uma falha, ela força uma falha da instância de banco de dados do Aurora MySQL. As outras consultas de injeção de falha resultam em simulações de eventos de falha, mas não desencadeiam o evento. Ao enviar uma consulta de injeção de falha, especifique também um período para a simulação do evento de falha.
Você pode enviar uma consulta de injeção de falha a uma das instâncias da réplica do Aurora conectando-se ao endpoint da réplica do Aurora. Para obter mais informações, consulte [Conexões de endpoints do Amazon Aurora](Aurora.Overview.Endpoints.md).
A execução de consultas de injeção de falhas requer todos os privilégios de usuário principal. Para obter mais informações, consulte [Privilégios da conta de usuário mestre](UsingWithRDS.MasterAccounts.md).
## Teste de pane da instância
Você pode forçar uma pane em uma instância do Amazon Aurora usando a consulta de injeção de falha `ALTER SYSTEM CRASH`.
No que tange a essa consulta de injeção de falha, não ocorrerá um failover. Se desejar testar um failover, é possível escolher a ação de instância **Failover** para o cluster de banco de dados no console do RDS ou usar o comando [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) da AWS CLI ou a operação de API [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) do RDS.
### Sintaxe
```
1. ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];
```
### Opções
Esta consulta de injeção de falha considera um dos seguintes tipos de pane:
+ **`INSTANCE`** — uma pane é simulada no banco de dados compatível com MySQL para a instância do Amazon Aurora.
+ **`DISPATCHER`** — Uma falha no dispatcher é simulada na instância de gravador do cluster de banco de dados do Aurora. O *dispatcher* grava atualizações no volume do cluster para um cluster de banco de dados do Amazon Aurora.
+ **`NODE`** — uma pane é simulada no banco de dados compatível com MySQL e no dispatcher para a instância do Amazon Aurora. No que tange a essa simulação de injeção de falha, o cache também é excluído.
O tipo de pane padrão é `INSTANCE`.
## Teste de falha em uma réplica do Aurora
Você pode simular a falha de uma réplica do Aurora usando a consulta de injeção de falha `ALTER SYSTEM SIMULATE READ REPLICA FAILURE`.
Uma falha na réplica do Aurora bloqueia todas as solicitações feitas na instância do leitor a ela ou a todas as réplicas do Aurora no cluster de banco de dados durante um intervalo de tempo especificado. Quando o intervalo de tempo acabar, as réplicas do Aurora afetadas serão sincronizadas automaticamente com a instância do gravador.
### Sintaxe
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE
2. [ TO ALL | TO "replica name" ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opções
Esta consulta de injeção de falha considera os seguintes parâmetros:
+ **`percentage_of_failure`** — A porcentagem de solicitações para obstruir durante o evento de falha. Esse valor pode ser um duplo entre 0 e 100. Se você especificar 0, nenhuma solicitação será bloqueada. Se você especificar 100, todas as solicitações serão bloqueadas.
+ **Tipo de falha** — O tipo de falha a ser simulado. Especifique `TO ALL` para simular falhas para todas as réplicas do Aurora no cluster de banco de dados. Especifique `TO` e o nome da réplica do Aurora para simular uma falha de uma única réplica do Aurora. O tipo de falha padrão é `TO ALL`.
+ **`quantity`** — o tempo durante o qual a falha da réplica do Aurora será simulada. O intervalo é uma quantidade seguida por uma unidade de tempo. A simulação ocorrerá durante essa quantidade da unidade especificada. Por exemplo, `20 MINUTE` resultará na execução de uma simulação de 20 minutos.
**nota**
Especifique o intervalo de tempo do evento de falha da réplica do Aurora; com cautela. Se você especificar um intervalo de tempo muito longo e a instância de gravador gravar uma grande quantidade de dados durante o evento de falha, o cluster de banco de dados do Aurora poderá presumir que a réplica do Aurora falhou e substituí-la.
## Teste de uma falha de disco
Você pode simular a falha de um disco para um cluster de banco de dados do Aurora usando a consulta de injeção de falha `ALTER SYSTEM SIMULATE DISK FAILURE`.
Durante uma simulação de falha de disco, o cluster de banco de dados do Aurora marca aleatoriamente segmentos do disco como falhos. As solicitações feitas a esses segmentos serão bloqueadas enquanto durar a simulação.
### Sintaxe
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE
2. [ IN DISK index | NODE index ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opções
Esta consulta de injeção de falha considera os seguintes parâmetros:
+ **`percentage_of_failure`** — a porcentagem do disco para marcar como falha durante o evento de falha. Esse valor pode ser um duplo entre 0 e 100. Se você especificar 0, nenhum dos discos será marcado como falhos. Se você especificar 100, o disco todo será marcado como falho.
+ **`DISK index`** — um bloco de dados lógico específico para simular o evento de falha. Se você exceder o intervalo de blocos lógicos de dados disponíveis, receberá um erro informando o valor máximo do índice que você pode especificar. Para obter mais informações, consulte [Exibir o status do volume para um cluster de banco de dados Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`NODE index`** — um nó de armazenamento específico para simular o evento de falha. Se você exceder o intervalo de nós de armazenamento disponíveis, receberá um erro informando o valor máximo do índice que você pode especificar. Para obter mais informações, consulte [Exibir o status do volume para um cluster de banco de dados Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`quantity`** — o tempo durante o qual a falha do disco será simulada. O intervalo é uma quantidade seguida por uma unidade de tempo. A simulação ocorrerá durante essa quantidade da unidade especificada. Por exemplo, `20 MINUTE` resultará na execução de uma simulação de 20 minutos.
## Teste de congestionamento de disco
Você pode simular a falha de um disco para um cluster de banco de dados do Aurora usando a consulta de injeção de falha `ALTER SYSTEM SIMULATE DISK CONGESTION`.
Durante uma simulação de congestionamento de disco, o cluster de banco de dados do Aurora marca aleatoriamente segmentos do disco como congestionados. As solicitações feitas a esses segmentos serão atrasadas entre o tempo de atraso mínimo e máximo especificado enquanto durar a simulação.
### Sintaxe
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION
2. BETWEEN minimum AND maximum MILLISECONDS
3. [ IN DISK index | NODE index ]
4. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opções
Esta consulta de injeção de falha considera os seguintes parâmetros:
+ **`percentage_of_failure`** — a porcentagem do disco para marcar como congestionada durante o evento de falha. Esse valor pode ser um duplo entre 0 e 100. Se você especificar 0, nenhum dos discos será marcado como congestionados. Se você especificar 100, o disco todo será marcado como congestionado.
+ **`DISK index` ou `NODE index`** — um disco ou nó específico para simular o evento de falha. Se você exceder o intervalo de índices de disco ou de nó, receberá um erro informando o valor máximo do índice que você pode especificar.
+ **`minimum` e `maximum`** — a quantidade mínima e máxima de atraso de congestionamento em milissegundos. Os segmentos de disco marcados como congestionados serão atrasados durante um período aleatório de tempo dentro do intervalo mínimo e máximo de milissegundos enquanto durar a simulação.
+ **`quantity`** — o tempo durante o qual o congestionamento do disco será simulado. O intervalo é uma quantidade seguida por uma unidade de tempo. A simulação ocorrerá durante essa quantidade da unidade de tempo especificada. Por exemplo, `20 MINUTE` resultará na execução de uma simulação de 20 minutos.
# Alterar tabelas no Amazon Aurora usando a DDL rápida
O Amazon Aurora inclui otimizações para executar uma operação de `ALTER TABLE` localmente, de maneira quase instantânea. A operação é concluída sem exigir que a tabela seja copiada e sem causar impacto material em outras instruções de DML. Como a operação não consome armazenamento temporário para a cópia da tabela, as instruções de DDL são práticas mesmo para tabelas grandes em classes de instâncias pequenas.
O Aurora MySQL versão 3 é compatível com o recurso do MySQL 8.0 chamado DDL instantânea. O Aurora MySQL versão 2 utiliza uma implementação diferente, chamada DDL rápida.
**Topics**
+ [DDL instantânea (Aurora MySQL versão 3)](#AuroraMySQL.mysql80-instant-ddl)
+ [DDL rápida (Aurora MySQL versão 2)](#AuroraMySQL.Managing.FastDDL-v2)
## DDL instantânea (Aurora MySQL versão 3)
A otimização realizada pelo Aurora MySQL versão 3 para melhorar a eficiência de algumas operações de DDL é chamada de DDL instantânea.
O Aurora MySQL versão 3 é compatível com a DDL instantânea da comunidade do MySQL 8.0. Você realiza uma operação de DDL instantânea utilizando a cláusula `ALGORITHM=INSTANT` com a instrução `ALTER TABLE`. Para obter detalhes de sintaxe e uso sobre a DDL instantânea, consulte [ALTER TABLE](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) e [Operações online de DDL](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html) na documentação do MySQL.
Os seguintes exemplos demonstram o recurso de DDL instantânea. As instruções `ALTER TABLE` adicionam colunas e modificam valores de colunas padrão. Os exemplos incluem colunas regulares e virtuais, bem como tabelas regulares e particionadas. Em cada etapa, é possível ver os resultados emitindo instruções `SHOW CREATE TABLE` e `DESCRIBE`.
```
mysql> CREATE TABLE t1 (a INT, b INT, KEY(b)) PARTITION BY KEY(b) PARTITIONS 6;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t1 RENAME TO t2, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b SET DEFAULT 100, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b DROP DEFAULT, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN c ENUM('a', 'b', 'c'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 MODIFY COLUMN c ENUM('a', 'b', 'c', 'd', 'e'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN (d INT GENERATED ALWAYS AS (a + 1) VIRTUAL), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t2 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t3 (a INT, b INT) PARTITION BY LIST(a)(
-> PARTITION mypart1 VALUES IN (1,3,5),
-> PARTITION MyPart2 VALUES IN (2,4,6)
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> ALTER TABLE t3 ALTER COLUMN a SET DEFAULT 20, ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t4 (a INT, b INT) PARTITION BY RANGE(a)
-> (PARTITION p0 VALUES LESS THAN(100), PARTITION p1 VALUES LESS THAN(1000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE);
Query OK, 0 rows affected (0.05 sec)
mysql> ALTER TABLE t4 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
/* Sub-partitioning example */
mysql> CREATE TABLE ts (id INT, purchased DATE, a INT, b INT)
-> PARTITION BY RANGE( YEAR(purchased) )
-> SUBPARTITION BY HASH( TO_DAYS(purchased) )
-> SUBPARTITIONS 2 (
-> PARTITION p0 VALUES LESS THAN (1990),
-> PARTITION p1 VALUES LESS THAN (2000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE
-> );
Query OK, 0 rows affected (0.10 sec)
mysql> ALTER TABLE ts ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
```
## DDL rápida (Aurora MySQL versão 2)
A DDL rápida no Aurora MySQL é uma otimização projetada para melhorar o desempenho de determinadas alterações de esquema, como adicionar ou remover colunas, reduzindo o tempo de inatividade e o uso de recursos. Ela permite que essas operações sejam concluídas com mais eficiência em comparação com os métodos tradicionais de DDL.
**Importante**
No momento, é necessário habilitar o modo de laboratório do Aurora para usar a DDL rápida. Consulte informações sobre como habilitar o modo de laboratório em [Modo de laboratório do Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md).
A otimização da DDL rápida foi introduzida inicialmente no modo de laboratório no Aurora MySQL versão 2 para melhorar a eficiência de certas operações de DDL. No Aurora MySQL versão 3, o modo de laboratório foi descontinuado, e a DDL rápida foi substituída pelo recurso de DDL instantânea do MySQL 8.0.
No MySQL, muitas operações de linguagem de definição de dados (DDL) exercem um impacto significativo na performance.
Por exemplo, suponha que você usará uma operação `ALTER TABLE` para adicionar uma coluna a uma tabela. Dependendo do algoritmo especificado para a operação, esta operação pode envolver o seguinte:
+ A criação de uma cópia completa da tabela
+ A criação de uma tabela temporária para processar operações simultâneas de linguagem de manipulação de dados (DML)
+ A reconstrução de todos os índices da tabela
+ A aplicação de bloqueios à tabela ao fazer alterações de DML simultâneos
+ O desaceleramento da taxa de transferência de DML simultâneos
Esse impacto no desempenho pode ser particularmente desafiador em ambientes com tabelas grandes ou altos volumes de transações. A DDL rápida ajuda a mitigar esses desafios otimizando as alterações de esquema, o que permite operações mais rápidas e menos intensivas em recursos.
### Limitações de DDL rápido
No momento, a DDL rápida apresenta as seguintes limitações:
+ O DDL rápido oferece suporte somente à adição de colunas anuláveis, sem valores padrão, ao final de uma tabela existente.
+ O Fast DDL não funciona com tabelas particionadas.
+ O DDL rápido não funciona com tabelas do InnoDB que usam o formato de linha REDUNDANT.
+ O Fast DDL não funciona com tabelas com índices de pesquisa de texto completo.
+ Se o tamanho de registro possível máximo para a operação de DDL for muito grande, a DDL rápida não será utilizada. O registro será muito grande se for maior do que a metade do tamanho da página. O tamanho máximo de um registro é calculado adicionando os tamanhos máximos de todas as colunas. Para colunas de tamanho variado, de acordo com os padrões InnoDB, bytes extern não são incluídos para computação.
### Sintaxe DDL rápido
```
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
```
Esta instrução apresenta as seguintes opções:
+ **`tbl_name` — **o nome da tabela a ser modificada.
+ **`col_name` — **o nome da coluna a ser adicionada.
+ **`col_definition` — **a definição da coluna a ser adicionada.
**nota**
Você deve especificar uma definição de coluna anulável sem um valor padrão. Caso contrário, a DDL rápida não será usada.
### Exemplos DDL rápido
Os exemplos a seguir demonstram a aceleração de operações de DDL rápida. O primeiro exemplo SQL executa instruções `ALTER TABLE` em uma tabela grande sem usar a DDL rápida. Esta operação leva um tempo considerável. Um exemplo da CLI mostra como permitir a DDL rápida para o cluster. Em seguida, outro exemplo SQL executa as mesmas instruções `ALTER TABLE` em uma tabela idêntica. Com a DDL rápida habilitada, a operação é muito rápida.
Este exemplo usa a tabela de`ORDERS` do benchmark TPC-H, contendo 150 milhões de linhas. Este cluster usa intencionalmente uma classe de instância relativamente pequena, para demonstrar quanto tempo as instruções `ALTER TABLE` podem demorar quando você não pode usar a DDL rápida. O exemplo cria um clone da tabela original contendo dados idênticos. Verificar a configuração de `aurora_lab_mode` confirma que o cluster não pode usar a DDL rápida, porque o modo de laboratório não está habilitado. Em seguida, as instruções de `ALTER TABLE ADD COLUMN` levam um tempo considerável para adicionar novas colunas no final da tabela.
```
mysql> create table orders_regular_ddl like orders;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into orders_regular_ddl select * from orders;
Query OK, 150000000 rows affected (1 hour 1 min 25.46 sec)
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 0 |
+-------------------+
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (40 min 31.41 sec)
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (40 min 44.45 sec)
```
Este exemplo faz a mesma preparação de uma tabela grande que o exemplo anterior. No entanto, você não pode simplesmente habilitar o modo de laboratório em uma sessão SQL interativa. Essa configuração deve ser ativada em um grupo de parâmetro personalizado. Isso requer a troca da sessão `mysql` e a execução de alguns comandos de CLI da AWS ou usar o Console de gerenciamento da AWS.
```
mysql> create table orders_fast_ddl like orders;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into orders_fast_ddl select * from orders;
Query OK, 150000000 rows affected (58 min 3.25 sec)
mysql> set aurora_lab_mode=1;
ERROR 1238 (HY000): Variable 'aurora_lab_mode' is a read only variable
```
Habilitar o modo de laboratório para o cluster requer algum trabalho com um grupo de parâmetro. Este exemplo de AWS CLI usa um grupo de parâmetros de cluster, para garantir que todas as instâncias de banco de dados no cluster usem o mesmo valor para a configuração do modo de laboratório.
```
$ aws rds create-db-cluster-parameter-group \
--db-parameter-group-family aurora5.7 \
--db-cluster-parameter-group-name lab-mode-enabled-57 --description 'TBD'
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].[ParameterName,ParameterValue]' \
--output text | grep aurora_lab_mode
aurora_lab_mode 0
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--parameters ParameterName=aurora_lab_mode,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lab-mode-enabled-57"
}
# Assign the custom parameter group to the cluster that's going to use Fast DDL.
$ aws rds modify-db-cluster --db-cluster-identifier tpch100g \
--db-cluster-parameter-group-name lab-mode-enabled-57
{
"DBClusterIdentifier": "tpch100g",
"DBClusterParameterGroup": "lab-mode-enabled-57",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.2",
"Status": "available"
}
# Reboot the primary instance for the cluster tpch100g:
$ aws rds reboot-db-instance --db-instance-identifier instance-2020-12-22-5208
{
"DBInstanceIdentifier": "instance-2020-12-22-5208",
"DBInstanceStatus": "rebooting"
}
$ aws rds describe-db-clusters --db-cluster-identifier tpch100g \
--query '*[].[DBClusterParameterGroup]' --output text
lab-mode-enabled-57
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
--output text | grep aurora_lab_mode
aurora_lab_mode 1
```
O exemplo a seguir mostra as etapas restantes depois que a alteração do grupo de parâmetro tem efeito. Ele testa a configuração de `aurora_lab_mode` para certificar-se de que o cluster pode usar a DDL rápida. Em seguida, ele executa as instruções de `ALTER TABLE` para adicionar colunas ao final de outra tabela grande. Desta vez, as instruções terminam muito rapidamente.
```
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 1 |
+-------------------+
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (1.51 sec)
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (0.40 sec)
```
# Exibir o status do volume para um cluster de banco de dados Aurora MySQL
No Amazon Aurora, um volume de cluster de banco de dados consiste em um acervo de blocos lógicos. Cada um deles representa 10 gigabytes de armazenamento alocado. Esses blocos são chamados de *grupos de proteção*.
Os dados em cada grupo de proteção são replicados entre seis dispositivos de armazenamento físico, chamados de *nós de armazenamento*. Esses nós de armazenamento são alocados em três zonas de disponibilidade (AZs) na região AWS em que reside o cluster de banco de dados. Por sua vez, cada nó de armazenamento contém um ou mais blocos lógicos de dados para o volume do cluster de banco de dados. Para obter mais informações sobre os grupos de proteção e os nós de armazenamento, consulte [ Introducing the Aurora storage engine (Apresentação do mecanismo de armazenamento do Aurora)](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) no blog de banco de dados da AWS.
Você pode simular a falha de um nó de armazenamento completo ou de um único bloco lógicos de dados dentro de um nó de armazenamento. Para fazer isso, use a instrução de injeção de falha `ALTER SYSTEM SIMULATE DISK FAILURE`. Para a instrução, especifique o valor do índice de um bloco lógico de dados ou de um nó de armazenamento específico. No entanto, se você especificar um valor de índice maior do que o número de blocos lógicos de dados ou de nós de armazenamento usados pelo volume do cluster de banco de dados, a instrução retornará um erro. Para obter mais informações sobre as consultas de injeção de falha, veja [Testar o Amazon Aurora MySQL usando consultas de injeção de falhas](AuroraMySQL.Managing.FaultInjectionQueries.md).
Você pode evitar esse erro usando a instrução `SHOW VOLUME STATUS`. A instrução retorna duas variáveis de status do servidor, `Disks` e `Nodes`. Essas variáveis representam o número total de blocos lógicos de dados e de nós de armazenamento, respectivamente, para o volume do cluster de banco de dados.
## Sintaxe
```
SHOW VOLUME STATUS
```
## Exemplo
O exemplo a seguir ilustra um resultado típico de SHOW VOLUME STATUS.
```
mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
```