Sobre a manutenção em instâncias do Cloud SQL

Nesta página, você verá como as atualizações de manutenção ocorrem nas instâncias do Cloud SQL e como controlar o momento dessas atualizações. Para dar os primeiros passos, consulte Como localizar e configurar janelas de manutenção.

Informações gerais

Por ser um serviço gerenciado, o Cloud SQL atualiza automaticamente as instâncias para garantir que o hardware, o sistema operacional e o mecanismo de banco de dados subjacentes sejam confiáveis, tenham alto desempenho e estejam seguros e atualizados. A maioria dessas atualizações é realizada enquanto a instância do Cloud SQL está em execução. No entanto, algumas atualizações do sistema exigem uma breve interrupção do serviço. Essas atualizações são chamadas de manutenção.

A manutenção atualiza o mecanismo de banco de dados e, em alguns casos, o sistema operacional. Como essas atualizações exigem que a instância seja reiniciada, elas geram um período de inatividade. As atualizações de manutenção oferecem os seguintes benefícios:

  • Recursos do Cloud SQL. Para lançar novos recursos, o mecanismo de banco de dados é atualizado, e novos plug-ins são instalados.

  • Upgrades da versão do banco de dados. O provedor do software de banco de dados que desenvolve o PostgreSQL lança novas versões secundárias várias vezes por ano. Cada nova versão contém correções de bugs, patches de segurança, melhorias de desempenho e novos recursos de banco de dados. Para encontrar a versão secundária mais recente compatível com o Cloud SQL para PostgreSQL, consulte as notas da versão ou as Versões do banco de dados e políticas de versão. As instâncias do Cloud SQL são atualizadas para a versão mais recente do banco de dados logo após o lançamento. Assim, você sempre executa o software de banco de dados mais recente.

  • Patches do sistema operacional. Estamos sempre monitorando vulnerabilidades de segurança recém-identificadas no sistema operacional. Após a descoberta, aplicamos um patch ao sistema operacional para proteger você contra novos riscos.

Impacto da manutenção

Para o Cloud SQL Enterprise Plus, o Cloud SQL oferece manutenção planejada com inatividade quase zero.

O Cloud SQL programa um evento de atualização de manutenção, que normalmente é feito a cada poucos meses. A atualização de manutenção pode levar de 5 a 10 minutos para cada instância. Se a instância tiver réplicas de leitura, a duração total da atualização de manutenção pode levar mais tempo. No entanto, durante o evento de atualização de manutenção, cada instância do Cloud SQL edição Enterprise perde a conectividade por menos de 30 segundos, em média. O tempo de inatividade pode ser maior para uma instância que está passando por altas quantidades de atividade durante o evento de atualização de manutenção ou que tem um conjunto de dados muito grande.

Você pode tomar medidas para garantir que a manutenção tenha o mínimo impacto possível em suas operações usando nossas configurações de manutenção e tornando seus sistemas resilientes a erros transitórios.

Manutenção planejada para inatividade quase zero

Com a manutenção planejada para inatividade quase zero, as instâncias do Cloud SQL Enterprise Plus geralmente perdem a conectividade por menos de um segundo durante a manutenção planejada.

O tempo de inatividade pode ser maior para instâncias com muita atividade durante a manutenção.

Pré-requisitos e restrições

  • O número de réplicas de leitura nas instâncias da edição Cloud SQL para PostgreSQL Enterprise Plus precisa ser menor que o valor definido para as sinalizações max_wal_senders e max_replication_slots. Para mais informações, consulte Configurar sinalizações do banco de dados.

  • Se você estiver usando o Cloud SQL Auth Proxy ou os conectores de linguagem do Cloud SQL, verifique se eles estão atualizados para a versão mais recente.

  • As tabelas não registradas ficarão vazias após a manutenção planejada.

  • Durante a manutenção, os registros do banco de dados terão mensagens de duas VMs diferentes.
  • Se uma DDL for emitida durante a manutenção planejada, as alterações poderão ter um carimbo de data/hora de criação ou modificação posterior ao carimbo de data/hora da manutenção.

Simular a manutenção planejada de inatividade quase zero

Para testar a inatividade de manutenção planejada da instância principal do Cloud SQL edição Enterprise Plus sem atualizar a instância do banco de dados, simule a manutenção planejada de inatividade quase zero.

