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