Limitações e considerações relativas às implantações azul/verde do Amazon RDS - Amazon Relational Database Service
LimitaçõesConsiderações

Limitações e considerações relativas às implantações azul/verde do Amazon RDS

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 RDS para MySQL:

  • 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 obter 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 para implantações azuis/verdes com replicação física

As seguintes limitações não se aplicam às implantações azuis/verdes do RDS para PostgreSQL que usam replicação física. Para obter uma explicação de quando as implantações azuis/verdes usam a replicação física em vez da replicação lógica, consulte Métodos de replicação do PostgreSQL em implantações azuis/verdes.

  • Depois que o ambiente verde for criado, não será possível fazer uma atualização manual da versão principal.

  • As implantações azuis/verdes que usam replicação física não oferecem suporte a alterações de esquema no ambiente verde, pois ele é estritamente somente leitura.

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

Limitações do RDS para PostgreSQL em implantações azuis/verdes com replicação lógica

As seguintes limitações do se aplicam às implantações azuis/verdes do RDS para PostgreSQL que usam replicação lógica. Para obter uma explicação de quando as implantações azuis/verdes usam a replicação lógica em vez da replicação física, consulte Métodos de replicação do PostgreSQL em implantações azuis/verdes.

  • As tabelas não registradas não são replicadas no ambiente verde.

  • A instância de banco de dados azul não pode ser uma origem lógica (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.

  • O processo de aplicação 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).

  • Não é possível criar outras partições em tabelas particionadas durante implantações azul/verde do RDS para PostgreSQL. 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.

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

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 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 . Para obter mais informações sobre a replicação lógica do PostgreSQL, consulte a documentação do PostgreSQL.

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ê 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 Amazon RDS para PostgreSQL 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 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.
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 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. Você deve excluir a implantação azul/verde e todos os bancos de dados verdes e, em seguida, recriá-la.

As visõ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, 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.

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, 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 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 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 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 obter 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.

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

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