Considerações e limitações relativas às implantações azul/verde - Amazon Relational Database Service
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:

  • 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 o volume de log dedicado (DLV) estiver habilitado no banco de dados azul, ele deverá estar habilitado em todas as instâncias de banco de dados, incluindo réplicas de leitura.

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

  • Você não pode alterar uma instância de banco de dados não criptografada em uma instância de banco de dados não criptografada. Além disso, não é possível alterar uma instância de banco de dados não criptografada em uma instância de banco de dados não criptografada.

  • Não é possível alterar uma instância de banco de dados azul para uma versão de mecanismo posterior à instância 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

    • Propagar réplicas de leitura

    • Réplicas de leitura entre regiões

    • AWS CloudFormation

    • Implantações de clusters de banco de dados multi-AZ

      O recurso de implantação azul/verde é compatível com implantações de instâncias de banco de dados multi-AZ. Para ter mais informações sobre implantações Multi-AZ, consulte Configurar e gerenciar uma implantação multi-AZ para o Amazon RDS.

Limitações do RDS para MySQL em implantações azul/verde

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

  • As versões 8.0.11 a 8.0.13 do MySQL têm um bug da comunidade que impede que ele seja compatível com as implantações azul/verde.

  • A instância de banco de dados azul não pode ser uma réplica externa de log binário.

  • Se o banco de dados de origem estiver associado a um grupo de opções personalizado, você não poderá especificar uma atualização de versão principal ao criar a implantação azul/verde.

    Nesse caso, você pode criar uma implantação azul/verde sem especificar uma atualização de versão principal. Depois, você pode atualizar o banco de dados no ambiente verde. Para ter mais informações, consulte Atualizar a versão de mecanismo de uma instância de banco de dados.

  • 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 RDS para PostgreSQL em implantações azul/verde

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

  • As seguintes versões do RDS para 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 tabelas não registradas.

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

  • Se o 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 da instância 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 na instância 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.

  • 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 para instâncias de banco de dados PostgreSQL.

A tabela a seguir descreve as limitações de replicação lógica que se aplicam às implantações azul/verde do .

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 Amazon RDS 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 Amazon RDS 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 Amazon RDS 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.

O RDS 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 instância de banco de de banco de dados 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 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 da instância de banco de dados. Cada um está listado na configuração do banco de dados no console do RDS.

O nome (ID da instância) 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 instância de banco de dados pode ser mydb no ambiente azul. Após a transição, a mesma instância de banco de dados pode ser renomeada para mydb-old1. No entanto, o ID do recurso da instância 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 RDSno AWS CloudTrail.

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

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

  • Se você tiver perfis do IAM associados à instância 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 na instância 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ê usa AWS Backup para gerenciar backups automatizados de recursos em uma implantação azul/verde, ajuste os IDs de recursos usados por AWS Backup após a transição. Para ter mais informações, consulte Usar o AWS Backup no gerenciamento de backups automatizados para o Amazon RDS.

  • Se você quiser restaurar um snapshot de banco de dados manual ou automatizado para uma instância de banco de dados que fazia parte de uma implantação azul/verde, restaure o snapshot de banco de dados correto examinando a hora em que o snapshot foi obtido. Para ter mais informações, consulte Restaurar uma instância de banco de dados.

  • Se você quiser descrever o backup automatizado de uma instância de banco de dados do ambiente azul anterior ou restaurá-lo para um determinado momento, use o ID do recurso para a operação.

    Como o nome da instância de banco de dados muda durante a transição, você não pode usar seu nome anterior para operações DescribeDBInstanceAutomatedBackups ou RestoreDBInstanceToPointInTime.

    Para ter mais informações, consulte Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS.

  • Quando você adiciona uma réplica de leitura a uma instância de banco de dados no ambiente verde de uma implantação azul/verde, a nova réplica de leitura não substituirá uma réplica de leitura no ambiente azul quando você fizer a transição. No entanto, a nova réplica de leitura é mantida no novo ambiente de produção após a transição.

  • Quando você exclui uma instância 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 nome do recurso da Amazon (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 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 adicionando -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.

    O mesmo comportamento se aplica às instâncias de banco de dados e às réplicas de leitura.