

# Mudar uma implantação azul/verde no Amazon RDS
<a name="blue-green-deployments-switching"></a>

Uma *transição* transforma o ambiente verde no novo ambiente de produção. Quando a instância de banco de dados verde tem réplicas de leitura, elas também são transicionadas. Antes de você fazer a transição, o tráfego de produção é roteado para a instância de banco de dados e lê as réplicas no ambiente azul. Antes de você fazer a transição, o tráfego de produção é roteado para a instância de banco de dados e lê as réplicas no ambiente verde.

*Mudar para* uma implantação azul/verde não é o mesmo que *promover* a instância de banco de dados verde na implantação azul/verde. Se você promover manualmente a instância de banco de dados escolhendo **Promover** no menu **Ações**, a replicação entre os ambientes azul e verde será interrompida e a implantação azul/verde entrará no estado de **Configuração inválida**. 

**Topics**
+ [Tempo limite de transição](#blue-green-deployments-switching-timeout)
+ [Barreiras de proteção de transição](#blue-green-deployments-switching-guardrails)
+ [Ações de transição](#blue-green-deployments-switching-actions)
+ [Práticas recomendadas de transição](#blue-green-deployments-switching-best-practices)
+ [Verificar as métricas do CloudWatch antes da transição](#blue-green-deployments-switching-over-cloudwatch)
+ [Monitorar o atraso da réplica antes da transição](#blue-green-deployments-monitor-replica-lag)
+ [Realizar a transição de uma implantação azul/verde](#blue-green-deployments-switching-over)
+ [Após a transição](#blue-green-deployments-switching-after)

## Tempo limite de transição
<a name="blue-green-deployments-switching-timeout"></a>

Você pode especificar um tempo limite de transição entre 30 segundos e 3.600 segundos (uma hora). Se a transição demorar mais do que o especificado, todas as alterações serão revertidas e nenhuma alteração será feita em nenhum dos ambientes. O limite de tempo padrão é 300 segundos (cinco minutos).

## Barreiras de proteção de transição
<a name="blue-green-deployments-switching-guardrails"></a>

Quando você inicia uma transição, o Amazon RDS executa algumas verificações básicas para testar a prontidão dos ambientes azul e verde para a transição. Essas verificações são conhecidas como *barreiras de proteção de transição*. Essas barreiras evitarão uma transição se os ambientes não estiverem prontos para isso. Portanto, elas evitam tempo de inatividade mais longo do que o esperado e evitam a perda de dados entre os ambientes azul e verde que pode ocorrer se a transição for iniciada.

O Amazon RDS executa as seguintes verificações de barreira de proteção no ambiente verde:
+ **Integridade da replicação**: confira se o status de replicação da instância de banco de dados primária verde é íntegro. A instância de banco de dados primária verde é uma réplica da instância de banco de dados primária azul.
+ **Atraso na replicação**: confira se o atraso da réplica da instância de banco de dados primária está nos limites permitidos para a transição. Os limites permitidos são baseados no tempo limite especificado. O atraso da réplica indica até que ponto a instância de banco de dados primária verde está atrás de sua instância de banco de dados primária azul. Para obter mais informações, consulte [Monitorar o atraso da réplica antes da transição](#blue-green-deployments-monitor-replica-lag).
+ **Gravações ativas**: certifique-se de que não haja gravações ativas na instância de banco de dados primária.

O Amazon RDS executa as seguintes verificações de barreira de proteção no ambiente azul:
+ **Replicação externa**: para o RDS for PostgreSQL, garante que o ambiente azul não seja uma fonte lógica autogerenciada (publicador) nem uma réplica (assinante). Se ele for, recomendamos que você elimine os slots de replicação autogerenciados e as assinaturas em todos os bancos de dados no ambiente azul, continue com a transição e, depois, recrie-os para retomar a replicação. Para o RDS para MySQL e RDS para MariaDB, verifica se o banco de dados azul não é uma réplica externa de log binário. Se for, verifique se ele não está se replicando ativamente.
+ **Gravações ativas de longa duração**: verifica se não há gravações ativas de longa duração na instância de banco de dados primária azul, pois elas podem aumentar o atraso da réplica.
+ **Instruções DDL de longa duração**: verifica se não há instruções DDL de longa duração na instância de banco de dados primária azul, pois elas podem aumentar o atraso da réplica.
+ **Alterações não compatíveis do PostgreSQL**: para RDS para PostgreSQL que usam replicação lógica, verifica se não há nenhuma alteração de DDL e se nenhuma adição ou modificação de objetos grandes foi realizada no ambiente azul. Para obter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).

  Se o Amazon RDS detectar alterações não compatíveis do PostgreSQL, ele alterará o estado de replicação para `Replication degraded` e notificará você de que a transição não está disponível para a implantação azul/verde. Para continuar com a transição, recomendamos que você exclua e recrie a implantação azul/verde e todos os bancos de dados verdes. Para fazer isso, escolha **Ações**, **Excluir com bancos de dados verdes**.

## Ações de transição
<a name="blue-green-deployments-switching-actions"></a>

Quando você alterna uma implantação azul/verde, o RDS realiza as seguintes ações:

1. Executa verificações de barreira de proteção para verificar se os ambientes azul e verde estão prontos para a transição.

1. Interrompe novas operações de gravação na instância de banco de dados primária nos dois ambientes.

1. Descarta conexões com as instâncias de banco de dados em ambos os ambientes e não permite novas conexões.

1. Espera que a replicação alcance o ambiente verde para que este esteja em sincronia com o ambiente azul.

1. Renomeia as instâncias de banco de dados nos dois ambientes.

   O RDS renomeia as instâncias de banco de dados no ambiente verde para coincidir com as instâncias de banco de dados no ambiente azul. Por exemplo, suponha que o nome de uma instância de banco de dados no ambiente azul seja `mydb`. Suponha também que o nome da instância de banco de dados correspondente no ambiente verde seja `mydb-green-abc123`. Durante a transição, o nome da instância de banco de dados no ambiente verde é alterado para `mydb`.

   O RDS renomeia as instâncias de banco de dados no ambiente azul anexando `-oldn` ao nome atual, em que `n` é um número. Por exemplo, suponha que o nome de uma instância de banco de dados no ambiente azul seja `mydb`. Após a transição, o nome da instância de banco de dados pode ser `mydb-old1`.

   O RDS também renomeia os endpoints no ambiente verde para corresponder aos endpoints correspondentes no ambiente azul, para que as alterações na aplicação não sejam necessárias.

1. Permite conexões com bancos de dados nos dois ambientes.

1. Permite operações de gravação na instância de banco de dados primária no novo ambiente de produção.

   Após a transição, a instância de banco de dados primária de produção anterior só permite operações de leitura até que você defina o parâmetro `read_only` (para RDS para MySQL) ou o parâmetro `default_transaction_read_only` (para RDS para PostgreSQL) como `0` e reinicialize a instância de banco de dados. 

Você pode monitorar o status de uma transição usando o Amazon EventBridge. Para obter mais informações, consulte [Eventos de implantação azul/verde](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments).

Durante a transição, as tags do ambiente azul substituem todas as tags dos recursos no ambiente verde. Todas as tags adicionadas diretamente aos recursos do ambiente verde são substituídas durante esse processo. Para ter mais informações sobre tags, consulte [Marcar recursos do do Amazon RDS](USER_Tagging.md).

Se a transição começar e parar antes de terminar por qualquer motivo, todas as alterações serão revertidas e nenhuma alteração será feita em nenhum dos ambientes.

## Práticas recomendadas de transição
<a name="blue-green-deployments-switching-best-practices"></a>

Antes de fazer a transição, é altamente recomendável que você siga as práticas recomendadas concluindo as seguintes tarefas:
+ Teste minuciosamente os recursos no ambiente verde. Eles devem funcionar de forma adequada e eficiente.
+ Monitore as métricas relevantes do Amazon CloudWatch. Para obter mais informações, consulte [Verificar as métricas do CloudWatch antes da transição](#blue-green-deployments-switching-over-cloudwatch).
+ Identifique o melhor momento para a transição.

  Durante a transição, as gravações são cortadas dos bancos de dados nos dois ambientes. Identifique um momento em que o tráfego é o menor em seu ambiente de produção. Transações de longa duração, como DDLs ativas, podem aumentar seu tempo de transição, ocasionando maior tempo de inatividade para suas workloads de produção.

  Se houver um grande número de conexões em suas instâncias de banco de dados, considere reduzi-las manualmente até a quantidade mínima necessária para sua aplicação antes de realizar a transição da implantação azul/verde. Uma maneira de fazer isso é criar um script que monitore o status da implantação azul/verde e comece a limpar as conexões quando detectar que o status mudou para `SWITCHOVER_IN_PROGRESS`.
+ As instâncias nos dois ambientes devem estar no estado `Available`.
+ A instância de banco de dados primária no ambiente verde devem estar funcionando e sendo replicada .
+ Garanta que suas configurações de rede e cliente não aumentem o tempo de vida útil (TTL) do cache DNS além de cinco segundos, que é o padrão para zonas DNS do RDS. Do contrário, as aplicações continuarão a enviar tráfego de gravação ao ambiente azul após a transição.
+ O carregamento de dados deve ser concluído antes da transição. Para obter mais informações, consulte [Carregamento lento e inicialização de armazenamento para implantações azuis/verdes](blue-green-deployments-creating.md#blue-green-deployments-creating-lazy-loading).
+ Para implantações azuis/verdes do RDS para PostgreSQL que usam replicação lógica, faça o seguinte:
  + Analise as limitações de replicação lógica e realize todas as ações necessárias antes da transição. Para obter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
  + Execute a operação `ANALYZE` para atualizar a tabela `pg_statistics`. Isso reduz o risco de problemas de desempenho após a transição.
  + Antes de iniciar uma transição de implantação azul/verde, verifique se a aplicação não substitui o parâmetro `default_transaction_read_only` em nível de sessão. Durante a transição, esse parâmetro é definido como `on` no gravador do ambiente verde para evitar gravações enquanto a promoção não for concluída. Se a aplicação ou as transações substituírem essa configuração por `off`, a aplicação poderá gravar dados no ambiente verde durante o processo de transição. Caso seja necessário reverter a transição, essas gravações não estarão disponíveis no ambiente azul, o que exige que as inconsistências nos dados sejam resolvidas manualmente. Antes de prosseguir com a transição, é altamente recomendável auditar as consultas à aplicação para garantir que elas respeitem a configuração `default_transaction_read_only`.

**nota**  
Durante uma transição, você não pode modificar nenhuma instância de banco de dados incluída na transição .

## Verificar as métricas do CloudWatch antes da transição
<a name="blue-green-deployments-switching-over-cloudwatch"></a>

Antes de realizar a transição de uma implantação azul/verde, recomendamos que verifique os valore das métrica a seguir no Amazon CloudWatch.
+ `DatabaseConnections`: use esta métrica para estimar o nível de atividade na implantação azul/verde; certifique-se de que o valor esteja em um nível aceitável para sua implantação antes da transição. Se o recurso Insights de Performance estiver ativado, `DBLoad` será uma métrica mais precisa.

Para obter mais informações, consulte [Métricas do Amazon CloudWatch para o Amazon RDS](rds-metrics.md).

## Monitorar o atraso da réplica antes da transição
<a name="blue-green-deployments-monitor-replica-lag"></a>

Antes de realizar a transição de uma implantação azul/verde, verifique se o atraso de réplica é próximo de zero para reduzir o tempo de inatividade.

### RDS para MySQL e RDS para MariaDB
<a name="blue-green-deployments-monitor-replica-lag-ms-mdb"></a>

Para implantações azul/verde do MySQL e MariaDB, confira a métrica `ReplicaLag` do CloudWatch no ambiente verde para identificar o atraso atual da réplica. Para obter mais informações, consulte [Diagnosticar e resolver atrasos entre réplicas de leitura](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).

### RDS para PostgreSQL
<a name="blue-green-deployments-monitor-replica-lag-pg"></a>

Para implantações azuis/verdes do PostgreSQL que usam replicação física, consulte [Monitoração e ajuste do processo de replicação](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md) para obter instruções sobre como identificar o atraso atual da réplica.

Para implantações azuis/verdes do PostgreSQL que usam replicação lógica, verifique a métrica `OldestReplicationSlotLag` do CloudWatch no ambiente azul para identificar o atraso atual da réplica. Para obter mais informações, consulte [Métricas específicas da instância do Amazon CloudWatch para Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).

Além disso, você pode executar a consulta SQL a seguir no ambiente azul:

```
SELECT slot_name,
       confirmed_flush_lsn as flushed,
       pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';

slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192
```

O `confirmed_flush_lsn` representa o número de sequência de log (LSN) mais recente enviado à réplica. O `pg_current_wal_lsn` representa onde o banco de dados está agora. Um `lsn_distance` de 0 significa que a réplica foi capturada.

Para obter uma explicação de quando as implantações azuis/verdes usam replicação física versus replicação lógica, consulte [Métodos de replicação do PostgreSQL em implantações azuis/verdes](blue-green-deployments-replication-type.md).

## Realizar a transição de uma implantação azul/verde
<a name="blue-green-deployments-switching-over"></a>

Você pode fazer a transição de uma implantação azul/verde usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS.

### Console
<a name="blue-green-deployments-switching-console"></a>

**Como realizar a transição de uma implantação azul/verde**

1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

1. No painel de navegação, selecione **Databases** (Bancos de dados) e, depois, selecione a implantação azul/verde da qual você deseja realizar a transição.

1. Para **Actions** (Ações), selecione **Switch over** (Realizar transição).

   A página **Switch over** (Realizar transição) é exibida.  
![\[Fazer a transição de uma implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/blue-green-deployment-switch-over.png)

1. Na página **Switch over** (Realizar transição), revise o resumo da transição. Os recursos nos dois ambientes devem corresponder ao que você espera. Caso contrário, selecione **Cancel** (Cancelar).

1. Em **Timeout** (Tempo limite), insira o limite de tempo para a transição.

1. Se seu , analise e confirme as recomendações de pré-transição. Para obter mais informações, consulte [Limitações específicas de replicação lógica para implantações azuis/verdes](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).

1. Selecione **Switch Role** (Realizar transição).

### AWS CLI
<a name="blue-green-deployments-switching-cli"></a>

Para realizar a transição de uma implantação azul/verde usando a AWS CLI, utilize o comando [switchover-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html) com as seguintes opções:
+ `--blue-green-deployment-identifier`: especifique o ID do recurso da implantação azul/verde.
+ `--switchover-timeout`: especifique o limite de tempo para a transição, em segundos. O padrão é 300.

**Example Fazer a transição de uma implantação azul/verde**  
Para Linux, macOS ou Unix:  

```
aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600
```
Para Windows:  

```
aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600
```

### API do RDS
<a name="blue-green-deployments-switching-api"></a>

Para realizar a transição de uma implantação azul/verde usando a API do Amazon RDS, use a operação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html) com os seguintes parâmetros:
+ `BlueGreenDeploymentIdentifier`: especifique o ID do recurso da implantação azul/verde.
+ `SwitchoverTimeout`: especifique o limite de tempo para a transição, em segundos. O padrão é 300.

## Após a transição
<a name="blue-green-deployments-switching-after"></a>

Depois de uma transição, as instâncias de banco de dados no ambiente azul anterior são retidas. Os custos padrão se aplicam a esses recursos. A replicação entre os ambientes azul e verde é interrompida.

O RDS renomeia as instâncias de banco de dados no ambiente azul anexando `-oldn` ao nome de recurso atual, em que `n` é um número. As instâncias de banco de dados no antigo ambiente azul são somente leitura até que você defina o parâmetro `read_only` (para RDS para MySQL) ou o parâmetro `default_transaction_read_only` (para RDS para PostgreSQL) como `0`.  O RDS nomeia as instâncias de banco de dados no ambiente verde `-newn`.

Se você excluir o recurso de implantação azul/verde, o RDS reterá os recursos `-oldn` e `-newn`.

![\[Depois de realizar a transição de uma implantação azul/verde\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/blue-green-deployment-after-switchover.png)


### Atualizar o nó principal para consumidores
<a name="blue-green-deployments-switching-reparent"></a>

O RDS oferece réplicas de leitura totalmente gerenciadas. No entanto, ele também oferece a opção de configurar réplicas autogerenciadas, também conhecidas como *réplicas externas*. As réplicas externas possibilitam o uso de recursos de terceiros como destinos de replicação.

Depois de fazer a transição de uma implantação azul/verde do RDS para MariaDB ou do RDS para MySQL, se a instância de banco de dados tiver alguma réplica externa ou consumidores de log binário antes da transição, será necessário atualizar o nó principal após a transição a fim de manter a continuidade da replicação. 

**Como atualizar o nó pai**

1. Após a transição, a instância de banco de dados de que estava anteriormente no ambiente verde emite um evento que contém o nome do arquivo de log principal e a posição do log principal. Para localizar o evento, acesse o console do RDS e escolha **Eventos** no painel de navegação esquerdo.

1. Filtre por eventos em que a origem é o nome da antiga instância de banco de dados verde do , antes da transição.

1. Localize o evento que contém as coordenadas de logs binários. A mensagem do evento é semelhante a: `Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574`.

1. Garanta que o consumidor ou a réplica tenha aplicado todos os logs binários do antigo ambiente azul. Depois, use as coordenadas de logs binários fornecidas para retomar a replicação nos consumidores. Por exemplo, se você estiver executando uma réplica do MySQL no EC2, poderá usar o seguinte comando:

   **MySQL 8.0.22 e versões principais e secundárias anteriores**

   ```
   CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=40134574;
   ```

   **MySQL 8.0.23 e versões principais e secundárias posteriores**

   ```
   CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
   ```

Se o consumidor for outra instância de banco de dados do RDS para MariaDB ou do RDS para MariaDB, execute os seguintes procedimentos armazenados na ordem: 

1. [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication)

1. [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) (para a versão 8.0 e anteriores) ou [mysql\$1rds\$1reset\$1external\$1source](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) (para a versão 8.4 e posteriores)

1. [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) (para a versão 8.0 e anteriores) ou [mysql\$1rds\$1set\$1external\$1source](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) (para a versão 8.4 e posteriores)

1. [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)