# Usar implantações azul/verde do Amazon Aurora para atualizações de banco de dados
Uma implantação azul/verde copia um ambiente de banco de dados de produção em um ambiente de teste separado e sincronizado. Usando as implantações azul/verde do Amazon Aurora, é possível fazer alterações no banco de dados no ambiente de teste sem prejudicar o ambiente de produção. Por exemplo, você pode atualizar a versão principal ou secundária do mecanismo de banco de dados ou alterar parâmetros do banco de dados no ambiente de preparação. Quando estiver tudo pronto, você poderá promover o ambiente de teste como o novo ambiente de banco de dados de produção, com tempo de inatividade normalmente inferior a um minuto.
O Amazon Aurora cria o ambiente de preparação *clonando* o volume de armazenamento subjacente do Aurora no ambiente de produção. O volume do cluster no ambiente de preparação armazena somente as alterações incrementais feitas nesse ambiente.
**nota**
No momento, as implantações azul/verde são compatíveis apenas com o Aurora MySQL, Aurora PostgreSQL e Aurora Global Database. Para saber a disponibilidade do mecanismo do Amazon RDS, consulte [Using Amazon RDS Blue/Green Deployments for database updates](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) no *Guia do usuário do Amazon RDS*.
**Topics**
+ [Visão geral das implantações azul/verde do Amazon Aurora](blue-green-deployments-overview.md)
+ [Criar uma implantação azul/verde no Amazon Aurora](blue-green-deployments-creating.md)
+ [Visualizar uma implantação azul/verde no Amazon Aurora](blue-green-deployments-viewing.md)
+ [Mudar uma implantação azul/verde no Amazon Aurora](blue-green-deployments-switching.md)
+ [Excluir uma implantação azul/verde no Amazon Aurora](blue-green-deployments-deleting.md)
# Visão geral das implantações azul/verde do Amazon Aurora
Ao usar implantações azul/verde do Amazon Aurora, é possível fazer e testar alterações no banco de dados antes de implementá-las em um ambiente de produção. Uma *implantação azul/verde* cria um ambiente de teste que copia o ambiente de produção. Em uma implantação azul/verde, o *ambiente azul* é o ambiente de produção atual. O *ambiente verde* é o ambiente de preparação e permanece sincronizado com o ambiente de produção atual.
Você pode fazer alterações no cluster de banco de dados do RDS no ambiente verde sem afetar as workloads de produção. Por exemplo, você pode atualizar a versão principal ou secundária do mecanismo de banco de dados ou alterar os parâmetros do banco de dados no ambiente de preparação. Você pode testar minuciosamente as alterações no ambiente verde. Quando estiver tudo pronto, você poderá *fazer a transição* do ambiente verde para o novo ambiente de produção. A transição normalmente leva menos de um minuto, sem perda de dados e sem necessidade de alterações na aplicação.
Como o ambiente verde é uma cópia da topologia do ambiente de produção, o cluster de banco de dados e todas as suas instâncias de banco de dados são copiados na implantação. O ambiente verde também inclui os recursos usados pelo cluster de banco de dados, como snapshots do cluster de banco de dados, Performance Insights, monitoramento aprimorado e o Aurora Serverless v2.
**nota**
Implantações azul/verde são aceitas pelo Aurora MySQL, o Aurora PostgreSQL e o Aurora Global Database. Para ter informações sobre a disponibilidade do RDS, consulte [Visão geral das implantações azul/verde do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html) no *Guia do usuário do Amazon RDS*.
**Topics**
+ [Disponibilidade de região e versão](#blue-green-deployments-region-version-availability)
+ [Benefícios do uso de implantações azul/verde do Amazon RDS](#blue-green-deployments-benefits)
+ [Fluxo de trabalho de uma implantação azul/verde](#blue-green-deployments-major-steps)
+ [Autorizar o acesso às operações de implantação azul/verde do Amazon Aurora](blue-green-deployments-authorizing-access.md)
+ [Limitações e considerações relativas às implantações azul/verde do Amazon Aurora](blue-green-deployments-considerations.md)
+ [Práticas recomendadas para implantações azul/verde do Amazon Aurora](blue-green-deployments-best-practices.md)
## Disponibilidade de região e versão
A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados e entre Regiões da AWS. Para obter mais informações, consulte [Regiões e mecanismos de banco de dados do Aurora compatíveis com implantações azul/verde](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md).
## Benefícios do uso de implantações azul/verde do Amazon RDS
Ao usar implantações azul/verde do Amazon RDS, você pode se manter atualizado sobre os patches de segurança, melhorar a performance do banco de dados e adotar novos recursos de banco de dados com um tempo de inatividade curto e previsível. As implantações azul/verde reduzem os riscos e o tempo de inatividade das atualizações do banco de dados, como atualizações principais ou secundárias de versões do mecanismo.
As implantações azul/verde oferecem os seguintes benefícios:
+ Crie facilmente um ambiente de teste pronto para produção.
+ Replique automaticamente as alterações do banco de dados do ambiente de produção para o ambiente de teste.
+ Teste as alterações do banco de dados em um ambiente de teste seguro sem afetar o ambiente de produção.
+ Mantenha-se atualizado com os patches do banco de dados e as atualizações do sistema.
+ Implemente e teste novos recursos de banco de dados.
+ Faça a transição de seu ambiente de teste para ser o novo ambiente de produção sem alterações em sua aplicação.
+ Faça a transição com segurança por meio do uso de grades de proteção de transição integradas.
+ Elimine a perda de dados durante a transição.
+ Faça a transição rapidamente, normalmente em menos de um minuto, dependendo da sua workload.
## Fluxo de trabalho de uma implantação azul/verde
Conclua as etapas principais a seguir ao usar uma implantação azul/verde para atualizações do cluster de banco de dados do Aurora.
1. Identifique um cluster de banco de dados de produção que exija atualizações.
A imagem a seguir mostra um exemplo de cluster de banco de dados de produção.
![\[Cluster de banco de dados do de produção (azul) em uma implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png)
1. Crie a implantação azul/verde Para instruções, consulte [Criar uma implantação azul/verde no Amazon Aurora](blue-green-deployments-creating.md).
A imagem a seguir mostra um exemplo de implantação azul/verde do ambiente de produção da etapa 1. Ao criar a implantação azul/verde, o RDS copia a topologia e a configuração completas do cluster de banco de dados do Aurora para criar o ambiente verde. Os nomes do cluster e das instâncias de banco de dados copiados são anexados com `-green-random-characters`. O ambiente de teste na imagem contém o cluster de banco de dados (auroradb-green-**abc123**). Ele também contém as três instâncias de banco de dados no cluster de banco de dados (auroradb-instance1-green-**abc123**, auroradb-instance2-green-**abc123** e auroradb-instance3-green-**abc123**).
![\[Implantação azul/verde do Amazon Aurora\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png)
Ao criar a implantação azul/verde, você pode especificar uma versão do mecanismo de banco de dados posterior e um grupo de parâmetros de banco de dados diferente para o cluster de banco de dados no ambiente verde. Você também pode especificar um grupo de parâmetros de banco de dados diferente para as instâncias de banco de dados no cluster de banco de dados.
O RDS também configura a replicação da instância de banco de dados primária no ambiente azul para a instância de banco de dados primária no ambiente verde.
**Importante**
Em relação ao Aurora MySQL versão 3, depois de criar a implantação azul/verde, o cluster de banco de dados no ambiente verde permite operações de gravação por padrão. No entanto, isso não se aplica aos usuários que têm o privilégio `CONNECTION_ADMIN`, incluindo o usuário principal do Aurora. Usuários com esse privilégio podem ignorar o comportamento `read_only`. Para obter mais informações, consulte [Modelo de privilégios baseados em funções](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
1. Faça as alterações no ambiente de teste.
Por exemplo, você pode alterar a classe da instância de banco de dados usada por uma ou mais instâncias de banco de dados no ambiente verde.
Para ter informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
1. Teste seu ambiente de teste.
Durante o teste, recomendamos que você mantenha seus bancos de dados no ambiente verde somente leitura. Habilite operações de gravação no ambiente verde com cuidado, pois elas podem causar conflitos de replicação. Elas também podem ocasionar dados não intencionais nos bancos de dados de produção após a transição. Para habilitar as operações de gravação para o Aurora MySQL, defina o parâmetro `read_only` como `0` e reinicialize a instância de banco de dados. Para o Aurora PostgreSQL, defina o parâmetro `default_transaction_read_only` como `off` no nível da sessão.
1. Quando estiver tudo pronto, faça a transição para promover o ambiente de teste para o novo ambiente de produção. Para instruções, consulte [Mudar uma implantação azul/verde no Amazon Aurora](blue-green-deployments-switching.md).
A transição ocasiona tempo de inatividade. O tempo de inatividade geralmente é inferior a um minuto, mas pode ser maior dependendo de sua workload.
A imagem a seguir mostra os clusters de banco de dados após a transição.
![\[Cluster e instâncias de banco de dados após a transição de uma implantação azul/verde do Aurora\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png)
Após a transição, o cluster de banco de dados do Aurora no ambiente verde se torna o novo cluster de banco de dados de produção. Os nomes e os endpoints no ambiente de produção atual são atribuídos ao ambiente de produção recém-transicionado, sem exigir alterações na aplicação. Como resultado, seu tráfego de produção agora flui para o novo ambiente de produção. O cluster e as instâncias de banco de dados no ambiente azul são renomeados anexando `-oldn` ao nome atual, em que `n` é um número. Por exemplo, suponha que o nome da instância de banco de dados no ambiente azul seja `auroradb-instance-1`. Após a transição, o nome da instância de banco de dados pode ser `auroradb-instance-1-old1`.
No exemplo da imagem, as seguintes alterações ocorrem durante a alternância:
+ O cluster de banco de dados do ambiente verde `auroradb-green-abc123` torna-se o cluster de banco de dados de produção chamado `auroradb`.
+ A instância de banco de dados do ambiente verde denominada `auroradb-instance1-green-abc123` torna-se a instância de banco de dados de produção denominada `auroradb-instance1`.
+ A instância de banco de dados do ambiente verde denominada `auroradb-instance2-green-abc123` torna-se a instância de banco de dados de produção denominada `auroradb-instance2`.
+ A instância de banco de dados do ambiente verde denominada `auroradb-instance3-green-abc123` torna-se a instância de banco de dados de produção denominada `auroradb-instance3`.
+ O cluster de banco de dados do ambiente azul chamado `auroradb` torna-se `auroradb-old1`.
+ A instância de banco de dados do ambiente azul chamado `auroradb-instance1` torna-se `auroradb-instance1-old1`.
+ A instância de banco de dados do ambiente azul chamado `auroradb-instance2` torna-se `auroradb-instance2-old1`.
+ A instância de banco de dados do ambiente azul chamado `auroradb-instance3` torna-se `auroradb-instance3-old1`.
1. Caso não precise mais de uma implantação azul/verde, você pode excluí-la. Para instruções, consulte [Excluir uma implantação azul/verde no Amazon Aurora](blue-green-deployments-deleting.md).
Após a transição, o ambiente de produção anterior não é excluído para que você possa usá-lo para testes de regressão, se necessário.
# Autorizar o acesso às operações de implantação azul/verde do Amazon Aurora
Os usuários devem ter as permissões necessárias para realizar operações relacionadas às implantações azul/verde. É possível criar políticas do IAM que concedam aos usuários e perfis permissão para executar operações de API específicas nos recursos especificados de que precisam. Depois, você pode anexar essas políticas aos conjuntos de permissões do IAM ou às funções que exigem essas permissões. Para ter mais informações, consulte [Gerenciamento de identidade e acesso no Amazon Aurora](UsingWithRDS.IAM.md).
O usuário que cria uma implantação azul/verde deve ter permissões para realizar as seguintes operações do RDS:
+ `rds:CreateBlueGreenDeployment`
+ `rds:AddTagsToResource`
+ `rds:CreateDBCluster`
+ `rds:CreateDBInstance`
+ `rds:CreateDBClusterEndpoint`
O usuário que faz a transição de uma implantação azul/verde deve ter permissões para realizar as seguintes operações do RDS:
+ `rds:SwitchoverBlueGreenDeployment`
+ `rds:ModifyDBCluster`
+ `rds:PromoteReadReplicaDBCluster`
O usuário que exclui uma implantação azul/verde deve ter permissões para realizar as seguintes operações do RDS:
+ `rds:DeleteBlueGreenDeployment`
+ `rds:DeleteDBCluster`
+ `rds:DeleteDBInstance`
+ `rds:DeleteDBClusterEndpoint`
O Aurora provisiona e modifica recursos no ambiente de preparação em seu nome. Esses recursos incluem instâncias de banco de dados que usam uma convenção de nomenclatura definida internamente. Portanto, as políticas do IAM anexadas não podem conter padrões parciais de nomes de recursos, como `my-db-prefix-*`. Somente curingas (\$1) são compatíveis. Em geral, recomendamos o uso de tags de recursos e outros atributos compatíveis para controlar o acesso a esses recursos, em vez do uso de curingas. Consulte mais informações em [Actions, resources, and condition keys for Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html).
## Permissões adicionais para implantações azul/verde do Aurora Global Database
Ao criar implantações azul/verde para clusters do Aurora Global Database, além da permissão listada acima, os usuários precisam das permissões a seguir a fim de realizar operações para gerenciar a topologia global do cluster.
O usuário que cria uma implantação azul/verde deve ter permissões para realizar as seguintes operações do RDS:
+ `rds:CreateGlobalCluster`
O usuário que faz a transição de uma implantação azul/verde deve ter permissões para realizar as seguintes operações do RDS:
+ `rds:ModifyGlobalCluster`
+ `rds:PromoteReadReplicaDBCluster`
O usuário que exclui uma implantação azul/verde deve ter permissões para realizar as seguintes operações do RDS:
+ `rds:DeleteGlobalCluster`
# Limitações e considerações relativas às implantações azul/verde do Amazon Aurora
Implantações azul/verde no Amazon RDS exigem uma análise cuidadosa de fatores, como slots de replicação, gerenciamento de recursos, dimensionamento de instâncias e possíveis impactos na performance do banco de dados. As seções a seguir fornecem orientação para ajudar a otimizar a estratégia de implantação para garantir o mínimo de tempo de inatividade, transições perfeitas e gerenciamento eficaz do ambiente de banco de dados.
**Topics**
+ [Limitações para implantações azul/verde](#blue-green-deployments-limitations)
+ [Limitações do Aurora Global Database para implantações azul/verde](#blue-green-deployments-limitations-agd)
+ [Considerações sobre implantações azul/verde](#blue-green-deployments-consider)
## Limitações para implantações azul/verde
As seguintes limitações se aplicam às implantações azul/verde:
**Topics**
+ [Limitações para implantações azul/verde](#blue-green-deployments-limitations-general)
+ [Limitações do Aurora MySQL em implantações azul/verde](#blue-green-deployments-limitations-mysql)
+ [Limitações do Aurora PostgreSQL em implantações azuis/verdes](#blue-green-deployments-limitations-postgres-logical)
### Limitações para implantações azul/verde
As seguintes limitações se aplicam às implantações azul/verde:
+ Não é possível interromper e iniciar um cluster que faça parte de uma implantação azul/verde.
+ As implantações azul/verde não são compatíveis com o gerenciamento de senhas de usuário principal com AWS Secrets Manager.
+ Se você tentar forçar um retrocesso no cluster de banco de dados azul, a implantação azul/verde será interrompida e a transição será bloqueada.
+ Durante a transição, os ambientes azul e verde não podem ter integrações ETL zero com o Amazon Redshift. Você deve excluir a integração primeiro, alternar e, depois, recriar a integração.
+ O Agendador de Eventos (parâmetro `event_scheduler`) deve ser desativado no ambiente verde ao criar uma implantação azul/verde. Isso impede que eventos sejam gerados no ambiente verde e causem inconsistências.
+ As políticas de ajuste de escala automático configuradas no cluster de banco de dados azul não serão copiadas para o ambiente verde. Você deve reconfigurá-las após a transição, independentemente de terem sido inicialmente configuradas no ambiente azul ou verde.
+ Você não pode alterar um cluster de banco de dados não criptografado em um cluster de banco de dados não criptografado. Além disso, não é possível alterar um cluster de banco de dados não criptografado em um cluster de banco de dados não criptografado.
+ Não é possível alterar um cluster de banco de dados azul para uma versão de mecanismo posterior ao cluster de banco de dados verde correspondente.
+ Os recursos no ambiente azul e no ambiente verde devem estar na mesma Conta da AWS.
+ As implantações azul/verde não são compatíveis com os seguintes recursos:
+ Proxy do Amazon RDS
+ Réplicas de leitura entre regiões
+ Aurora Serverless v1Clusters de banco de dados do
+ CloudFormation
### Limitações do Aurora MySQL em implantações azul/verde
As seguintes limitações se aplicam às implantações azul/verde do Aurora MySQL:
+ O cluster de banco de dados de origem não pode conter nenhum banco de dados denominado `tmp`. Bancos de dados com esse nome não serão copiados no ambiente verde.
+ O cluster de banco de dados azul não pode ser uma réplica externa de log binário.
+ Se o cluster de banco de dados de origem tiver o retrocesso habilitado, o cluster de banco de dados verde será criado sem compatibilidade com retrocesso. Isso ocorre porque o retrocesso não funciona com a replicação de log binário (binlog), que é necessária para implantações azul/verde. Para obter mais informações, consulte [Retroceder um cluster de banco de dados Aurora](AuroraMySQL.Managing.Backtrack.md).
+ As implantações azul/verde não são compatíveis com o driver JDBC da AWS para MySQL. Consulte mais informações em [Known Limitations](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations) no GitHub.
### Limitações do Aurora PostgreSQL em implantações azuis/verdes
As seguintes limitações do se aplicam às implantações azuis/verdes do Aurora PostgreSQL .
+ As tabelas [não registradas](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) não são replicadas no ambiente verde, a menos que o parâmetro `rds.logically_replicate_unlogged_tables` esteja definido como `1` no cluster de banco de dados azul. Não modifique esse valor de parâmetro depois de criar uma implantação azul/verde para evitar possíveis erros de replicação em tabelas não registradas em log.
+ O cluster de banco de dados azul não pode ser uma origem lógica (publicador) nem uma réplica (assinante).
+ Se o cluster de banco de dados azul estiver configurado como o servidor externo de uma extensão de invólucro de dados externo (FDW), você deverá usar o nome do endpoint do cluster em vez dos endereços IP. Isso permite que a configuração permaneça funcional após a transição.
+ Em uma implantação azul/verde, cada banco de dados exige um slot de replicação lógica. À medida que o número de bancos de dados aumenta, a sobrecarga de recursos aumenta e pode gerar um atraso na replicação, principalmente se o cluster de banco de dados não estiver suficientemente escalado. O impacto depende de fatores, como a workload de bancos de dados e o número de conexões. Para atenuar isso, pense em escalar sua classe de instância de banco de dados ou reduzir o número de bancos de dados no cluster de origem.
+ As implantações azul/verde são compatíveis com o Babelfish para Aurora PostgreSQL somente na versão 15.7, ou versões 15 posteriores, e na versão 16.3, ou versões 16 posteriores.
+ Se quiser capturar planos de execução nas réplicas do Aurora, você deve fornecer o endpoint azul do cluster de banco de dados ao chamar a função. `apg_plan_mgmt.create_replica_plan_capture` Isso garante que as capturas do plano continuem funcionando após a transição. Para obter mais informações, consulte [Capturar planos de execução nas réplicas do Aurora PostgreSQL](AuroraPostgreSQL.QPM.Plancapturereplicas.md).
+ O [processo de aplicação](https://www.postgresql.org/docs/current/logical-replication-architecture.html) da replicação lógica no ambiente verde é de thread único. Se o ambiente azul gerar um alto volume de tráfego de gravação, o ambiente verde talvez não consiga acompanhar o ritmo. Isso pode causar atraso ou falha na replicação, especialmente para workloads que produzem um throughput de gravação alto e contínuo. Teste minuciosamente suas workloads. Em cenários que exigem atualizações de versão principal e processamento de workloads com alto volume de gravação, considere abordagens alternativas, como usar o [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) ou a [replicação lógica autogerenciada](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html).
+ Não é possível criar outras partições em tabelas particionadas durante implantações azul/verde do Aurora. A criação de outras partições requer operações de linguagem de definição de dados (DDL), como `CREATE TABLE`, que não são replicadas do ambiente azul para o ambiente verde. No entanto, as tabelas particionadas existentes e os respectivos dados serão replicados para o ambiente verde.
+ As limitações a seguir se aplicam às extensões do PostgreSQL:
+ A extensão `pg_partman` deve ser desabilitada no ambiente azul quando uma implantação azul/verde é criada. A extensão realiza operações de DDL como `CREATE TABLE`, que interrompem a replicação lógica do ambiente azul no ambiente verde.
+ A extensão `pg_cron` deve permanecer desativada em todos os bancos de dados verdes após a criação da implantação azul/verde. A extensão tem trabalhadores em segundo plano que são executados como superusuários e ignoram a configuração somente leitura do ambiente verde, o que pode causar conflitos de replicação.
+ A extensão `apg_plan_mgmt` deve ter o parâmetro `apg_plan_mgmt.capture_plan_baselines` definido como `off` em todos os bancos de dados verdes para evitar conflitos de chave primária se um plano idêntico for capturado no ambiente azul. Para obter mais informações, consulte [Visão geral do gerenciamento de planos de consulta do Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md).
+ As extensões `pglogical` e `pgactive` devem ser desativadas no ambiente azul ao criar uma implantação azul/verde. Depois de fazer a transição do ambiente verde para o novo ambiente de produção, será possível habilitar as extensões novamente. Além disso, o banco de dados azul não pode ser um assinante lógico de uma instância externa.
+ Se você estiver usando a extensão `pgAudit`, ela deverá permanecer nas bibliotecas compartilhadas (`shared_preload_libraries`) nos grupos de parâmetros de banco de dados personalizados para as instâncias de banco de dados azul e verde. Para obter mais informações, consulte [Configurar a extensão pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
#### Limitações específicas de replicação lógica para implantações azuis/verdes
O PostgreSQL tem certas restrições relacionadas à replicação lógica, que se traduzem em limitações ao criar implantações azul/verdes para clusters de banco de dados Aurora PostgreSQL RDS para .
Para obter mais informações sobre a replicação lógica do PostgreSQL, consulte a [documentação do PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
| Limitação | Explicação |
| --- | --- |
| Declarações de linguagem de definição de dados (DDL), como CREATE TABLE eCREATE SCHEMA, não são replicadas do ambiente azul para o ambiente verde. | **Se o Aurora detectar uma alteração de DDL no ambiente azul, seus bancos de dados verdes entrarão em um estado de replicação degradada.** Você deve excluir a implantação azul/verde e todos os bancos de dados verdes e, em seguida, recriá-la. |
| As instruções de linguagem de controle de dados (DCL), como GRANT e REVOKE, não são replicadas do ambiente azul para o ambiente verde. | Se o Aurora detectar uma tentativa de execução de uma instrução de DCL no ambiente azul, você verá uma mensagem de aviso. Não há configuração ou API disponível para alterar esse comportamento, pois é uma limitação do processo de implantação azul/verde. |
| As operações NEXTVAL em objetos de sequência não são sincronizadas entre o ambiente azul e o ambiente verde. | Durante a transição, o Aurora incrementa os valores da sequência no ambiente verde para corresponder aos do ambiente azul. Se você tiver milhares de sequências, isso pode atrasar a transição. |
| Os objetos grandes no ambiente azul não são replicadas no ambiente verde. Isso inclui objetos grandes existentes e quaisquer objetos grandes recém-criados ou modificados durante o processo de implantação azul/verde. | **Se o Aurora detectar a criação ou modificação de objetos grandes no ambiente azul que estão armazenados na tabela do `pg_largeobject` sistema, seus bancos de dados verdes entrarão em um estado de replicação degradada.** Você deve excluir a implantação azul/verde e todos os bancos de dados verdes e, em seguida, recriá-la. |
| Atualizar visões materializadas interrompe a replicação. | Atualizar visões materializadas no ambiente azul interrompe a replicação no ambiente verde. Evite atualizar visões materializadas no ambiente azul. Após uma transição, é possível atualizá-las manualmente usando o comando [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) ou programar uma atualização. |
| As operações UPDATE e DELETE não são permitidas em tabelas que não têm uma chave primária. | Antes de criar uma implantação azul/verde, verifique se todas as tabelas têm uma chave primária ou use `REPLICA IDENTITY FULL`. No entanto, use somente `REPLICA IDENTITY FULL` se não houver uma chave primária ou única, pois isso afeta a performance da replicação. Para obter mais informações, consulte a [Documentação do PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). |
## Limitações do Aurora Global Database para implantações azul/verde
Além das limitações gerais e específicas do mecanismo mencionadas acima, as seguintes limitações se aplicam às implantações azul/verde do Aurora Global Database:
+ Todas as operações devem ser iniciadas na mesma região que o cluster de gravador do banco de dados global.
+ Realizar uma transição global ou um failover global fará com que a implantação ativa azul/verde se torne inválida. A implantação azul-verde precisa ser excluída e recriada da nova região primária.
+ Para o Aurora PostgreSQL, se você tiver o encaminhamento de gravação global habilitado em seu ambiente de produção e criar uma implantação azul/verde, o encaminhamento de gravação será desabilitado no cluster verde. Ele é habilitado no ambiente verde somente após a transição azul/verde, quando o ambiente verde se torna o novo ambiente de produção. Após a transição, o encaminhamento de gravação é desabilitado no cluster `-old1`.
+ A modificação da topologia do banco de dados global após a criação da implantação azul/verde fará com que a implantação azul/verde ativa se torne inválida. Seria necessário excluir e recriar a implantação azul-verde da nova região primária.
+ Os snapshots automatizados ficam retidos de acordo com os dias de retenção de backup que foram originalmente configurados no antigo ambiente azul. Os snapshots automatizados do antigo cluster azul não são copiados no verde.
+ O failover global é aceito durante uma transição azul/verde, mas a transição global não é aceita durante uma transição azul/verde.
+ Garanta que o cluster de banco de dados e os grupos de parâmetros de banco de dados para o ambiente verde existam em todas as regiões secundárias com nomes idênticos. Se o grupo de parâmetros em qualquer região não estiver disponível, o grupo de parâmetros padrão nas regiões será usado.
+ Evite usar o RDS Proxy em qualquer membro do banco de dados global durante a transição de implantação azul/verde.
## Considerações sobre implantações azul/verde
O Amazon RDS rastreia recursos em implantações azul/verde com o `DbiResourceId` e o `DbClusterResourceId` de cada recurso. Esse ID de recurso é um identificador imutável e exclusivo da Região da AWS do recurso.
O ID do *recurso* é diferente do ID *do cluster*** de banco de dados. Cada um está listado na configuração do banco de dados no console do RDS.
O nome (ID do cluster) de um recurso muda quando você faz a transição de uma implantação azul/verde, mas cada recurso mantém o mesmo ID de recurso. Por exemplo, um identificador de cluster de banco de dados pode ser `mycluster` no ambiente azul. Após a transição, o mesmo cluster de banco de dados pode ser renomeado para `mycluster-old1`. No entanto, o ID do recurso do cluster de banco de dados não muda durante a transição. Portanto, na transição dos recursos verdes para os novos recursos de produção, os respectivos IDs de recurso não correspondem aos IDs de recurso azuis que estavam anteriormente em produção.
Depois que você realizar a transição de uma implantação azul/verde, pense em atualizar os IDs de recurso para aqueles dos recursos de produção cuja transição foi feita recentemente para recursos e serviços integrados que você utilizou com os recursos de produção. Especificamente, considere as seguintes atualizações:
+ Se você realizar a filtragem usando a API e os IDs de recursos do RDS, ajuste os IDs de recursos usados na filtragem após a transição.
+ Se você usa o CloudTrail para recursos de auditoria, ajuste os consumidores do CloudTrail para rastrear os novos IDs de recursos após a transição. Para ter mais informações, consulte [Monitorar chamadas de API do Amazon Aurorano AWS CloudTrail](logging-using-cloudtrail.md).
+ Se você usar o Database Activity Streams para recursos no ambiente azul, ajuste sua aplicação para monitorar os eventos do banco de dados para o novo fluxo após a transição. Para ter mais informações, consulte [Regiões e mecanismos de banco de dados do Aurora compatíveis com fluxos de atividades de banco de dados](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md).
+ Se você usar a API do Performance Insights, ajuste os IDs dos recursos nas chamadas para a API após a transição. Para ter mais informações, consulte [Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora](USER_PerfInsights.md).
Você pode monitorar um banco de dados com o mesmo nome após a transição, mas ele não contém os dados de antes da transição.
+ Se você usar IDs de recurso nas políticas do IAM, adicione os IDs dos recursos dos quais foi feita a transição recentemente quando necessário. Para obter mais informações, consulte [Gerenciamento de identidade e acesso no Amazon Aurora](UsingWithRDS.IAM.md).
+ Se você tiver perfis do IAM associados ao cluster de banco de dados, associe-os novamente depois da transição. Os perfis anexados não são copiados automaticamente no ambiente verde.
+ Se você se autenticar no cluster de banco de dados usando a [autenticação do banco de dados do IAM](UsingWithRDS.IAMDBAuth.md), garanta que a política do IAM usada para acesso ao banco de dados tenha os bancos de dados azul e verde listados sob o elemento `Resource` da política. Isso é necessário para se conectar ao banco de dados verde após a transição. Para obter mais informações, consulte [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md).
+ Se você quiser restaurar um snapshot de cluster de banco de dados manual ou automatizado para um cluster de banco de dados que fazia parte de uma implantação azul/verde, restaure o snapshot de cluster de banco de dados correto examinando a hora em que o snapshot foi obtido. Para ter mais informações, consulte [Restauração de um snapshot de um cluster de banco de dados](aurora-restore-snapshot.md).
+ Depois de mudar, as tarefas de replicação do AWS Database Migration Service (AWS DMS) não podem ser retomadas porque o ponto de verificação do ambiente azul é inválido no ambiente verde. Você deve recriar a tarefa do DMS com um novo ponto de verificação para continuar a replicação.
+ O Amazon Aurora cria o ambiente verde *clonando* o volume de armazenamento subjacente do Aurora no ambiente azul. O volume do cluster verde armazena somente as alterações incrementais feitas no ambiente verde. Se você excluir o cluster de banco de dados no ambiente azul, o tamanho do volume de armazenamento subjacente do Aurora no ambiente verde será aumentado para o tamanho total. Para ter mais informações, consulte [Clonar um volume para um cluster de banco de dados do Amazon Aurora](Aurora.Managing.Clone.md).
+ Quando você adiciona uma instância de banco de dados ao cluster de banco de dados no ambiente verde de uma implantação azul/verde, a nova instância de banco de dados não substituirá uma instância de banco de dados no ambiente azul quando você fizer a transição. No entanto, a nova instância de banco de dados é mantida no cluster de banco de dados e torna-se uma instância de banco de dados no novo ambiente de produção.
+ Quando você exclui uma instância de banco de dados no cluster de banco de dados no ambiente verde de uma implantação azul/verde, não é possível criar uma instância de banco de dados para substituí-la na implantação azul/verde.
Se você criar uma instância de banco de dados com o mesmo nome e ARN da instância de banco de dados excluída, ela terá um `DbiResourceId` diferente, portanto, não fará parte do ambiente verde.
Ocorrerá o comportamento a seguir se você excluir uma instância de banco de dados no cluster de banco de dados no ambiente verde:
+ Se existir uma instância de banco de dados no ambiente azul com o mesmo nome, não será feita a transição dela para a instância de banco de dados no ambiente verde. Essa instância de banco de dados não será renomeada anexando `-oldn` ao nome da instância de banco de dados.
+ Qualquer aplicação que aponte para a instância de banco de dados no ambiente azul continua usando a mesma instância de banco de dados após a transição.
+ Se você usa tags de recursos para controle de acesso ou gerenciamento operacional, precisa entender que as alterações das tags não são sincronizadas entre os ambientes azul e verde até a transição. Ao criar uma implantação azul/verde, as tags do ambiente azul são copiadas para o ambiente verde. Após a criação, nenhuma modificação de tag que você fizer em qualquer um dos ambientes será sincronizada automaticamente. Durante a transição, as tags de ambiente azul substituem todas as tags no ambiente verde. Aplique todas as tags necessárias ao ambiente azul antes de criar a implantação azul/verde ou reaplique as tags necessárias ao novo ambiente de produção após a transição. Para ter mais informações sobre tags, consulte [Marcar recursos do Amazon Aurora e do Amazon RDS](USER_Tagging.md).
# Práticas recomendadas para implantações azul/verde do Amazon Aurora
Veja as práticas recomendadas para implantações azul/verde.
**Topics**
+ [Práticas recomendadas gerais para implantações azuis/verdes](#blue-green-deployments-best-practices-general)
+ [Práticas recomendadas do Aurora MySQL para implantações azuis/verdes](#blue-green-deployments-best-practices-mysql)
+ [Práticas recomendadas do Aurora PostgreSQL para implantações azuis/verdes](#blue-green-deployments-best-practices-postgres)
+ [Práticas recomendadas do Aurora Global Database para implantações azul/verde.](#blue-green-deployments-best-practices-agd)
## Práticas recomendadas gerais para implantações azuis/verdes
Considere as seguintes práticas recomendadas gerais ao criar uma implantação azul/verde.
+ Teste minuciosamente o cluster de banco de dados do Aurora no ambiente verde antes da transição.
+ Mantenha seus bancos de dados no ambiente verde somente leitura. Recomendamos que você habilite as operações de gravação no ambiente verde com cuidado, pois elas podem causar conflitos de replicação. Elas também podem ocasionar dados não intencionais nos bancos de dados de produção após a transição.
+ Se você usar uma implantação azul/verde para implementar alterações de esquema, faça somente alterações compatíveis com a replicação.
Por exemplo, é possível adicionar novas colunas ao final de uma tabela sem interromper a replicação da implantação azul para a implantação verde. No entanto, alterações de esquema, como renomear colunas ou renomear tabelas, transformam a replicação na implantação verde.
Para ter mais informações sobre alterações compatíveis com replicação, consulte [Replicação com diferentes definições de tabela na origem e na réplica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) na documentação do MySQL e [Restrições](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) na documentação de replicação lógica do PostgreSQL.
+ Use o endpoint do cluster, o endpoint do leitor ou o endpoint personalizado para todas as conexões nos dois ambientes. Não use endpoints de instância nem endpoints personalizados com listas estáticas ou de exclusão.
+ Ao realizar a transição de uma implantação azul/verde, siga as práticas recomendadas de transição. Para obter mais informações, consulte [Práticas recomendadas de transição](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices).
## Práticas recomendadas do Aurora MySQL para implantações azuis/verdes
Considere as seguintes práticas recomendadas ao criar uma implantação azul/verde em um cluster de banco de dados do Aurora MySQL.
+ Se o ambiente verde apresentar atraso na réplica, pense no seguinte:
+ Desabilite a retenção de logs binários, se não for necessária, ou desabilite-a temporariamente até que a replicação seja atualizada. Para fazer isso, redefina o parâmetro `binlog_format` de cluster de banco de dados como `0` e reinicialize a instância verde de banco de dados do gravador.
+ Defina o parâmetro `innodb_flush_log_at_trx_commit` temporariamente como `0` no grupo de parâmetros verde do banco de dados. Depois de atualizar a replicação, faça a reversão para o valor padrão de `1` antes da transição. Se ocorrer um desligamento inesperado ou uma falha com os valores dos parâmetros temporários, compile o ambiente verde novamente para evitar que nenhuma corrupção de dados passe despercebida. Para obter mais informações, consulte [Configurar a frequência com que o buffer de log é liberado](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush).
## Práticas recomendadas do Aurora PostgreSQL para implantações azuis/verdes
Considere as seguintes práticas recomendadas ao criar uma implantação azul/verde em um cluster de banco de dados do Aurora PostgreSQL.
+ Monitore o cache de gravação de replicação lógica do Aurora PostgreSQL e realize ajustes no buffer de cache, se necessário. Para obter mais informações, consulte [Monitorar o cache de gravação simultânea de replicação lógica do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
+ Aumente o valor do parâmetro de banco de dados `logical_decoding_work_mem` no ambiente azul. Isso permite menos decodificação no disco e uso da memória. Para obter mais informações, consulte [Ajustar a memória de trabalho para decodificação lógica](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem).
+ É possível monitorar o estouro de transações que está sendo gravado em disco usando a métrica `ReplicationSlotDiskUsage` do CloudWatch. Essa métrica oferece insights sobre o uso do espaço em disco por slots de replicação, ajudando a identificar quando os dados da transação excedem a capacidade de memória e são armazenados em disco. Você pode monitorar a memória livre com a métrica do `FreeableMemory` do CloudWatch. Para obter mais informações, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+ No Aurora PostgreSQL versão 14 e posterior, é possível monitorar o tamanho dos arquivos de estouro lógico usando a visualização `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` do sistema.
+ Atualize todas as extensões do PostgreSQL para a versão mais recente antes de criar uma implantação azul/verde. Para obter mais informações, consulte [Atualizar extensões do PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md).
+ Se você estiver usando a extensão `aws_s3`, conceda ao cluster de banco de dados verde acesso ao Amazon S3 por meio de um perfil do IAM após a criação do ambiente verde. Isso permite que os comandos de importação e exportação continuem funcionando após a transição. Para instruções, consulte [Configurar o acesso a um bucket do Amazon S3](postgresql-s3-export-access-bucket.md).
+ Se você especificar uma versão posterior do mecanismo para o ambiente verde, execute a operação `ANALYZE` em todos os bancos de dados para atualizar a tabela `pg_statistic`. As estatísticas do otimizador não são transferidas durante uma atualização de versão principal, portanto, é necessário gerar novamente todas as estatísticas para evitar problemas de performance. Para conhecer práticas recomendadas adicionais durante as principais atualizações de versões, consulte [Realizar uma atualização da versão principal](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
+ Evite configurar gatilhos como `ENABLE REPLICA` ou `ENABLE ALWAYS` se o gatilho for usado na origem para manipular dados. Caso contrário, o sistema de replicação propagará as alterações e executará o gatilho, o que ocasiona duplicação.
+ Transações de longa duração podem causar um atraso significativo na réplica. Para reduzir o atraso na réplica, pense no seguinte:
+ Reduza as transações de longa duração e as subtransações que podem ser adiadas até que o ambiente verde alcance o ambiente azul.
+ Reduza as operações em massa no ambiente azul até que o ambiente verde alcance o ambiente azul.
+ Inicie uma operação manual de congelamento de vacuum em tabelas ocupadas antes de criar a implantação azul/verde. Para conferir instruções, consulte [Realização de um congelamento manual de vacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html).
+ No PostgreSQL versão 12 e posterior, desabilite o parâmetro `index_cleanup` em tabelas grandes ou muito utilizadas para melhorar a eficiência da manutenção normal em bancos de dados azuis. Para ter mais informações, consulte [Aspirar uma tabela o mais rápido possível](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
**nota**
Ignorar regularmente a limpeza do índice durante a aspiração pode causar inchaço no índice, o que pode prejudicar o desempenho da limpeza. Como prática recomendada, utilize essa abordagem somente ao usar uma implantação azul/verde. Depois que a implantação estiver concluída, recomendamos retomar a manutenção e a limpeza regulares do índice.
+ Poderá ocorrer atraso na réplica se as instâncias de banco de dados azul e verde estiverem subdimensionadas para a workload. Garanta que as instâncias de banco de dados não estejam atingindo os limites de recurso para o tipo de instância. Para obter mais informações, consulte [Usar métricas do Amazon CloudWatch para analisar o uso de recursos do Aurora PostgreSQL](AuroraPostgreSQL_AnayzeResourceUsage.md).
+ A replicação lenta pode fazer com que remetentes e destinatários sejam reiniciados com frequência, o que atrasa a sincronização. Para garantir que eles permaneçam ativos, desabilite os tempos limite definindo o parâmetro `wal_sender_timeout` como `0` no ambiente azul e o parâmetro `wal_receiver_timeout` como `0` no ambiente verde.
+ Analise o desempenho das instruções UPDATE e DELETE e avalie se a criação de um índice na coluna utilizada na cláusula WHERE pode otimizar essas consultas. Isso pode melhorar o desempenho quando as operações são repetidas no ambiente verde. Para obter mais informações, consulte [Verificar filtros de predicados em busca de consultas que geram esperas](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters).
+ Se você estiver usando gatilhos, garanta que eles não interfiram na criação, atualização e eliminação de objetos `pg_catalog.pg_publication`, `pg_catalog.pg_subscription` e `pg_catalog.pg_replication_slots` cujos nomes comecem com “rds”.
+ Se o Babelfish estiver ativado no cluster de banco de dados de origem, os seguintes parâmetros deverão ter as mesmas configurações no grupo de parâmetros do cluster de banco de dados de destino para o ambiente verde e no grupo de parâmetros do cluster de banco de dados de origem:
+ rds.babelfish\$1status
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1precision
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1scale
+ babelfishpg\$1tsql.default\$1locale
+ babelfishpg\$1tsql.migration\$1mode
+ babelfishpg\$1tsql.server\$1collation\$1name
Para mais informações sobre esses parâmetros, consulte [Configurações de grupo de parâmetros de cluster de banco de dados para o Babelfish](babelfish-configuration.md).
## Práticas recomendadas do Aurora Global Database para implantações azul/verde.
Além das práticas recomendadas gerais e específicas do mecanismo listadas acima, pense nas práticas recomendadas a seguir para o Aurora Global Database..
+ Monitore as seguintes métricas do CloudWatch para identificar períodos de baixa atividade em seu ambiente de produção:
+ `DatabaseConnections`
+ `ActiveTransactions`
Programe a transição entre azul e verde durante a janela de manutenção planejada ou durante um período de baixa atividade.
+ A duração da transição entre azul e verde varia de acordo com sua workload e o número de regiões secundárias. Quando você inicia uma transição entre azul e verde, o serviço espera que o atraso da réplica chegue a zero antes de continuar. Recomendamos conferir o atraso da réplica antes de iniciar a transição.
+ Se você pretende usar um parâmetro de banco de dados ou um grupo de parâmetros de cluster de banco de dados diferente do padrão para seu ambiente verde, crie o grupo de parâmetros desejado com o mesmo nome em todas as regiões secundárias antes de iniciar a implantação azul/verde.
# Criar uma implantação azul/verde no Amazon Aurora
O RDS copia a topologia e os recursos do ambiente azul para uma área de preparação. Se uma instância de banco de dados azul tiver réplicas de leitura, elas serão copiadas como réplicas da instância verde. O armazenamento alocado de todas as réplicas verdes corresponde à instância primária verde, enquanto outros parâmetros de armazenamento são herdados das réplicas azuis.
Ao criar uma implantação azul/verde, você especifica o cluster de banco de dados a ser copiado na implantação. O cluster de banco de dados selecionado é o cluster de banco de dados de produção e torna-se o cluster de banco de dados no ambiente azul. O RDS copia a topologia do ambiente azul para uma área de teste, junto com seus recursos configurados. O cluster de banco de dados é copiado no ambiente verde, e o RDS configura a replicação do cluster de banco de dados no ambiente azul para o cluster de banco de dados no ambiente verde. O RDS também copia todas as instâncias de banco de dados no cluster de banco de dados.
**Topics**
+ [Preparação para uma implantação azul/verde](#blue-green-deployments-creating-preparing)
+ [Especificar as alterações ao criar uma implantação azul/verde](#blue-green-deployments-creating-changes)
+ [Criar uma implantação azul/verde](#blue-green-deployments-creating-create)
+ [Configurações para criar implantações azuis/verdes](#create-blue-green-settings)
## Preparação para uma implantação azul/verde
Há algumas etapas que você deve seguir antes de criar uma implantação azul/verde, dependendo do mecanismo que o cluster de banco de dados do Aurora está executando.
**Topics**
+ [Preparar um cluster de banco de dados do Aurora MySQL para uma implantação azul/verde](#blue-green-deployments-creating-preparing-mysql)
+ [Preparar um cluster de banco de dados do Aurora PostgreSQL para uma implantação azul/verde](#blue-green-deployments-creating-preparing-postgres)
+ [Preparar um cluster de banco de dados do Aurora Global Databases para uma implantação azul/verde](#blue-green-deployments-creating-preparing-agd)
### Preparar um cluster de banco de dados do Aurora MySQL para uma implantação azul/verde
Antes de criar uma implantação azul/verde para um cluster de banco de dados do Aurora MySQL, o cluster de banco de dados deve estar associado a um grupo de parâmetros de cluster de banco de dados personalizado com o [registro em log binário](USER_LogAccess.MySQL.BinaryFormat.md) (`binlog_format`) ativado. O registro em log binário é necessário para a replicação do ambiente azul para o ambiente verde. Embora qualquer formato de log binário funcione, recomendamos `ROW` para reduzir o risco de inconsistências de replicação. Para obter informações sobre como criar um grupo de parâmetros de cluster de banco de dados personalizado e definir parâmetros, consulte [Grupos de parâmetros do cluster de banco de dados para clusters de banco de dados do Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md).
**nota**
Habilitar o registro em log binário aumenta o número de operações de E/S de disco de gravação no cluster de banco de dados. Você pode monitorar o uso de IOPS com a métrica `VolumeWriteIOPs` do CloudWatch.
Depois de habilitar o registro em log binário, reinicialize o cluster de banco de dados para que as alterações tenham efeito. As implantações azul/verde *exigem* que a instância do gravador esteja sincronizada com o grupo de parâmetros do cluster de banco de dados, caso contrário a criação falhará. Para obter mais informações, consulte [Reinicializar uma instância de banco de dados em um cluster do Aurora](aurora-reboot-db-instance.md).
Além disso, recomendamos alterar o período de retenção de logs binários para um valor diferente de `NULL` a fim de evitar que os arquivos de log binários sejam eliminados. Para obter mais informações, consulte [Definir e mostrar a configuração de logs binários](mysql-stored-proc-configuring.md).
### Preparar um cluster de banco de dados do Aurora PostgreSQL para uma implantação azul/verde
Antes de criar uma implantação azul/verde para um cluster de banco de dados do Aurora PostgreSQL, faça o seguinte.
+ Associe o cluster a um grupo de parâmetros de cluster de banco de dados personalizado com a replicação lógica (`rds.logical_replication`) ativada. A replicação lógica é necessária para a replicação do ambiente azul no ambiente verde.
Ao habilitar a replicação lógica, é necessário também ajustar determinados parâmetros do cluster, como `max_replication_slots`, `max_logical_replication_workers` e `max_worker_processes`. Para ter instruções sobre como habilitar a replicação lógica e ajustar esses parâmetros, consulte [Configurar a replicação lógica para seu cluster de banco de dados do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical.Configure.md).
Além disso, verifique se o parâmetro `synchronous_commit` está definido como `on`.
Depois de configurar os parâmetros necessários, reinicialize o cluster de banco de dados para que as alterações tenham efeito. As implantações azul/verde *exigem* que a instância do gravador esteja sincronizada com o grupo de parâmetros do cluster de banco de dados, caso contrário a criação falhará. Para obter mais informações, consulte [Reinicializar uma instância de banco de dados em um cluster do Aurora](aurora-reboot-db-instance.md).
+ Confirme se o cluster de banco de dados está executando uma versão do Aurora PostgreSQL compatível com implantações azuis/verdes. Para conferir uma lista de versões compatíveis, consulte [Implantações azul/verde com o Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.apg).
+ Certifique-se de que todas as tabelas no cluster de banco de dados tenham uma chave primária. A replicação lógica do PostgreSQL não permite operações UPDATE ou DELETE em tabelas que não têm uma chave primária.
### Preparar um cluster de banco de dados do Aurora Global Databases para uma implantação azul/verde
Antes de criar uma implantação azul/verde para seu cluster de banco de dados do Aurora Global Database, observe os seguintes pontos:
+ Todas as operações devem ser iniciadas na mesma região que o cluster de gravador do banco de dados global.
+ Configuração do grupo de parâmetros:
+ O ambiente verde usa um novo grupo de parâmetros que você especifica ou o mesmo grupo de parâmetros que do cluster azul (padrão).
+ Os grupos de parâmetros personalizados são copiados no ambiente verde.
+ Se um grupo de parâmetros especificado não existir na região secundária, o grupo de parâmetros padrão na região secundária será usado para o ambiente verde.
## Especificar as alterações ao criar uma implantação azul/verde
Você pode fazer as seguintes alterações no cluster de banco de dados no ambiente verde ao criar a implantação azul/verde:
Você pode fazer outras modificações de banco de dados no cluster e em suas instâncias de banco de dados no ambiente verde após sua implantação. Por exemplo, você pode especificar uma versão posterior do mecanismo ou um grupo de parâmetros diferente.
Para ter informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
**Topics**
+ [Especifique uma versão de mecanismo superior](#blue-green-deployments-engine-version)
+ [Especificar outro grupo de parâmetros de banco de dados](#blue-green-deployments-parameters)
### Especifique uma versão de mecanismo superior
Você poderá especificar uma versão superior do mecanismo se quiser testar uma atualização do mecanismo de banco de dados. Após a transição, o banco de dados é atualizado para a versão principal ou secundária do mecanismo de banco de dados que você especificar.
### Especificar outro grupo de parâmetros de banco de dados
Você pode especificar um grupo de parâmetros de cluster de banco de dados diferente do usado pelo cluster de banco de dados. É possível testar como as alterações de parâmetros afetam o cluster de banco de dados no ambiente verde ou especificar um grupo de parâmetros para uma nova versão principal do mecanismo de banco de dados no caso de uma atualização.
Se você especificar um grupo de parâmetros de cluster de banco de dados diferente, o grupo de parâmetros especificado será associado ao cluster de banco de dados no ambiente verde. Se você não especificar um grupo de parâmetros de cluster de banco de dados diferente, o cluster de banco de dados no ambiente verde será associado ao mesmo grupo de parâmetros que o cluster de banco de dados azul.
## Criar uma implantação azul/verde
Você pode criar a implantação azul/verde usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
### Console
**Como criar uma implantação azul/verde**
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, selecione **Databases** (Bancos de dados) e, depois, o cluster de banco de dados que você deseja copiar em um ambiente verde.
1. Selecione **Ações**, **Criar implantação azul/verde**.
A página **Criar implantação azul/verde** é exibida.
![\[Criar uma implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-create-aurora.png)
1. Analise os identificadores azuis do banco de dados. Eles devem corresponder às instâncias de banco de dados que você espera no ambiente azul. Caso contrário, selecione **Cancel** (Cancelar).
1. Em **Nome da implantação azul/verde**, insira um nome para sua implantação azul/verde.
1. Nas seções restantes, especifique as configurações do ambiente verde. Para obter informações sobre cada configuração, consulte [Configurações para criar implantações azuis/verdes](#create-blue-green-settings).
Você pode fazer outras modificações nos bancos de dados no ambiente verde após sua implantação.
1. Escolha **Criar**.
### AWS CLI
Para criar uma implantação azul/verde usando a AWS CLI, utilize o comando [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html). Para obter informações sobre todas as opções disponíveis, consulte [Configurações para criar implantações azuis/verdes](#create-blue-green-settings).
**Example**
Para Linux, macOS ou Unix:
```
aws rds create-blue-green-deployment \
--blue-green-deployment-name aurora-blue-green-deployment \
--source arn:aws:rds:us-east-2:123456789012:cluster:auroradb \
--target-engine-version 8.0 \
--target-db-cluster-parameter-group-name mydbclusterparametergroup
```
Para Windows:
```
aws rds create-blue-green-deployment ^
--blue-green-deployment-name aurora-blue-green-deployment ^
--source arn:aws:rds:us-east-2:123456789012:cluster:auroradb ^
--target-engine-version 8.0 ^
--target-db-cluster-parameter-group-name mydbclusterparametergroup
```
### API do RDS
Para criar uma implantação azul/verde usando a API do Amazon RDS, use a operação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html). Para ter mais informações sobre cada opção, consulte [Configurações para criar implantações azuis/verdes](#create-blue-green-settings).
## Configurações para criar implantações azuis/verdes
A tabela a seguir explica as configurações que você pode escolher ao criar uma implantação azul/verde. Consulte mais informações sobre as opções da AWS CLI em [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html). Consulte mais informações sobre os parâmetros da API do RDS em [CreateBlueGreenDeployment](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html).
| Configuração do console | Descrição da configuração | Opção da CLI e parâmetro da API do RDS |
| --- | --- | --- |
| **Identificador de implantação azul/verde** | Um nome para a implantação azul/verde. | **Opção da CLI:** `--blue-green-deployment-name` **Parâmetro da API:** `BlueGreenDeploymentName` |
| Identificador de banco de dados azul | O identificador do cluster que você deseja copiar no ambiente verde. Ao usar a CLI ou a API, especifique o nome do recurso da Amazon (ARN) do cluster. | **Opção da CLI:** `--source` **Parâmetro da API:** `Source` |
| Grupo de parâmetros do cluster de banco de dados para bancos de dados verdes | Um grupo de parâmetros para associar aos bancos de dados no ambiente verde. | **Opção da CLI:** `--target-db-cluster-parameter-group-name` **Parâmetro da API:** `TargetDBClusterParameterGroupName` |
| **Versão do mecanismo para bancos de dados verdes** | Faça upgrade do cluster no ambiente verde para a versão especificada do mecanismo de banco de dados. Se você escolher um cluster de banco de dados Aurora PostgreSQL, analise e reconheça as limitações da replicação lógica. Para obter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres). | **Opção da CLI:** `--target-engine-version` **Parâmetro da API do RDS:** `TargetEngineVersion` |
# Visualizar uma implantação azul/verde no Amazon Aurora
Você pode visualizar os detalhes de uma implantação azul/verde usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
Você também pode visualizar e assinar eventos para obter informações sobre uma implantação azul/verde. Para ter mais informações, consulte [Eventos de implantação azul/verde](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments).
## Console
**Como visualizar os detalhes sobre uma implantação azul/verde**
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, selecione **Databases** (Bancos de dados) e, depois, localize a implantação azul/verde na lista.
![\[Implantação azul/verde na lista de bancos de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-db-list-aurora.png)
O valor de **Role** (Função) para a implantação azul/verde é **Blue/Green Deployment** (Implantação azul/verde).
1. Selecione o nome da implantação azul/verde que você deseja visualizar para exibir seus detalhes.
Cada guia tem uma seção para a implantação azul e uma seção para a implantação verde. Por exemplo, na guia **Configuração**, a versão do mecanismo de banco de dados pode ser diferente no ambiente azul e no ambiente verde se você estiver atualizando a versão do mecanismo de banco de dados no ambiente verde.
A imagem a seguir mostra um exemplo da guia **Conectividade e segurança**.
![\[Detalhes das implantações azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-details-aurora.png)
A guia **Conectividade e segurança** também inclui uma seção chamada **Replicação**, que mostra o estado atual da replicação e o atraso da réplica entre os ambientes azul e verde. Se o estado de replicação for `Replicating`, a implantação azul/verde está sendo replicada com êxito.
Para implantações azuis/verdes do Aurora PostgreSQL que usam replicação lógica, o estado da replicação pode mudar para `Replication degraded` se você fizer alterações de DDL incompatíveis ou de objetos grandes no ambiente azul. Para ter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
A imagem a seguir mostra um exemplo da guia **Configuração**.
![\[Detalhes da configuração da implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-config-aurora.png)
A seguinte imagem mostra um exemplo da guia **Status**:
![\[Status das implantações azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-status-aurora.png)
## AWS CLI
Para ver os detalhes sobre uma implantação azul/verde usando a AWS CLI, use o comando [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html).
**Example Veja os detalhes sobre uma implantação azul/verde filtrando por seu nome**
Ao usar o comando [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html), você pode filtrar no `--blue-green-deployment-name`.
O exemplo a seguir mostra os detalhes de uma implantação azul/verde chamada `my-blue-green-deployment`.
```
aws rds describe-blue-green-deployments \
--filters Name=blue-green-deployment-name,Values=my-blue-green-deployment
```
**Example Visualizar os detalhes sobre uma implantação azul/verde especificando seu identificador**
Ao usar o comando [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html), é possível especificar a opção `--blue-green-deployment-identifier`.
O exemplo a seguir mostra os detalhes de uma implantação azul/verde com o identificador `bgd-1234567890abcdef`.
```
aws rds describe-blue-green-deployments \
--blue-green-deployment-identifier bgd-1234567890abcdef
```
## API do RDS
Para ver os detalhes sobre uma implantação azul/verde usando a API do Amazon RDS, use a operação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html) e especifique o `BlueGreenDeploymentIdentifier`.
# Mudar uma implantação azul/verde no Amazon Aurora
Uma *transição* transforma o cluster de banco de dados, inclusive as instâncias de banco de dados, do ambiente verde no 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.
*Mudar para* uma implantação azul/verde não é o mesmo que *promover* o cluster de banco de dados verde na implantação azul/verde. Se você promover manualmente o cluster de banco de dados escolhendo **Promover** no menu **Ações**, a replicação entre os ambientes azul e verde será interrompida e a implantação azul/verde entrará no estado de **Configuração inválida**.
**Topics**
+ [Tempo limite de transição](#blue-green-deployments-switching-timeout)
+ [Barreiras de proteção de transição](#blue-green-deployments-switching-guardrails)
+ [Ações de transição](#blue-green-deployments-switching-actions)
+ [Práticas recomendadas de transição](#blue-green-deployments-switching-best-practices)
+ [Verificar as métricas do CloudWatch antes da transição](#blue-green-deployments-switching-over-cloudwatch)
+ [Monitorar o atraso da réplica antes da transição](#blue-green-deployments-monitor-replica-lag)
+ [Realizar a transição de uma implantação azul/verde](#blue-green-deployments-switching-over)
+ [Após a transição](#blue-green-deployments-switching-after)
## 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 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 [Monitorar o atraso da réplica antes da transição](#blue-green-deployments-monitor-replica-lag).
+ **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 implantações azuis/verdes 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 obter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
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:
1. Executa verificações de barreira de proteção para verificar se os ambientes azul e verde estão prontos para a transição.
1. Interrompe novas operações de gravação na no cluster de banco de dados nos dois ambientes.
1. Descarta conexões com as instâncias de banco de dados em ambos os ambientes e não permite novas conexões.
1. Espera que a replicação alcance o ambiente verde para que este esteja em sincronia com o ambiente azul.
1. Renomeia de banco de dados o cluster e instâncias de banco de dados nos dois ambientes.
O RDS renomeia o cluster e as instâncias de banco de dados no ambiente verde para coincidir com o cluster e as 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.
1. Permite conexões com bancos de dados nos dois ambientes.
1. 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 de produção anterior só permite operações de leitura. Mesmo se você ativar gravações 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 obter mais informações, consulte [Eventos de implantação azul/verde](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments).
Durante a transição, as tags do ambiente azul substituem todas as tags dos recursos no ambiente verde. Todas as tags adicionadas diretamente aos recursos do ambiente verde são substituídas durante esse processo. Para ter mais informações sobre tags, consulte [Marcar recursos do Amazon Aurora e do Amazon RDS](USER_Tagging.md).
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 obter mais informações, consulte [Verificar as métricas do CloudWatch antes da transição](#blue-green-deployments-switching-over-cloudwatch).
+ 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 . Do contrário, as aplicações continuarão a enviar tráfego de gravação ao ambiente azul após
a transição.
+ Para implantações azuis/verdes 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 obter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
+ Execute a operação `ANALYZE` para atualizar a tabela `pg_statistics`. Isso reduz o risco de problemas de desempenho após a transição.
+ Antes de iniciar uma transição de implantação azul/verde, verifique se a aplicação não substitui o parâmetro `default_transaction_read_only` em nível de sessão. Durante a transição, esse parâmetro é definido como `on` no gravador do ambiente verde para evitar gravações enquanto a promoção não for concluída. Se a aplicação ou as transações substituírem essa configuração por `off`, a aplicação poderá gravar dados no ambiente verde durante o processo de transição. Caso seja necessário reverter a transição, essas gravações não estarão disponíveis no ambiente azul, o que exige que as inconsistências nos dados sejam resolvidas manualmente. Antes de prosseguir com a transição, é altamente recomendável auditar as consultas à aplicação para garantir que elas respeitem a configuração `default_transaction_read_only`.
**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 obter mais informações, consulte [Métricas do Amazon CloudWatch para o Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md).
## 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 é próximo de zero para reduzir o tempo de inatividade.
### Aurora MySQL
Para implantações azul/verde do MySQL, confira a métrica `AuroraBinlogReplicaLag` do CloudWatch no ambiente verde para identificar o atraso atual da réplica. Para obter mais informações, consulte [Diagnosticar e resolver atrasos entre réplicas de leitura](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).
### Aurora PostgreSQL
Para implantações azuis/verdes do PostgreSQL, verifique a métrica `OldestReplicationSlotLag` do CloudWatch no ambiente azul para identificar o atraso atual da réplica. Para obter mais informações, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
Além disso, você pode executar a consulta SQL a seguir no ambiente azul:
```
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 Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
### Console
**Como realizar a transição de uma implantação azul/verde**
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, selecione **Databases** (Bancos de dados) e, depois, selecione a implantação azul/verde da qual você deseja realizar a transição.
1. Para **Actions** (Ações), selecione **Switch over** (Realizar transição).
A página **Switch over** (Realizar transição) é exibida.
![\[Fazer a transição de uma implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switch-over-aurora.png)
1. 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).
1. Em **Timeout** (Tempo limite), insira o limite de tempo para a transição.
1. Se seu cluster estiver executando o Aurora PostgreSQL, a instância , analise e confirme as recomendações de pré-transição. Para obter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
1. Selecione **Switch Role** (Realizar transição).
### AWS CLI
Para realizar a transição de uma implantação azul/verde usando a AWS CLI, utilize o comando [switchover-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html) 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.
**Example 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
```
### API do RDS
Para realizar a transição de uma implantação azul/verde usando a API do Amazon RDS, use a operação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html) 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 azul é forçado a entrar em um estado somente leitura. Mesmo se você habilitar as operações de gravação, ele permanecerá somente leitura até que você exclua a implantação azul/verde. O RDS nomeia o cluster e as instâncias de banco de dados no ambiente verde `-newn`.
Se você excluir o recurso de implantação azul/verde, o RDS reterá os recursos `-oldn` e `-newn`.
![\[Depois de realizar a transição de uma implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-after-switchover-aurora.png)
### Atualizar o nó principal para consumidores
O RDS oferece réplicas de leitura totalmente gerenciadas. No entanto, ele também oferece a opção de configurar réplicas autogerenciadas, também conhecidas como *réplicas externas*. As réplicas externas possibilitam o uso de recursos de terceiros como destinos de replicação.
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 a fim de manter a continuidade da replicação.
**Como atualizar o nó pai**
1. 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. Para localizar o evento, acesse o console do RDS e escolha **Eventos** no painel de navegação esquerdo.
1. Filtre por eventos em que a origem é o nome da antiga instância de banco de dados verde do gravador, antes da transição.
1. Localize o evento que contém as coordenadas de logs binários. A mensagem do evento é semelhante a: `Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574`.
1. Garanta que o consumidor ou a réplica tenha aplicado todos os logs binários do antigo ambiente azul. Depois, use as coordenadas de logs binários fornecidas para retomar a replicação nos consumidores. Por exemplo, se você estiver executando uma réplica do MySQL no EC2, poderá usar o seguinte comando:
**MySQL 8.0.22 e versões principais e secundárias anteriores**
```
CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=40134574;
```
**MySQL 8.0.23 e versões principais e secundárias posteriores**
```
CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
```
# Excluir uma implantação azul/verde no Amazon Aurora
Você pode excluir uma implantação azul/verde antes ou depois de realizar a transição.
Quando você exclui uma implantação azul/verde antes de realizar a transição, o Amazon RDS exclui opcionalmente o cluster de banco de dados no ambiente verde:
+ Se você optar por excluir o cluster de banco de dados no ambiente verde (`--delete-target`), ele deverá ter proteção contra exclusão desativada.
+ Se você não excluir o cluster de banco de dados no ambiente verde (`--no-delete-target`), ele será retido, mas ele não fará mais parte de uma implantação azul/verde. Para o Aurora MySQL, a replicação continua entre os ambientes. Para o Aurora PostgreSQL, o ambiente verde é promovido a um ambiente autônomo, então a replicação é interrompida.
A opção de excluir bancos de dados verdes não estará disponível no console depois da [transição](blue-green-deployments-switching.md). Ao excluir uma implantação azul/verde usando a AWS CLI, você não poderá especificar a opção `--delete-target` se o [status](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BlueGreenDeployment.html) da implantação for `SWITCHOVER_COMPLETED`.
**Importante**
Após a exclusão de uma implantação azul/verde, o RDS remove as proteções somente leitura do cluster de banco de dados de produção anterior. Se o parâmetro `read_only` estiver desabilitado para o cluster de banco de dados, ele começará a permitir operações de gravação novamente.
Você pode excluir a implantação azul/verde usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.
## Console
**Como excluir uma implantação azul/verde**
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, selecione **Databases** (Bancos de dados) e, depois, selecione a implantação azul/verde que você deseja excluir.
1. Em **Ações**, escolha **Excluir**.
A janela **Excluir implantação azul/verde?** é exibida.
![\[Excluir uma implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-delete-aurora.png)
Para excluir os bancos de dados verdes, selecione **Excluir os bancos de dados verdes nesta implantação azul/verde**.
1. Digite **delete me** na caixa.
1. Escolha **Delete (Excluir)**.
## AWS CLI
Para excluir uma implantação azul/verde usando a AWS CLI, use o comando [delete-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-blue-green-deployment.html) com as seguintes opções:
+ `--blue-green-deployment-identifier`: o ID do recurso da implantação azul/verde a ser excluída.
+ `--delete-target`: especifica que o cluster de banco de dados no ambiente verde seja excluído. Você não poderá especificar essa opção se a implantação azul/verde tiver um status de `SWITCHOVER_COMPLETED`.
+ `--no-delete-target`: especifica que o cluster de banco de dados no ambiente verde seja retido.
**Example : excluir uma implantação azul/verde e o cluster de banco de dados no ambiente verde**
Para Linux, macOS ou Unix:
```
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier bgd-1234567890abcdef \
--delete-target
```
Para Windows:
```
aws rds delete-blue-green-deployment ^
--blue-green-deployment-identifier bgd-1234567890abcdef ^
--delete-target
```
**Example : excluir uma implantação azul/verde, mas manter o cluster de banco de dados no ambiente verde**
Para Linux, macOS ou Unix:
```
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier bgd-1234567890abcdef \
--no-delete-target
```
Para Windows:
```
aws rds delete-blue-green-deployment ^
--blue-green-deployment-identifier bgd-1234567890abcdef ^
--no-delete-target
```
## API do RDS
Para excluir uma implantação azul/verde usando a API do Amazon RDS, use a operação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html) com os seguintes parâmetros:
+ `BlueGreenDeploymentIdentifier`: o ID do recurso da implantação azul/verde a ser excluída.
+ `DeleteTarget`: especifique `TRUE` se deseja excluir o cluster de banco de dados no ambiente verde ou `FALSE` para mantê-lo. Não poderá ser `TRUE` se a implantação azul/verde tiver um status de `SWITCHOVER_COMPLETED`.