Para fazer isso, invoque a simulação de um evento de manutenção em uma instância do Cloud SQL edição Enterprise Plus qualificada para manutenção planejada de inatividade quase zero. A solicitação de simulação resulta em uma operação de atualização da instância para a mesma versão da manutenção antes da operação.

É possível executar a simulação mesmo que você tenha uma atualização de manutenção pendente na instância. A versão da instância permanece igual durante toda a simulação.

Para simular um evento de manutenção planejada de inatividade quase zero, use o seguinte comando da gcloud CLI:

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

Substitua INSTANCE_NAME pelo nome da instância em que você quer executar o evento de manutenção simulado.

Configurações de manutenção

O Cloud SQL permite configurar atualizações de manutenção usando um conjunto de configurações de manutenção.

É possível configurar a manutenção para que seja programada para momentos em que um breve período de inatividade afeta menos os aplicativos. Para cada instância do Cloud SQL, configure o seguinte:

  • Horário da manutenção (anteriormente Ordem de atualização). A semana do período de lançamento para atualizar a instância do Cloud SQL. Siga uma destas instruções:

    • Any: a atualização de manutenção pode acontecer a qualquer momento, mas normalmente acontece dentro da semana 1.
    • Week 1: a manutenção ocorre de 7 a 14 dias após o envio da notificação de manutenção.
    • Week 2: a atualização de manutenção acontece de 15 a 21 dias após o envio da notificação.
    • Week 5: a atualização de manutenção ocorre de 35 a 42 dias após o envio da notificação.

    Você define a programação da atualização de manutenção ao configurar uma janela de manutenção.

  • Janela de manutenção. O dia da semana e o horário em que o Cloud SQL programa a manutenção. As janelas de manutenção duram uma hora. Saiba como configurar uma janela de manutenção.

  • Período de bloqueio de manutenção. Um intervalo de dias em que o Cloud SQL não programa manutenções. É possível definir um período de bloqueio de manutenção de até 90 dias. Saiba como configurar um período de bloqueio de manutenção.

Janelas de manutenção padrão

Se você não definir uma janela de manutenção, o Cloud SQL atualizará a instância nas seguintes janelas padrão de acordo com o fuso horário da instância:

  • Período da semana (de segunda a sexta-feira): das 22h às 6h
  • Janela de fim de semana: sexta-feira, das 22h à segunda-feira, às 6h

Exemplo de manutenção

Suponha que você trabalhe como desenvolvedor em um varejista gerenciando um serviço de carrinho de compras. Você tem uma instância do Cloud SQL para um ambiente de produção e uma segunda para um ambiente de preparo. Você quer que a manutenção ocorra no momento em que a instância processa a menor quantidade de tráfego, que é por volta da meia-noite aos domingos. Você também quer pular a manutenção durante a movimentada temporada de compras de fim de ano.

Nesse caso, defina as configurações de manutenção da instância de produção como:

  • Janela de manutenção: domingos entre 0h e 1h ET
  • Dia/hora da manutenção: Week 2
  • Período de bloqueio de manutenção: 1º de novembro a 15 de janeiro.

As configurações de manutenção do ambiente de preparo seriam idênticas, mas o tempo de manutenção seria definido como Week 2. Isso garante a execução de testes de aceitação operacional para uma versão de manutenção no ambiente de preparo pelo menos sete dias antes de a manutenção chegar à produção. Se ocorrer algum problema no ambiente de teste, você terá tempo para diagnosticar e corrigir o problema ou configurar um período de bloqueio de manutenção que o ambiente de produção não seja afetado.

Notificações de manutenções futuras

Você pode optar por receber uma notificação sobre uma manutenção futura no e-mail pelo menos uma semana antes da data programada. Se quiser definir um filtro de e-mail para notificações, o título do e-mail precisará ser Próxima manutenção da instância do Cloud SQL instancename.

As notificações para manutenção não são enviadas por padrão. Você precisa optar por receber as notificações de manutenção. Antes de receber notificações, você também precisa selecionar uma janela de manutenção.

As notificações são enviadas para o endereço de e-mail associado à sua Conta do Google. Não é possível configurar um alias de e-mail personalizado (por exemplo, um alias de e-mail de equipe).

