Este documento oferece uma visão geral das implantações azul-verde do Cloud SQL, que permitem fazer atualizações de banco de dados, como upgrades de versão principal e modificações de hardware, minimizando o tempo de inatividade.
Objetivos e casos de uso de implantação
É possível criar uma implantação azul-verde com ou sem a intenção de fazer um upgrade de versão principal:
- Criar com intenção (upgrade da versão principal): faz upgrade do mecanismo do banco de dados para uma versão principal mais recente. Durante a criação da implantação, o Cloud SQL executa a API de pré-verificação de upgrade da versão principal para verificar a compatibilidade antes de continuar com o fluxo de trabalho de upgrade.
- Criar sem intenção (mudanças de configuração ou hardware): faz modificações na versão atual do banco de dados. Os casos de uso incluem a mudança de tipos de máquinas (escalonamento de CPU/RAM), teste de flags de banco de dados ou avaliação de modificações de armazenamento sem fazer upgrade da versão do mecanismo.
Como as implantações azul-verde funcionam
As implantações azul-verde do Cloud SQL oferecem um fluxo de trabalho automatizado ao organizar as mudanças em um ambiente secundário temporário antes de alternar o tráfego ativo.
Durante uma implantação azul-verde, o Cloud SQL cria um ambiente de teste separado (verde) que espelha seu ambiente de produção atual (azul). O serviço mantém a replicação lógica contínua do azul para o verde. Você pode testar completamente a compatibilidade e o desempenho do aplicativo no ambiente verde sem afetar o tráfego de produção. Quando estiver tudo pronto, você vai acionar uma alternância rápida que atribui o ambiente verde ao status de leitura e gravação de produção com tempo de inatividade mínimo do aplicativo (geralmente em segundos).
Componentes de uma implantação azul-verde
Uma implantação azul-verde consiste nos seguintes componentes:
- Ambiente azul (origem): seu ambiente de produção atual que atende ativamente ao tráfego de aplicativos. Ela consiste na instância de leitura e gravação de origem e em qualquer configuração associada.
- Ambiente verde (destino): um ambiente de teste temporário e isolado
criado pelo Cloud SQL como um clone do ambiente azul. O ambiente verde incorpora as mudanças solicitadas (como uma versão mais recente do banco de dados) e permanece sincronizado com o ambiente azul usando a replicação contínua.
O Cloud SQL nomeia automaticamente a instância de staging verde usando o padrão
BLUE_INSTANCE_NAME-green-UNIQUE_ID, em que BLUE_INSTANCE_NAME é truncado para um máximo de 48 caracteres e UNIQUE_ID é um identificador hexadecimal de 8 caracteres. Failover:o processo planejado e iniciado pelo usuário de conversão do ambiente verde para se tornar a nova instância de leitura e gravação de produção. Durante a troca, o Cloud SQL troca os endpoints de conexão para que os aplicativos se conectem ao ambiente verde com uma breve queda de conexão (normalmente em segundos). O tempo de inatividade esperado durante a troca varia de acordo com a edição do Cloud SQL:
- Edição Cloud SQL Enterprise Plus:o tempo de inatividade de failover geralmente é inferior a um segundo.
- Cloud SQL Enterprise Edition:o tempo de inatividade de failover geralmente é inferior a 60 segundos, dependendo da carga de trabalho e do atraso de replicação.
Ao contrário de um failover não planejado (que é acionado automaticamente durante uma interrupção), um switchover é uma operação controlada usada para gerenciamento de mudanças planejadas.
Exclusão:o processo de remoção do recurso de implantação azul-verde. O comportamento de exclusão varia de acordo com a ocorrência ou não da troca:
- Antes da troca:a exclusão da implantação remove a instância de preparação verde e o recurso de implantação. A instância de produção azul não é afetada e continua atendendo ao tráfego.
- Após a troca:a exclusão da implantação remove os metadados dela. Por padrão, a instância convertida (verde) e a instância azul são mantidas. Se quiser, exclua a instância azul para evitar cobranças contínuas.
Ciclo de vida e estados de implantação
Uma implantação azul-verde passa por quatro fases distintas do ciclo de vida:
- Criação e preparo (
PROVISIONING): quando você solicita uma implantação azul-verde, o Cloud SQL provisiona uma instância de destino verde temporária que clona seu ambiente de produção azul. No caso de um upgrade de versão principal, o Cloud SQL também executa a API de pré-verificação de upgrade de versão principal para validar a compatibilidade do banco de dados antes de prosseguir com o fluxo de trabalho de upgrade. O Cloud SQL aplica o upgrade ou a mudança de configuração solicitada ao ambiente verde e inicia a replicação lógica contínua do azul para o verde. - Verificação de preparo (
SWITCHOVER_READYouSWITCHOVER_NOT_READY): quando a replicação inicial termina, a implantação entra no estadoSWITCHOVER_READY(ouSWITCHOVER_NOT_READYse a replicação for interrompida ou se ocorrerem erros). O azul continua atendendo ao tráfego de produção em tempo real. Você se conecta ao verde para executar testes de validação, verificar a compatibilidade do aplicativo e testar o desempenho da consulta. - Execução da alternância (
SWITCHOVER_IN_PROGRESSouSWITCHOVER_COMPLETED): quando você aciona a alternância, o Cloud SQL executa pré-verificações de segurança, troca os endpoints de conexão e define a instância verde como sua instância de leitura e gravação de produção ativa (SWITCHOVER_COMPLETED) e faz a transição da instância azul para uma instância independente de leitura e gravação. As operações de leitura e gravação ativas são encaminhadas exclusivamente para a instância verde, e a replicação lógica do azul para o verde é encerrada. Para mais informações, consulte Fazer uma troca de implantação azul-verde. Exclusão (
DELETING): quando você termina de testar ou depois de verificar as operações de produção, exclui o recurso de implantação. O comportamento de exclusão varia de acordo com o estado da implantação:- Antes da troca (cancelamento): se você decidir não continuar com a implantação ou se surgirem problemas de verificação, a exclusão da implantação removerá a instância de pré-produção verde e os metadados da implantação. A instância de produção azul original permanece intacta e continua atendendo ao tráfego sem interrupção.
- Após a substituição (limpeza): depois que a substituição for concluída e você verificar
as operações na nova instância de produção, a exclusão da implantação removerá
os metadados dela. Por padrão, a nova instância de produção (verde) e a instância azul são mantidas como instâncias independentes de leitura e gravação. Você também pode especificar a flag
--delete-old-sourcepara excluir permanentemente a instância azul e parar de receber cobranças por ela.
Para mais informações, consulte Excluir uma implantação azul-verde.
Estados de recursos de implantação
Ao inspecionar uma implantação azul-verde, o campo state indica o
status atual do ciclo de vida:
PROVISIONING:a implantação está sendo criada. Para upgrades de versão principal, o Cloud SQL executa a API de pré-verificação para validar a compatibilidade antes de continuar. O Cloud SQL provisiona o ambiente verde, aplica os upgrades solicitados e configura a replicação lógica contínua.SWITCHOVER_READY:o ambiente verde é provisionado, a replicação lógica do azul para o verde está íntegra, e a implantação está pronta para failover.SWITCHOVER_NOT_READY:a implantação foi provisionada, mas a troca não pode ser iniciada. Isso acontece se a replicação lógica for interrompida ou quebrada, se a replicação inicial não for concluída ou se um nó pareado encontrar um erro.SWITCHOVER_IN_PROGRESS:uma operação de failover está em execução. O Cloud SQL está trocando os endpoints de conexão e convertendo a instância verde na instância de leitura e gravação de produção ativa.SWITCHOVER_COMPLETED:a operação de failover foi concluída com sucesso. A instância verde agora é sua instância de leitura e gravação de produção ativa, e a azul é mantida como uma instância independente de leitura e gravação.DELETING:a implantação está sendo excluída. Se a exclusão for feita antes da mudança, o Cloud SQL vai remover a instância de staging verde e excluir os metadados de implantação. Se a exclusão for feita após a troca, o Cloud SQL vai remover os metadados da implantação e, opcionalmente, excluir a instância azul se a flag--delete-old-sourcefor especificada.STATE_UNSPECIFIED:o estado da implantação é desconhecido.
Estados e prontidão da troca
A prontidão para failover depende da integridade da replicação e do status do nó para proteger seu banco de dados de produção contra perda de dados ou tempo de inatividade prolongado:
- Integridade e atraso da replicação:se a replicação lógica entre azul e verde for interrompida, pausada ou falhar, o status da implantação vai mudar para
SWITCHOVER_NOT_READY. A implantaçãostatee a saída de descrição não informam o atraso de replicação, e o Cloud SQL não avalia o atraso de replicação como uma pré-verificação ao determinar o status da implantação. No entanto, a operação de alternância vai falhar se o atraso na replicação for muito alto quando a alternância for iniciada. Para garantir uma troca bem-sucedida, verifique se o atraso na replicação é mínimo antes de iniciar a troca. É possível monitorar o atraso de replicação no Cloud Monitoring (verificando métricas comoreplica_lagna lista de métricas do Cloud SQL) ou diretamente na instância verde. Para mais informações, consulte Monitorar o atraso de replicação. - Status do nó pareado:em
deploymentMappings, cada nó pareado informa o próprio estado (comoPROVISIONED,UPGRADED,UPGRADE_FAILED,SWITCHOVER_IN_PROGRESS,SWITCHOVER_SUCCEEDEDouSWITCHOVER_FAILED). Se um nó pareado encontrar um erro (UPGRADE_FAILEDouSWITCHOVER_FAILED), o estado geral da implantação vai mudar paraSWITCHOVER_NOT_READY. Se uma substituição falhar, o roteamento vai permanecer na instância azul sem perda de dados. - Solução de problemas de prontidão para failover:se a implantação informar
SWITCHOVER_NOT_READY, verifique o campoerrorDetailpara diagnosticar erros de replicação ou de nó. Antes de iniciar a troca, verifique se o atraso de replicação é mínimo e se as operações DDL de lote ativas ou as transações de gravação de longa duração na instância azul foram concluídas.
Limitações
Confira as limitações a seguir antes de usar implantações azul-verde:
- Mecanismos e versões compatíveis:as instâncias do Cloud SQL para MySQL no MySQL 5.7 e versões mais recentes são compatíveis com o preparo da configuração (criação sem intenção). Os destinos de upgrade de versão principal (criar com intenção) são compatíveis com o MySQL 8.0 para 8.4. O MySQL 8.0.18 não é compatível com implantações azul-verde.
- Mecanismos de banco de dados não compatíveis:o Cloud SQL para PostgreSQL e o Cloud SQL para SQL Server não são compatíveis.
- Instâncias com réplicas de leitura:as implantações azul-verde não são compatíveis com instâncias com réplicas de leitura.
- Configurações de rede sem suporte:implantações azul-verde não oferecem suporte a configurações de saída do Private Service Connect.
- Autenticação de grupo do IAM:os implantações azul-verde são incompatíveis com a autenticação de grupo do IAM do MySQL e podem causar falhas de failover.
- Requisito de arquitetura de rede:as instâncias do Cloud SQL precisam usar a nova arquitetura de rede. Não há suporte para instâncias que usam a arquitetura de rede antiga.
- Requisito de geração de registros binários:as instâncias do MySQL precisam ter backups automatizados e geração de registros binários ativados para oferecer suporte à replicação lógica contínua no ambiente verde.
- Requisito de versão de manutenção:sua instância de origem azul precisa executar a versão de manutenção mais recente antes de você criar uma implantação azul-verde. Para verificar ou atualizar a versão de manutenção da instância, consulte Fazer manutenção de autoatendimento.
- Disponibilidade de recursos:o provisionamento de instâncias durante fluxos de trabalho de implantação azul-verde, incluindo a criação da instância de preparo verde e da instância azul após o failover, pode ser afetado por restrições de recursos de computação na região ou zona selecionada.
- Interrupções e failover não planejados:a troca de implantação azul-verde é uma operação estritamente planejada que exige uma instância de origem azul
RUNNINGíntegra. A instância de preparo verde funciona como uma réplica de leitura especializada. Assim como as réplicas de leitura padrão, a instância verde não pode ser usada como um destino de failover durante uma interrupção não planejada da instância de origem. Para recuperação automática de interrupções, configure sua instância para alta disponibilidade ou use uma réplica de recuperação de desastres (DR, na sigla em inglês).
Faturamento e preços
Não há cobrança adicional para usar implantações azul-verde. No entanto, como um ambiente verde paralelo completo é provisionado durante a implantação, você recebe cobranças de tarifas padrão pelas instâncias azul e verde durante todo o período em que os dois ambientes existem.
Para evitar cobranças desnecessárias, exclua a implantação e as instâncias associadas:
- Antes da troca:se você cancelar a implantação, exclua-a para remover a instância de staging verde e interromper as cobranças dela.
- Após a substituição:exclua a implantação e especifique a flag
--delete-old-sourcepara excluir permanentemente a instância azul depois de verificar a nova instância de produção. Se você não excluir a instância azul, vai continuar recebendo cobranças pelas duas.
A seguir
- Crie e organize uma implantação azul-verde.
- Descrever e listar implantações azul-verde.
- Mude uma implantação azul-verde.
- Exclua uma implantação azul-verde.