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.
Sumário
- Visão geral do retrocesso
- Disponibilidade de região e versão
- Considerações de atualização para clusters habilitados para o retrocesso
- Configurar o retrocesso de um cluster de banco de dados do Aurora MySQL
- Realizar um retrocesso de um cluster de banco de dados do Aurora MySQL
- Monitorar o retrocesso de um cluster de banco de dados do Aurora MySQL
- Assinar um evento de retrocesso com o console
- Recuperar retrocessos existentes
- Desativar o retrocesso de um cluster de banco de dados do Aurora MySQL
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.
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 da CLI da AWS. Para obter mais informações, consulte Recuperar retrocessos existentes.
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.
-
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ão e versão
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 (N. 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 (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 (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 (Pequim) | – | – |
| 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) | – | – |
| Oriente Médio (Barém) | – | – |
| 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.
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
Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/
. -
Selecione Event subscriptions (Assinaturas de eventos).
-
Selecione Criar assinatura de evento.
-
Na caixa Name (Nome), digite um nome para a assinatura do evento e verifique se Yes (Sim) está selecionado para Enabled (Ativado).
-
Na seção Target (Destino), selecione New email topic (Novo tópico de email).
-
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.
-
Na seção Source (Origem), selecione Instances (Instâncias) para Source type (Tipo de origem).
-
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.
-
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.
-
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.
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 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-clusterPara Windows:
aws rds describe-db-cluster-backtracks ^ --db-cluster-identifier sample-cluster -
Para recuperar informações sobre retrocessos para um cluster de banco de dados usando a API do Amazon RDS, use a operação DescribeDBClusterBacktracks. Esta operação retorna informações sobre retrocessos para o cluster de banco de dados especificado no valor do DBClusterIdentifier.