Ative as notificações de manutenção de todas as instâncias do Cloud SQL que tiverem janelas de manutenção em um projeto específico. Você receberá uma notificação por instância. As notificações de manutenção futura não são enviadas para réplicas de leitura.

Você também pode ver informações sobre manutenções futuras no Console do Google Cloud.

  • Na lista Instâncias da coluna Manutenção. Se a manutenção estiver programada, você verá a data e a hora de início. Filtre a lista de instâncias usando o termo manutenção para encontrar todas as instâncias programadas para manutenção. A coluna Manutenção só é exibida quando há manutenção programada para uma ou mais instâncias no projeto. Se nenhuma manutenção estiver programada, a coluna permanecerá oculta.
  • Na página Detalhes da instância no painel Manutenção. Se a manutenção estiver programada, em Próxima, você verá a data e hora de início.

  • Na página ATIVIDADE no console do Google Cloud, é possível conferir uma lista de instâncias programadas para manutenção. Se a manutenção estiver programada, as instâncias terão a mensagem Manutenção do SQL e a data e hora de início da manutenção.

Remarcar manutenção

Se você tiver uma janela de manutenção para a instância, poderá reprogramar a atualização de manutenção até 24 horas antes do horário programado. Por exemplo, se você estiver lançando um novo serviço durante a janela de manutenção programada, é recomendável adiar a atualização de manutenção para alguns dias após o lançamento.

Há alguns limites para reprogramar atualizações de manutenção. Depois que o Cloud SQL envia o e-mail de notificação, ele realiza a atualização de manutenção em um período de sete semanas para evitar sobreposições com a próxima atualização de manutenção do Cloud SQL. Por exemplo, se você selecionar o período de manutenção da Semana 1 ou Semana 2, será possível reprogramar a atualização de manutenção para até 4 semanas (28 dias) após a data originalmente programada. Se você definir a instância para um período de manutenção na Semana 5, só será possível reagendar o evento de manutenção no máximo uma semana (7 dias) após a data original. É possível reprogramar a manutenção várias vezes, desde que o evento de manutenção reprogramado esteja dentro da duração de reprogramação definida pelo tempo de manutenção que você configurou para a instância.

Para todas as outras limitações, consulte Limitações de remarcação.

Você verá algumas opções de programação para a nova janela de manutenção:

  • Aplicar as atualizações imediatamente. É possível aplicar as atualizações à instância imediatamente em vez de esperar a janela de manutenção programada. Nesse caso, a manutenção geralmente começa em cinco minutos.

  • Reprogramar para outro horário. É possível adiar um evento de manutenção programado de duas maneiras:

    • Próxima janela disponível. Esta opção adia a manutenção para a próxima janela de manutenção disponível após o horário de manutenção programado atual, que costuma ser uma semana depois.
    • Horário específico. Essa opção permite escolher um horário específico para a duração de reprogramação definida pelo dia/hora da manutenção que você configurou para sua instância.
      • 28 dias se você selecionar a janela de manutenção da Semana 1 ou 2
      • 7 dias se você selecionar o tempo de manutenção da Semana 5

Para instruções sobre como reprogramar a manutenção, consulte Reprogramar a manutenção planejada.

Como funciona a manutenção

Para que a manutenção seja breve, o Cloud SQL usa um fluxo de trabalho de failover de manutenção que é muito parecido com o nosso fluxo de trabalho de failover automático para instâncias altamente disponíveis.

Resumindo, são estas etapas:

  1. configurar uma VM atualizada com o novo software;
  2. interromper o banco de dados na VM original;
  3. mudar o disco e o IP estático para a VM atualizada.
  4. iniciar o banco de dados na VM atualizada.

Percorra as guias a seguir para ver detalhes do fluxo de trabalho, incluindo pré e pós-manutenção.

Pré-manutenção

Antes da manutenção, o cliente se comunica com a VM original por um endereço IP estático. Os dados são armazenados em um disco permanente anexado à VM original. Neste exemplo, a instância do Cloud SQL tem alta disponibilidade configurada, o que significa que outra VM está em espera para assumir o controle no caso de uma interrupção não planejada. A instância do Cloud SQL está veiculando tráfego para o aplicativo.

