Tempo limite de transição Barreiras de proteção de transição Ações de transição Práticas recomendadas de transição Verificar as métricas do CloudWatch antes da transição Monitorar o atraso da réplica antes da transição Realizar a transição de uma implantação azul/verde Após a transição

Alternar uma implantação azul/verde

Uma transição promove o cluster de banco de dados, incluindo suas instâncias de banco de dados, no ambiente verde ao cluster de banco de dados de produção. Antes de fazer a transição, o tráfego de produção é roteado para o cluster no ambiente azul. Depois de fazer a transição, o tráfego de produção é roteado para o cluster de banco de dados no ambiente verde.

Tópicos

Tempo limite de transição
Barreiras de proteção de transição
Ações de transição
Práticas recomendadas de transição
Verificar as métricas do CloudWatch antes da transição
Monitorar o atraso da réplica antes da transição
Realizar a transição de uma implantação azul/verde
Após a transição

Tempo limite de transição

Você pode especificar um tempo limite de transição entre 30 segundos e 3.600 segundos (uma hora). Se a transição demorar mais do que o especificado, todas as alterações serão revertidas e nenhuma alteração será feita em nenhum dos ambientes. O limite de tempo padrão é 300 segundos (cinco minutos).

Barreiras de proteção de transição

Quando você inicia uma transição, o Amazon RDS executa algumas verificações básicas para testar a prontidão dos ambientes azul e verde para a transição. Essas verificações são conhecidas como barreiras de proteção de transição. Essas barreiras evitarão uma transição se os ambientes não estiverem prontos para isso. Portanto, elas evitam tempo de inatividade mais longo do que o esperado e evitam a perda de dados entre os ambientes azul e verde que pode ocorrer se a transição for iniciada.

O Amazon RDS executa as seguintes verificações de barreira de proteção no ambiente verde:

Integridade da replicação: confira se o status de replicação da instância de banco de dados primária do cluster de banco de dados verde é íntegro. O cluster de banco de dados verde é uma réplica do cluster de banco de dados azul.
Atraso na replicação: confira se o atraso da réplica do cluster de banco de dados está nos limites permitidos para a transição. Os limites permitidos são baseados no tempo limite especificado. O atraso da réplica indica até que ponto o cluster de banco de dados verde está atrás de seu cluster de banco de dados azul. Para obter mais informações, consulte Diagnosticar e resolver atrasos entre réplicas de leitura para Aurora PostgreSQL.
Gravações ativas: certifique-se de que não haja gravações ativas no cluster de banco de dados.

O Amazon RDS executa as seguintes verificações de barreira de proteção no ambiente azul:

Replicação externa: para o Aurora PostgreSQL, garante que o ambiente azul não seja uma fonte lógica autogerenciada (publicador) nem uma réplica (assinante). Se ele for, recomendamos que você elimine os slots de replicação autogerenciados e as assinaturas em todos os bancos de dados no ambiente azul, continue com a transição e, depois, recrie-os para retomar a replicação. Para o Aurora MySQL, verifica se o banco de dados azul não é uma réplica externa de log binário. Se for, verifique se ele não está se replicando ativamente.
Gravações ativas de longa duração: verifica se não há gravações ativas de longa duração no cluster de banco de dados azul, pois elas podem aumentar o atraso da réplica.
Instruções DDL de longa duração: verifica se não há instruções DDL de longa duração no cluster de banco de dados azul, pois elas podem aumentar o atraso da réplica.
Alterações não compatíveis do PostgreSQL: para clusters de banco de dados do Aurora PostgreSQL, verifica se não há nenhuma alteração de DDL e se nenhuma adição ou modificação de objetos grandes foi realizada no ambiente azul. Para ter mais informações, consulte Limitações de replicação lógica do PostgreSQL para implantações azul/verde.

Se o Amazon RDS detectar alterações não compatíveis do PostgreSQL, ele alterará o estado de replicação para Replication degraded e notificará você de que a transição não está disponível para a implantação azul/verde. Para continuar com a transição, recomendamos que você exclua e recrie a implantação azul/verde e todos os bancos de dados verdes. Para fazer isso, escolha Ações, Excluir com bancos de dados verdes.

Ações de transição

Quando você alterna uma implantação azul/verde, o RDS realiza as seguintes ações:

Executa verificações de barreira de proteção para verificar se os ambientes azul e verde estão prontos para a transição.
Interrompe novas operações de gravação na no cluster de banco de dados nos dois ambientes.
Descarta conexões com as instâncias de banco de dados em ambos os ambientes e não permite novas conexões.
Espera que a replicação alcance o ambiente verde para que este esteja em sincronia com o ambiente azul.
Renomeia de banco de dados o cluster e instâncias de banco de dados nos dois ambientes.

