Considerações e limitações relativas às implantações azul/verde - Amazon Aurora
LimitaçõesConsiderações

Considerações e limitações relativas às implantações azul/verde

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.

Limitações para implantações azul/verde

As seguintes limitações se aplicam às implantações azul/verde:

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.

  • Todas as políticas de ajuste de escala automático do Aurora que estejam definidas no cluster de banco de dados azul não serão copiadas para o ambiente 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:

    • Amazon RDS Proxy

    • Réplicas de leitura entre regiões

    • Clusters de banco de dados do Aurora Serverless v1

    • Clusters de banco de dados que fazem parte de um banco de dados global do Aurora.

    • AWS CloudFormation

Limitações do Aurora MySQL em implantações azul/verde

As seguintes limitações se aplicam às implantações azul/verde do MySQL:

  • As versões 2.08 e 2.09 do Aurora MySQL não são compatíveis como versões de destino ou de origem de atualização.

  • 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 ter mais informações, consulte Retroceder um cluster de banco de dados Aurora.

  • 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 no GitHub.

Limitações do Aurora PostgreSQL em implantações azul/verde

As seguintes limitações se aplicam às implantações azul/verde do PostgreSQL:

  • As seguintes versões do Aurora PostgreSQL são aceitas como origem e destino da atualização: 11.21 e posterior, 12.16 e posterior, 13.12 e posterior, 14.9 e posterior, 15.4 e posterior e 16.1 e posterior. Para versões inferiores, você pode realizar uma atualização de versão secundária para uma versão compatível.

  • As tabelas não registradas 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. Recomendamos que você 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.

  • O cluster de banco de dados azul não pode ser uma origem lógica autogerenciada (publicador) nem uma réplica (assinante).

  • Se o cluster de banco de de banco de dados 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 da 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 a instância de banco de dados não estiver suficientemente escalada. 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.

  • A extensão pg_partman deve ser desativada no ambiente azul ao criar uma implantação azul/verde. 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 ter mais informações, consulte Visão geral do gerenciamento de planos de consulta do Aurora PostgreSQL.

    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 ter mais informações, consulte Capturar planos de execução nas réplicas do Aurora PostgreSQL.

  • As extensões pglogical e pgactive devem ser desativadas no ambiente azul ao criar uma implantação azul/verde. Depois de promover o ambiente verde para o novo ambiente de produção, você poderá 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 ter mais informações, consulte Configurar a extensão pgAudit.

Limitações de replicação lógica do PostgreSQL em implantações azul/verde

As implantações azul/verde usam a replicação lógica para manter o ambiente de teste sincronizado com o ambiente de produção. 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 .

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ê recebe um evento notificando que as alterações de DDL no ambiente azul não podem ser replicadas no ambiente verde. Você deve excluir a implantação azul/verde e todos os bancos de dados verdes e, em seguida, recriá-la. Caso contrário, não será possível alternar a 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.
A criação ou modificação de objetos grandes no ambiente azul não são replicadas no ambiente 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.

Aurora gera um evento notificando você de que alterações de objetos grandes no ambiente azul não podem ser replicadas no ambiente verde. Você deve excluir a implantação azul/verde e todos os bancos de dados verdes e, em seguida, recriá-la. Caso contrário, não será possível alternar a implantação azul/verde.

As visualizações materializadas não são atualizadas automaticamente no ambiente verde.

Atualizar visualizações materializadas no ambiente azul não as atualiza no ambiente verde. Após a transição, é possível atualizá-los manualmente usando o comando REFRESH MATERIALIZED VIEW ou agendar 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, certifique-se de que todas as tabelas na tenham uma chave primária.

Para obter mais informações sobre a replicação lógica do PostgreSQL, consulte a documentação do PostgreSQL.

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, quando os recursos verdes são promovidos como novos recursos de produção, seus IDs de recursos não correspondem aos IDs de recursos azuis que estavam anteriormente em produção.

Depois de realizar a transição de uma implantação azul/verde, pense em atualizar os IDs dos recursos de produção recém-promovidos para recursos e serviços integrados que você usou 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.

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

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

    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 recursos nas políticas do IAM, adicione os IDs dos recursos recém-promovidos quando necessário. Para ter mais informações, consulte Gerenciamento de identidade e acesso no Amazon Aurora.

  • 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, 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 ter mais informações, consulte Criar e usar uma política do IAM para acesso do banco de dados do IAM.

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

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

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