Diagrama mostrando o estado de pré-manutenção

Etapa 1

Configurar a nova VM.

Uma nova máquina virtual (VM, na sigla em inglês) é configurada com as versões mais recentes do software do banco de dados e do sistema operacional (SO) da VM. O SO atualizado da VM é iniciado. A essa altura, o mecanismo de banco de dados ainda não foi iniciado. Para as instâncias altamente disponíveis, uma nova VM em espera também é configurada.

O período total de inatividade é substancialmente reduzido ao instalar a atualização de software em outra VM enquanto a instância original do Cloud SQL ainda está exibindo tráfego.

Diagrama mostrando a configuração da VM

Etapa 2

interromper o banco de dados na VM original;

O mecanismo de banco de dados é encerrado. Assim, é possível remover o disco da VM original e anexá-lo à VM atualizada. Antes de ser encerrado, o mecanismo de banco de dados aguarda alguns segundos para que as transações em andamento sejam confirmadas e as conexões atuais sejam drenadas. Depois disso, todas as transações abertas ou de longa duração são revertidas. O banco de dados para de aceitar novas conexões e as que já existem são eliminadas. A instância fica indisponível e o tempo de inatividade de manutenção é iniciado.

Diagrama da instância após o failover

Etapa 3

Mudar para a VM atualizada.

O disco é removido da VM original e anexado à VM atualizada. O endereço IP estático é reconfigurado para apontar para a VM atualizada. Isso garante que o aplicativo use o mesmo endereço IP de antes da manutenção. O cache do banco de dados é removido com a VM original, isto é, o cache do banco de dados é efetivamente limpo durante a manutenção.

Diagrama de alternância para VM atualizada

Etapa 4

iniciar o banco de dados na VM atualizada.

O mecanismo de banco de dados atualizado é iniciado no disco de dados. O uso de um disco de dados comum garante que todas as transações gravadas na instância original antes da manutenção ainda estejam presentes no banco de dados atualizado após a manutenção. Se alguma transação incompleta não terminar de reverter durante o encerramento do banco de dados, ele passará automaticamente pela recuperação de falhas para garantir que seja restaurado para um estado utilizável.

Diagrama de inicialização da VM atualizada

Pós-manutenção

Após a etapa 4, a instância do Cloud SQL está disponível para aceitar conexões e retorna para veicular o tráfego para o aplicativo.

Para o aplicativo, com exceção do software atualizado, a instância do Cloud SQL parece a mesma. O aplicativo ainda se conecta à instância do Cloud SQL usando o mesmo endereço IP estático, e a VM atualizada é executada na mesma zona que a VM original. Todos os dados gravados no banco de dados original são preservados.

Diagrama pós-manutenção

Minimizar o impacto da manutenção

Em geral, o Google Cloud recomenda que os usuários que executam aplicativos na nuvem tornem os sistemas resilientes a erros transitórios, que são problemas passageiros de comunicação entre serviços causados por indisponibilidade temporária. Os erros transitórios ocasionais são inevitáveis na nuvem.

Alguns dos erros transitórios que ocorrem durante a manutenção são quedas de conexão e transações em andamento com falha. Se você criar os sistemas e ajustar os aplicativos para serem resilientes a erros transitórios, também será possível reduzir os impactos da manutenção do banco de dados.

Para minimizar o impacto das quedas de conexão, use pools de conexões. As conexões entre o pooler e o banco de dados são eliminadas durante a manutenção, mas as conexões entre o aplicativo e o pooler são preservadas. Assim, o trabalho de restabelecer as conexões fica transparente para o aplicativo e é transferido para o pooler de conexões.

Para reduzir as falhas de transação, limite o número de transações de longa duração. Reescrever consultas para que fiquem menores e mais eficientes não apenas reduz o período de inatividade da manutenção, mas também melhora o desempenho e a confiabilidade do banco de dados.

É possível usar o Query Insights para identificar consultas lentas.