O RDS renomeia de banco de dados o cluster e as instâncias de banco de dados no ambiente verde para corresponder de banco de dados ao cluster e às instâncias de banco de dados no ambiente azul. Por exemplo, suponha que o nome de uma instância de banco de dados no ambiente azul seja mydb. Suponha também que o nome da instância de banco de dados correspondente no ambiente verde seja mydb-green-abc123. Durante a transição, o nome da instância de banco de dados no ambiente verde é alterado para mydb.

O RDS renomeia o cluster e as instâncias de banco de dados no ambiente azul anexando -oldn ao nome atual, em que n é um número. Por exemplo, suponha que o nome de uma instância de banco de dados no ambiente azul seja mydb. Após a transição, o nome da instância de banco de dados pode ser mydb-old1.

O RDS também renomeia os endpoints no ambiente verde para corresponder aos endpoints correspondentes no ambiente azul, para que as alterações na aplicação não sejam necessárias.
Permite conexões com bancos de dados nos dois ambientes.
Permite operações de gravação no cluster de banco de dados no novo ambiente de produção.

Após a transição, o cluster de banco de dados da produção anterior só permitirá operações de leitura. Mesmo se você desabilitar o parâmetro read_only no cluster de banco de dados, ele permanecerá somente leitura até que você exclua a implantação azul/verde.

Você pode monitorar o status de uma transição usando o Amazon EventBridge. Para ter mais informações, consulte Eventos de implantação azul/verde.

Se você tiver tags configuradas no ambiente azul, essas tags serão movidas para o novo ambiente de produção durante a transição. O ambiente de produção anterior também retém essas tags. Para ter mais informações sobre tags, consulte Marcar recursos do Amazon RDS.

Se a transição começar e parar antes de terminar por qualquer motivo, todas as alterações serão revertidas e nenhuma alteração será feita em nenhum dos ambientes.

Práticas recomendadas de transição

Antes de fazer a transição, é altamente recomendável que você siga as práticas recomendadas concluindo as seguintes tarefas:

Teste minuciosamente os recursos no ambiente verde. Eles devem funcionar de forma adequada e eficiente.
Monitore as métricas relevantes do Amazon CloudWatch. Para ter mais informações, consulte Verificar as métricas do CloudWatch antes da transição.
Identifique o melhor momento para a transição.

Durante a transição, as gravações são cortadas dos bancos de dados nos dois ambientes. Identifique um momento em que o tráfego é o menor em seu ambiente de produção. Transações de longa duração, como DDLs ativas, podem aumentar seu tempo de transição, ocasionando maior tempo de inatividade para suas workloads de produção.

Se houver um grande número de conexões em seu cluster de banco de dados e instâncias de banco de dados, considere reduzi-las manualmente até a quantidade mínima necessária para sua aplicação antes de realizar a transição da implantação azul/verde. Uma maneira de fazer isso é criar um script que monitore o status da implantação azul/verde e comece a limpar as conexões quando detectar que o status mudou para SWITCHOVER_IN_PROGRESS.
O cluster e as instâncias de banco de dados nos dois ambientes devem estar no estado Available.
O cluster de banco de dados no ambiente verde devem estar funcionando e sendo replicado.
Garanta que suas configurações de rede e cliente não aumentem o tempo de vida útil (TTL) do cache DNS além de cinco segundos, que é o padrão para zonas DNS do Aurora .  Caso contrário, as aplicações continuarão a enviar tráfego de gravação ao ambiente azul após  transição.
Para clusters de banco de dados do Aurora PostgreSQL, faça o seguinte:
- Analise as limitações de replicação lógica e realize todas as ações necessárias antes da transição. Para ter mais informações, consulte Limitações de replicação lógica do PostgreSQL para implantações azul/verde.
- Execute a operação ANALYZE para atualizar a tabela pg_statistics. Isso reduz o risco de problemas de desempenho após a transição.

nota

Durante uma transição, você não pode modificar nenhum cluster de banco de dados incluído na transição.

Verificar as métricas do CloudWatch antes da transição

Antes de realizar a transição de uma implantação azul/verde, recomendamos que verifique os valores das métricas a seguir no Amazon CloudWatch.

DatabaseConnections: use esta métrica para estimar o nível de atividade na implantação azul/verde; certifique-se de que o valor esteja em um nível aceitável para sua implantação antes da transição. Se o recurso Insights de Performance estiver ativado, DBLoad será uma métrica mais precisa.
ActiveTransactions: se innodb_monitor_enable estiver definido como all no grupo de parâmetros de banco de dados para qualquer uma de suas instâncias de banco de dados, use esta métrica para ver se há um grande número de transações ativas que podem bloquear a transição.

