# 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.