Para se recuperar com eficiência de quedas de conexão e falhas de transação, gerencie as conexões de banco de dados com eficiência. Você pode criar uma lógica de repetição de consulta e de conexão em espera exponencial nos aplicativos e poolers de conexão. Se uma consulta falhar ou uma conexão cair, o sistema instituirá um período de espera antes de tentar novamente. Esse período aumenta a cada nova tentativa subsequente. Por exemplo, o sistema pode esperar poucos segundos até a primeira tentativa, mas até um minuto para a quarta tentativa. Esse padrão garante que essas falhas sejam corrigidas sem sobrecarregar o serviço.

Outras soluções criativas também podem minimizar os impactos de manutenção, desde o uso de scripts para pré-aquecer o cache do banco de dados após a manutenção até a simplificação do número de tabelas em bancos de dados. Recomendamos seguir as práticas recomendadas e as diretrizes operacionais de gerenciamento de banco de dados para garantir que a manutenção ocorra sem problemas.

Manutenção urgente

Em casos muito raros, o Cloud SQL pode precisar programar a manutenção independentemente das configurações de manutenção para aplicar patches em problemas graves de estabilidade ou vulnerabilidades urgentes. Essas atualizações são entregues rapidamente, e o Cloud SQL as considera como inatividade no SLA.

Manutenção de autoatendimento

O Cloud SQL lança regularmente melhorias de software e patches para vulnerabilidades de segurança por meio de novas versões de manutenção que podem ser instaladas nas instâncias. O Cloud SQL mantém um registro de alterações de manutenção do Cloud SQL para cada versão principal do mecanismo de banco de dados. Para saber mais, consulte Registros de alterações de manutenção do Cloud SQL.

O Cloud SQL programa atualizações de manutenção uma vez a cada alguns meses para garantir que você tenha o software mais recente, mas é possível usar manutenção de autoatendimento para manter sua instância atualizada. se:

  • você precisar de uma atualização antes do próximo evento de manutenção programado;
  • você quiser usar o software mais recente depois de pular a atualização de manutenção mais recente.

Se você usar réplicas de leitura, poderá usar a manutenção de autoatendimento para atualizar todas as réplicas de leitura. Você especifica a instância principal, e a solicitação de manutenção atualiza todas as réplicas de leitura da instância principal para a versão de manutenção especificada. Em seguida, a instância principal é atualizada para a versão de manutenção.

Limitações de manutenção

Nesta seção, descrevemos as limitações da manutenção do Cloud SQL.

Reprogramar limitações

O que você precisa saber sobre a reprogramação:

  • É necessário reprogramar a manutenção pelo menos 24 horas antes do evento de manutenção programado originalmente.

  • É possível reprogramar a manutenção de uma ou várias instâncias no seu projeto. No entanto, isso precisa ser feito com uma instância por vez. A reprogramação em massa não está disponível.

  • É possível reprogramar a manutenção para um horário que se enquadre em um bloqueio de manutenção ou até mesmo fora da janela de manutenção, desde que a duração da reprogramação esteja dentro do período definido pelo período da manutenção que você configurou para sua instância.

  • Se uma operação de manutenção estiver em andamento, o reagendamento será adiado até a conclusão da operação.

Limitações do período de bloqueio de manutenção