Para ter mais informações sobre essas métricas, consulte Métricas do Amazon CloudWatch para o Amazon Aurora.

Monitorar o atraso da réplica antes da transição

Antes de realizar a transição de uma implantação azul/verde, verifique se o atraso de réplica no banco de dados verde é próximo de zero para reduzir o tempo de inatividade.

Para o Aurora MySQL, use a métrica AuroraBinlogReplicaLag do CloudWatch para identificar o atraso de replicação atual no ambiente verde.

Para o Aurora PostgreSQL, use a seguinte consulta SQL:


SELECT slot_name,
       confirmed_flush_lsn as flushed,
       pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';

slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192

O confirmed_flush_lsn representa o número de sequência de log (LSN) mais recente enviado à réplica. O pg_current_wal_lsn representa onde o banco de dados está agora. Um lsn_distance de 0 significa que a réplica foi capturada.

Realizar a transição de uma implantação azul/verde

Você pode fazer a transição de uma implantação azul/verde usando o AWS Management Console, a AWS CLI ou a API do RDS.

Como realizar a transição de uma implantação azul/verde

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, selecione Databases (Bancos de dados) e, depois, selecione a implantação azul/verde da qual você deseja realizar a transição.
Para Actions (Ações), selecione Switch over (Realizar transição).

A página Switch over (Realizar transição) é exibida.
Na página Switch over (Realizar transição), revise o resumo da transição. Os recursos nos dois ambientes devem corresponder ao que você espera. Caso contrário, selecione Cancel (Cancelar).
Em Timeout (Tempo limite), insira o limite de tempo para a transição.
Se seu cluster estiver executando o Aurora PostgreSQL, a instância , analise e confirme as recomendações de pré-transição. Para ter mais informações, consulte Limitações de replicação lógica do PostgreSQL para implantações azul/verde.
Selecione Switch Role (Realizar transição).

Para realizar a transição de uma implantação azul/verde usando a AWS CLI, utilize o comando switchover-blue-green-deployment com as seguintes opções:

--blue-green-deployment-identifier: especifique o ID do recurso da implantação azul/verde.
--switchover-timeout: especifique o limite de tempo para a transição, em segundos. O padrão é 300.

exemplo Fazer a transição de uma implantação azul/verde

Para Linux, macOS ou Unix:


aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600

Para Windows:


aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600

Para realizar a transição de uma implantação azul/verde usando a API do Amazon RDS, use a operação SwitchoverBlueGreenDeployment com os seguintes parâmetros:

BlueGreenDeploymentIdentifier: especifique o ID do recurso da implantação azul/verde.
SwitchoverTimeout: especifique o limite de tempo para a transição, em segundos. O padrão é 300.

Após a transição

Depois de uma transição, o cluster e as instâncias de banco de dados no ambiente azul anterior são retidos. Os custos padrão se aplicam a esses recursos. A replicação entre os ambientes azul e verde é interrompida, bem como o registro em log binário.

O RDS renomeia o cluster e as instâncias de banco de dados no ambiente azul anexando -oldn ao nome de recurso atual, em que n é um número. O cluster de banco de dados é forçado a entrar em um estado somente leitura. Mesmo se você desabilitar o parâmetro read_only no cluster de banco de dados, ele permanecerá somente leitura até que você exclua a implantação azul/verde.

Depois de realizar a transição de uma implantação azul/verde

Atualizar o nó principal para consumidores

Depois de fazer a transição de uma implantação azul/verde do Aurora MySQL, se o cluster de banco de dados tiver alguma réplica externa ou consumidores de log binário antes da transição, será necessário atualizar o nó principal após a transição para manter a continuidade da replicação.

Após a transição, a instância de banco de dados de gravador que estava anteriormente no ambiente verde emite um evento que contém o nome do arquivo de log principal e a posição do log principal. Por exemplo:


aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier

{
    "Events": [
...
        {
            "SourceIdentifier": "db-instance-identifier",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000003 and position 804",
            "EventCategories": [],
            "Date": "2023-11-10T01:33:41.911Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier"
        }
    ]
}

Primeiro, garanta que o consumidor ou a réplica tenha aplicado todos os logs binários do antigo ambiente azul. Depois, use as coordenadas do log binário fornecidas para retomar a aplicação nos consumidores. Por exemplo, se você estiver executando uma réplica do MySQL no EC2, poderá usar o comando CHANGE MASTER TO:


CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Visualizar uma implantação azul/verde

Excluir uma implantação azul/verde