Veja o que você precisa saber sobre os períodos de bloqueio de manutenção:

  • É possível ter um período de bloqueio de manutenção mesmo se você não tiver janelas de manutenção configuradas para sua instância. Os período de bloqueio de manutenção podem variar de 1 a 90 dias.

  • O período de manutenção de negação tem precedência sobre qualquer janela de manutenção programada. Se houver conflito entre o momento de uma janela de manutenção e o período de manutenção de negação, o período modificará a janela.

  • Os períodos de bloqueio de manutenção e o tempo de manutenção são recursos independentes. Se você criar um período de bloqueio de manutenção para uma instância com tempo de manutenção Week 1, ele não vai afetar a determinação da atualização programada para uma instância com tempo de manutenção Week 2. Se uma atualização de manutenção programada ocorrer dentro de um período de bloqueio de manutenção, o Cloud SQL não enviará uma notificação para as instâncias que você configurou com o dia/hora da manutenção.

  • Quando um período de bloqueio é definido em uma instância principal, a manutenção de todas as réplicas associadas a ela também é bloqueada. Por exemplo, uma instância principal localizada na região A tem três réplicas de leitura: duas na região A e outra na região B. Ao definir um período de bloqueio na instância principal, a manutenção de cada uma das réplicas, incluindo a réplica da região B, deixa de ser realizada até que o período de bloqueio da instância principal expire.

  • Se um período de manutenção de negação for definido após a manutenção, de modo que esse período se sobreponha ao tempo de manutenção programado, a atualização é ignorada.

  • É possível definir o período de bloqueio de manutenção como recorrente todos os anos, sem incluir o ano nos parâmetros de data de início e término. Se o ano for especificado, o período de bloqueio de manutenção será definido apenas para esse ano.

  • É possível definir vários períodos de negação de manutenção em um ano. É recomendável evitar encadeamentos de períodos de negação para pular eventos consecutivos de manutenção programada. É importante manter-se atualizado sobre a manutenção do Cloud SQL para garantir que a instância opere de maneira confiável. Normalmente, a manutenção do Cloud SQL é programada uma vez em um intervalo de alguns meses.

  • Para garantir a confiabilidade do serviço, o Cloud SQL poderá notificar os usuários com instâncias que executam versões de manutenção com mais de 12 meses para que o próximo lançamento de manutenção seja necessário.

  • Quando o período de manutenção de negação termina, o comportamento de manutenção regular é retomado.

  • Os períodos de bloqueio de manutenção não afetam as operações acionadas pelo usuário, como a manutenção de autoatendimento.

Perguntas frequentes sobre manutenção

O tempo de inatividade com manutenção é contabilizado no SLA?

O tempo de inatividade com manutenção normal não é contabilizado no SLA. No entanto, o Cloud SQL inclui o tempo de inatividade com manutenção urgente no SLA.

Como a manutenção afeta as réplicas de leitura?

  • O Cloud SQL sempre mantém réplicas de leitura antes da instância principal. Se a instância principal tiver uma janela de manutenção, as réplicas de leitura vão observar a mesma janela de manutenção.
  • Se a instância primária tiver várias réplicas de leitura, o Cloud SQL poderá atualizar algumas delas simultaneamente.
  • As réplicas de leitura também observam o período de manutenção de negação definido para a instância principal.

Posso cancelar uma manutenção programada?

Não é possível cancelar uma janela de manutenção programada, mas é possível reprogramá-la. Também é possível configurar um período de bloqueio de manutenção que se sobreponha ao tempo de manutenção programado para pular a manutenção de maneira eficaz.

O que acontece se o evento de manutenção for cancelado?

Se o Cloud SQL cancelar um evento de manutenção, você receberá uma notificação de que a manutenção será cancelada com antecedência, quando possível.

Você receberá uma nova notificação de manutenção futura quando o evento de manutenção for reprogramado.

A manutenção do Cloud SQL é cumulativa?

As atualizações de manutenção são cumulativas. Não é necessário aplicar cada atualização de manutenção perdida. A versão de manutenção mais recente será aplicada na próxima atualização de manutenção programada. Ou use a manutenção de autoatendimento para aplicar a manutenção de atualização mais recente.

O que acontece se a instância for interrompida durante a atualização de manutenção programada?

Quando uma instância é interrompida durante a atualização de manutenção programada, o Cloud SQL ignora a atualização de manutenção. No entanto, na próxima reiniciação da instância, o Cloud SQL a atualiza automaticamente com a atualização de manutenção mais recente.

Quanto tempo a manutenção de autoatendimento leva para todas as réplicas de leitura de uma instância principal?

O tempo que uma atualização de manutenção de autoatendimento leva depende do número total de réplicas de leitura da sua instância principal. Para reduzir o tempo que a atualização de manutenção de autoatendimento pode levar, atualize algumas réplicas de leitura individualmente e realize a atualização na instância principal para atualizar o restante das réplicas de leitura.

A segunda atualização ignora todas as réplicas que já tenham a versão de manutenção de destino.

Se eu tiver várias réplicas de leitura da minha instância principal, posso fazer a manutenção de autoatendimento em uma única réplica de leitura?

Sim, é possível executar a manutenção de autoatendimento em uma instância de réplica de leitura individual. No entanto, recomendamos que você atualize o restante das réplicas de leitura e da instância principal para a mesma versão de manutenção logo depois. Recomendamos que você opere todas as réplicas de leitura e a instância principal com uma versão de manutenção idêntica.

A seguir