Atualizações de manutenção em instâncias do Cloud SQL

Esta página explica como ocorrem as atualizações de manutenção em instâncias do Cloud SQL e como pode controlar o momento destas atualizações. Para começar, consulte o artigo Veja e defina janelas de manutenção.

Vista geral

Como serviço gerido, o Cloud SQL atualiza automaticamente as instâncias para garantir que o hardware, o sistema operativo e o motor de base de dados subjacentes são fiáveis, têm um bom desempenho, são seguros e estão atualizados. A maioria destas atualizações é realizada enquanto a sua instância do Cloud SQL está em funcionamento. No entanto, determinadas atualizações do sistema requerem uma breve interrupção do serviço. Estas atualizações são denominadas manutenção.

A manutenção atualiza o motor da base de dados e, em alguns casos, o sistema operativo. Uma vez que estas atualizações requerem o reinício da instância, incorrem em algum tempo de inatividade. As atualizações de manutenção oferecem as seguintes vantagens:

  • Funcionalidades do Cloud SQL. Para lançar novas funcionalidades, o motor da base de dados é atualizado e são instalados novos plug-ins na base de dados.

  • Atualizações da versão da base de dados. O fornecedor de software de base de dados que desenvolve o PostgreSQL lança novas versões secundárias várias vezes por ano. Cada nova versão inclui correções de erros, patches de segurança, melhorias de desempenho e novas funcionalidades da base de dados. Pode encontrar a versão secundária mais recente suportada pelo Cloud SQL para PostgreSQL consultando as notas de lançamento ou as versões de base de dados e as políticas de versões. As instâncias do Cloud SQL são atualizadas para a versão mais recente da base de dados pouco tempo após o lançamento, para que possa beneficiar da execução do software de base de dados mais recente.

  • Patches do sistema operativo. Monitorizamos continuamente novas vulnerabilidades de segurança identificadas no sistema operativo. Após a deteção, aplicamos patches ao sistema operativo para proteger o seu dispositivo contra novos riscos.

Impacto da manutenção

Para a edição Cloud SQL Enterprise Plus, o Cloud SQL oferece manutenção planeada com tempo de inatividade quase nulo.

Normalmente, o Cloud SQL agenda um evento de atualização de manutenção uma vez a cada poucos meses. A atualização de manutenção pode demorar aproximadamente 5 a 10 minutos para cada instância. Se a instância tiver réplicas de leitura, a duração geral da atualização de manutenção pode demorar mais tempo. No entanto, durante o evento de atualização de manutenção, cada instância da edição Enterprise do Cloud SQL perde a conetividade durante menos de 30 segundos, em média. O tempo de inatividade pode ser superior para uma instância que esteja a sofrer grandes quantidades de atividade durante o evento de atualização de manutenção ou que tenha um conjunto de dados muito grande.

Pode tomar medidas para garantir que a manutenção tem o menor impacto possível nas suas operações através das nossas definições de manutenção e tornando os seus sistemas resilientes a erros transitórios.

Manutenção planeada com um período de descanso quase nulo

Com a manutenção planeada com tempo de inatividade quase nulo, as instâncias da edição Cloud SQL Enterprise Plus perdem normalmente a conetividade durante menos de 1 segundo durante a manutenção planeada.

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

Pré-requisitos e restrições

  • O número de réplicas de leitura nas suas instâncias da edição Enterprise Plus do Cloud SQL para PostgreSQL tem de ser inferior ao valor definido para os flags max_wal_senders e max_replication_slots. Para mais informações, consulte o artigo configure flags da base de dados.

  • Se estiver a usar o proxy Auth do Cloud SQL ou os conetores de linguagem do Cloud SQL, certifique-se de que estão atualizados para a versão mais recente.

  • Todas as tabelas não registadas ficam vazias após a manutenção planeada.

  • Durante a manutenção, os registos da base de dados têm mensagens de duas VMs diferentes.
  • Se for emitido um DDL durante a manutenção planeada, as alterações podem ter uma indicação de tempo de criação ou modificação posterior à indicação de tempo de manutenção.
  • As strings de ligação e as definições de consulta do lado do cliente, como o tipo de ligação, os limites de tempo das consultas e o agrupamento de ligações, podem afetar o tempo de inatividade observado. Certifique-se de que testa a configuração da sua aplicação para encontrar as definições que melhor se adequam às suas necessidades.

Simule a manutenção planeada com um período de descanso quase nulo

Para testar o tempo de inatividade da manutenção planeada da sua instância principal do Cloud SQL Enterprise Plus edition sem atualizar a instância da base de dados, pode simular a manutenção planeada com um tempo de inatividade quase nulo.

Para o fazer, invoque a simulação de um evento de manutenção numa instância da edição Cloud SQL Enterprise Plus elegível para manutenção planeada com tempo de inatividade quase nulo. O pedido de simulação resulta numa operação de atualização da instância para a mesma versão de manutenção antes da operação.

Pode fazer a simulação mesmo que tenha uma atualização de manutenção pendente na instância. A versão da instância permanece a mesma durante toda a simulação.

Para simular um evento de manutenção planeada com tempo de inatividade quase nulo, use o seguinte comando da CLI gcloud:

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

Substitua INSTANCE_NAME pelo nome da instância onde quer executar o evento de manutenção simulado.

Definições de manutenção

O Cloud SQL oferece-lhe a capacidade de configurar atualizações de manutenção através de um conjunto de definições de manutenção.

Pode configurar a manutenção para ser agendada em alturas em que a breve indisponibilidade causa o menor impacto nas suas aplicações. Para cada instância do Cloud SQL, pode configurar o seguinte:

  • Tempo de manutenção (anteriormente Ordem de atualização). A semana do período de implementação para atualizar a sua instância do Cloud SQL. Tem as seguintes opções:

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

    Define o horário da atualização de manutenção quando configura um período de manutenção.

  • Período de manutenção. O dia da semana e a hora em que o Cloud SQL agenda a manutenção. Os períodos de manutenção duram uma hora. Saiba como configurar um período de manutenção.

  • Período de negação de manutenção. Um bloco de dias em que o Cloud SQL não agenda manutenção. Pode definir um período de manutenção de recusa com uma duração máxima de 90 dias. Saiba como configurar um período de manutenção de recusa.

Períodos de manutenção predefinidos

Se não definir um período de manutenção, o Cloud SQL atualiza a sua instância nos seguintes períodos predefinidos, de acordo com o fuso horário da instância:

  • Janela de dias úteis (segunda a sexta-feira): das 22:00 às 06:00
  • Período do fim de semana: de sexta-feira, às 22:00, a segunda-feira, às 06:00

Exemplo de manutenção

Suponha que é um programador de um retalhista que gere um serviço de carrinho de compras. Tem uma instância do Cloud SQL para um ambiente de produção e uma segunda para um ambiente de teste. Quer que a manutenção seja realizada na altura em que a sua instância processa a menor quantidade de tráfego, que é por volta da meia-noite aos domingos. Também quer evitar a manutenção durante a época festiva de compras de fim de ano.

Neste caso, defina as definições de manutenção da instância de produção para:

  • Período de manutenção: domingos entre as 00:00 e as 01:00 (Hora do Leste)
  • Tempo de manutenção: Week 2
  • Período de manutenção recusado: de 1 de novembro a 15 de janeiro.

As definições de manutenção do seu ambiente de teste seriam idênticas, exceto que a hora de manutenção está definida como Week 2. Isto garante que pode executar testes de aceitação operacional para um lançamento de manutenção na preparação, pelo menos, sete dias antes de a manutenção ser implementada na produção. Se algo correr mal no ambiente de teste, tem tempo para diagnosticar e corrigir o problema ou configurar um período de manutenção recusado para que o ambiente de produção não seja afetado.

Notificações de manutenção futuras

Pode receber uma notificação sobre a manutenção futura enviada para o seu email, pelo menos, uma semana antes da manutenção agendada. Se quiser definir um filtro de email para notificações, o título do email é Manutenção futura da sua instância do Cloud SQL instancename.

Por predefinição, as notificações de manutenção não são enviadas. Tem de ativar as notificações de manutenção. Antes de poder receber notificações, também tem de selecionar um período de manutenção.

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

Ativa as notificações de manutenção para todas as instâncias do Cloud SQL que tenham períodos de manutenção num determinado projeto. Recebe uma notificação por instância. As notificações de manutenção futuras não são enviadas para réplicas de leitura.

Também pode ver as informações de manutenção futuras na Google Cloud consola.

  • Na lista Instâncias, na coluna Manutenção. Se a manutenção estiver agendada, vê a data e a hora em que está agendada para começar. Pode filtrar a lista de instâncias usando o termo Manutenção para encontrar todas as instâncias agendadas para manutenção. A coluna Manutenção só é apresentada quando a manutenção está agendada em uma ou mais instâncias no projeto. Se não estiver agendada nenhuma manutenção, a coluna fica oculta.
  • Na página Detalhes da instância no painel Manutenção. Se a manutenção estiver agendada, em Próximas, é apresentada uma data e uma hora para o início agendado.

  • Na página Explorador de registos na Google Cloud consola. Use o menu pendente Nome de todos os registos para pesquisar maintenance-events e, de seguida, clique em Aplicar. Se for agendada manutenção para uma instância, o registo mostra o nome da instância e a hora de início da manutenção agendada.

Outras notificações de manutenção

Quando ativa a opção para receber notificações de manutenção, recebe notificações de determinados eventos:

  • Manutenção agendada futura
  • Manutenção iniciada
  • Manutenção concluída
  • Manutenção cancelada

Reagendar manutenção

Se tiver um período de manutenção para a sua instância, pode reagendar a atualização de manutenção até 24 horas antes da data agendada. Por exemplo, se estiver a lançar um novo serviço durante o período de manutenção agendado, é recomendável adiar a atualização de manutenção para alguns dias após o lançamento.

Existem alguns limites para o reagendamento de atualizações de manutenção. Depois de o Cloud SQL enviar o email de notificação, o Cloud SQL faz a atualização de manutenção no prazo de sete semanas para evitar qualquer sobreposição com a atualização de manutenção seguinte do Cloud SQL. Por exemplo, se selecionar um momento de manutenção da semana 1 ou da semana 2, pode reagendar a atualização de manutenção até um máximo de 4 semanas (28 dias) após a data originalmente agendada. Se definir a sua instância para uma manutenção na 5.ª semana, só pode reagendar o evento de manutenção até um máximo de uma semana (7 dias) após a data original. Pode reagendar a manutenção várias vezes, desde que o evento de manutenção reagendado esteja dentro da duração do reagendamento definida pela data/hora de manutenção que configurou para a sua instância.

Para todas as outras limitações, consulte o artigo Limitações de reagendamento.

Tem algumas opções de agendamento para o novo período de manutenção:

  • Aplique as atualizações imediatamente. Pode aplicar a atualização à sua instância imediatamente em vez de aguardar pela janela de manutenção agendada. Neste caso, a manutenção começa geralmente no prazo de cinco minutos.

  • Reagendar para outra hora. Pode adiar um evento de manutenção agendado de duas formas:

    • Próxima janela disponível. Esta opção transfere a manutenção para a próxima janela de manutenção disponível após a hora de manutenção agendada atual, que é normalmente uma semana depois.
    • Hora específica. Esta opção permite-lhe escolher uma hora específica para a duração do reagendamento definida pela hora de manutenção que configurou para a sua instância.
      • 28 dias se selecionar o período de manutenção da semana 1 ou da semana 2
      • 7 dias se selecionar o momento de manutenção da 5.ª semana

Para ver instruções sobre como reagendar a manutenção, consulte o artigo Reagende a manutenção planeada.

Como funciona a manutenção

Para manter a manutenção breve, o Cloud SQL usa um fluxo de trabalho de comutação por falha de manutenção que se assemelha muito ao nosso fluxo de trabalho de comutação por falha automática para instâncias de elevada disponibilidade.

Resumidamente, estes são os passos:

  1. Configure uma VM atualizada com o novo software.
  2. Pare a base de dados na VM original.
  3. Mude o disco e o IP estático para a VM atualizada.
  4. Inicie a base de dados na VM atualizada.

Percorra os seguintes separadores para ver os detalhes do fluxo de trabalho, incluindo a pré-manutenção e a pós-manutenção.

Pré-manutenção

Antes da manutenção, o cliente comunica com a VM original através de um endereço IP estático. Os dados são armazenados num disco persistente que está associado à VM original. Neste exemplo, a instância do Cloud SQL tem a alta disponibilidade configurada, o que significa que outra VM está em espera para assumir o controlo em caso de uma indisponibilidade não planeada. A instância do Cloud SQL está a servir tráfego para a aplicação.

Diagrama que mostra o estado antes da manutenção

Passo 1

Configure a nova VM.

uma nova máquina virtual (VM) é configurada com o software de base de dados mais recente e o sistema operativo (SO) da VM. O SO da VM atualizado é iniciado. Neste ponto, o motor da base de dados ainda não foi iniciado. Para instâncias de alta disponibilidade, também é configurada uma nova VM em espera.

A inatividade total é substancialmente reduzida através da instalação da atualização de software noutra VM enquanto a instância original do Cloud SQL continua a publicar tráfego.

Diagrama que mostra a configuração da VM

Passo 2

Pare a base de dados na VM original.

O motor da base de dados é encerrado para que o disco possa ser separado da VM original e anexado à VM atualizada. Antes de ser encerrado, o motor da base de dados aguarda alguns segundos para que as transações em curso sejam confirmadas e os pedidos das ligações existentes sejam esgotados. Depois disso, todas as transações abertas ou de longa duração são revertidas. A base de dados deixa de aceitar novas ligações e as ligações existentes são eliminadas. A instância fica indisponível e o período de descanso de manutenção começa.

Diagrama da instância após a comutação por falha

Passo 3

Mude para a VM atualizada.

O disco é desanexado da VM original e anexado à VM atualizada. O endereço IP estático é reconfigurado para apontar para a VM atualizada. Isto garante que a aplicação usa o mesmo endereço IP após a manutenção que antes. A cache da base de dados é substituída pela VM original, o que significa que a cache da base de dados é efetivamente limpa durante a manutenção.

Diagrama da mudança para a VM atualizada

Passo 4

Inicie a base de dados na VM atualizada.

O motor da base de dados atualizado é iniciado no disco de dados. A utilização de um disco de dados comum garante que todas as transações escritas na instância original antes da manutenção ainda estão presentes na base de dados atualizada após a manutenção. Se alguma transação incompleta não tiver terminado a reversão durante o encerramento da base de dados, a base de dados passa automaticamente pela recuperação de falhas para garantir que é restaurada para um estado utilizável.

Diagrama de início da VM atualizada

Pós-manutenção

Após o passo 4, a instância do Cloud SQL está disponível para aceitar ligações e volta a servir tráfego para a aplicação.

Para a aplicação, além do software atualizado, a instância do Cloud SQL tem o mesmo aspeto. A aplicação continua a estabelecer ligação à instância do Cloud SQL através do mesmo endereço IP estático, e a VM atualizada é executada na mesma zona que a VM original. Todos os dados escritos na base de dados original são preservados.

Diagrama de pós-manutenção

Minimize o impacto da manutenção

Em geral, Google Cloud recomenda que os utilizadores que executam aplicações na nuvem tornem os respetivos sistemas resilientes a erros transitórios, que são problemas momentâneos 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 ligações interrompidas e transações em curso falhadas. Se criar os seus sistemas e ajustar as suas aplicações para serem resilientes a erros transitórios, também está em posição de minimizar os impactos devido à manutenção da base de dados.

Para minimizar o impacto das ligações interrompidas, pode usar pools de ligações. Embora as ligações entre o agrupador e a base de dados sejam interrompidas durante a manutenção, as ligações entre a aplicação e o agrupador são preservadas. Desta forma, o trabalho de restabelecer as ligações é transparente para a aplicação e é transferido para o agrupador de ligações.

Para reduzir as falhas de transações, pode limitar o número de transações de longa duração. A reescrita de consultas para serem mais pequenas e eficientes não só reduz o tempo de inatividade de manutenção, como também melhora o desempenho e a fiabilidade da base de dados.

Pode usar as Estatísticas de consultas para identificar consultas lentas.

Para recuperar de forma eficiente de falhas de ligação e falhas de transações, pode gerir as ligações à base de dados de forma eficiente. Pode criar uma lógica de repetição de consultas e ligações com reversão exponencial nas suas aplicações e agrupadores de ligações. Caso uma consulta falhe ou uma ligação seja interrompida, o sistema institui um período de espera antes de tentar novamente, que aumenta para cada nova tentativa subsequente. Por exemplo, o sistema pode aguardar apenas alguns segundos para a primeira nova tentativa, mas até um minuto para a quarta nova tentativa. Seguir este padrão garante que estas falhas são corrigidas sem sobrecarregar o serviço.

Outras soluções criativas também podem minimizar os impactos da manutenção, desde a utilização de scripts para aquecer a cache da base de dados após a manutenção até à simplificação do número de tabelas nas bases de dados. Recomendamos que siga as práticas recomendadas de gestão de bases de dados e as diretrizes operacionais para garantir que a manutenção decorre sem problemas.

Manutenção sensível ao tempo

Em casos muito raros, o Cloud SQL pode ter de agendar a manutenção fora das suas definições de manutenção para corrigir problemas de estabilidade graves ou vulnerabilidades sensíveis ao tempo. Estas atualizações são fornecidas rapidamente e o Cloud SQL considera-as como tempo de inatividade em relação ao SLA.

Manutenção autónoma

O Cloud SQL lança regularmente melhorias de software e patches para vulnerabilidades de segurança através de novas versões de manutenção que pode instalar nas suas instâncias. O Cloud SQL mantém um registo de alterações da manutenção do Cloud SQL para cada versão principal do motor de base de dados. Para saber mais, consulte os registos de alterações da manutenção do Cloud SQL.

Embora o Cloud SQL agende atualizações de manutenção a cada poucos meses para garantir que tem o software mais recente, pode usar a manutenção autónoma para manter a sua instância atualizada se:

  • Precisa de uma atualização antes do próximo evento de manutenção agendado.
  • Quiser atualizar o software para a versão mais recente depois de ignorar a atualização de manutenção mais recente.

Se usar réplicas de leitura, pode usar a manutenção self-service para atualizar todas as réplicas de leitura. Especifica a instância principal e o pedido 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

Esta secção descreve as limitações da manutenção do Cloud SQL.

Limitações de reagendamento

Existem alguns aspetos que deve saber sobre o reagendamento:

  • Tem de reagendar a manutenção, pelo menos, 24 horas antes do evento de manutenção originalmente agendado.

  • Pode reagendar a manutenção numa ou em várias instâncias no seu projeto. No entanto, só pode reagendar uma instância de cada vez (o reagendamento em massa não está disponível).

  • Pode reagendar a manutenção para uma hora que se enquadre num período de manutenção recusado ou mesmo fora do período de manutenção, desde que a duração do reagendamento esteja dentro do período definido pela programação da manutenção que configurou para a sua instância.

  • Se estiver em curso uma operação de manutenção, o reagendamento é atrasado até a operação estar concluída.

Recuse limitações do período de manutenção

Existem alguns aspetos que deve saber acerca dos períodos de manutenção recusados:

  • A partir de 15 de agosto de 2025, não pode definir um período de manutenção recusado para uma instância se a respetiva versão de manutenção tiver mais de 12 meses. Qualquer instância que use uma versão de manutenção com mais de 12 meses tem de receber uma atualização. Para encontrar a data da versão de manutenção instalada na sua instância, use o comando gcloud sql instances describe ou veja a secção Manutenção da página Vista geral da instância na consolaGoogle Cloud . Para mais informações sobre como encontrar a versão de manutenção da sua instância, consulte o artigo Veja as informações da instância. Para determinar a data de lançamento, verifique o nome da versão de manutenção. Por exemplo, se o nome da versão de manutenção for POSTGRES_16_9.R20250302.00_31, a data de lançamento correspondente é 2 de março de 2025.

    Para atualizar a instância, faça a manutenção self-service ou aguarde pela atualização automática durante o próximo período de manutenção. Depois de atualizar a instância, pode definir um período de negação de manutenção.

  • Pode ter um período de recusa de manutenção, mesmo que não tenha períodos de manutenção configurados para a sua instância. Os períodos de recusa de manutenção podem variar entre 1 e 90 dias.

  • O período de manutenção recusado tem precedência sobre qualquer período de manutenção agendado. Se existir um conflito entre o momento de um período de manutenção e o período de manutenção recusado, o período de manutenção recusado substitui o período de manutenção.

  • A recusa de períodos de manutenção e a sincronização da manutenção são funcionalidades independentes. Se criar um período de negação de manutenção para uma instância com o horário de manutenção Week 1, não tem impacto na determinação da atualização agendada para uma instância com o horário de manutenção Week 2. Se uma atualização de manutenção agendada ocorrer num período de manutenção recusado, o Cloud SQL não envia uma notificação para as instâncias que configurou com o horário de manutenção.

  • Quando um período de recusa é definido numa instância principal, a manutenção de todas as réplicas associadas à instância principal também é recusada. Por exemplo, uma instância principal localizada na região A tem três réplicas de leitura: duas na região A e uma na região B. Quando é definido um período de recusa na instância principal, a manutenção de cada uma das réplicas, incluindo a réplica na região B, não recebe manutenção até o período de recusa na instância principal expirar.

  • Se for definido um período de negação de manutenção após a agendamento da manutenção, de modo que o período de negação de manutenção se sobreponha ao horário de manutenção agendado, a atualização é ignorada.

  • Pode definir o período de manutenção recusado para ocorrer todos os anos se não incluir o ano nos parâmetros de data de início e de conclusão. Se o ano for especificado, o período de manutenção de recusa é definido apenas para esse ano.

  • Pode definir vários períodos de manutenção recusados num ano. No entanto, não pode definir um período de manutenção recusado para uma instância que esteja a executar uma versão de manutenção com mais de 12 meses. Evite encadear períodos de recusa para ignorar eventos de manutenção agendada consecutivos. Manter-se a par da manutenção do Cloud SQL é importante para garantir que a sua instância funciona de forma fiável. Normalmente, a manutenção do Cloud SQL é agendada uma vez no período de alguns meses.

  • Para ajudar a garantir a fiabilidade do serviço, o Cloud SQL notifica os utilizadores com instâncias que executam versões de manutenção com mais de 12 meses que a próxima implementação de manutenção é necessária.

  • Quando um período de manutenção de recusa termina, o comportamento de manutenção normal é retomado.

  • Os períodos de manutenção recusados não afetam as operações acionadas pelo utilizador, como a manutenção self-service.

Perguntas frequentes sobre manutenção

O tempo de inatividade de manutenção conta para o SLA?

A inatividade devido à manutenção normal não é contabilizada para o SLA. No entanto, o Cloud SQL contabiliza o tempo de inatividade de manutenção sensível ao tempo em relação ao SLA.

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

  • O Cloud SQL mantém sempre as réplicas de leitura antes da instância principal. Se a instância principal tiver um período de manutenção, as réplicas de leitura observam o mesmo período de manutenção.
  • Se a sua instância principal tiver várias réplicas de leitura, o Cloud SQL pode atualizar algumas das réplicas em simultâneo.
  • As réplicas de leitura respeitam o período de manutenção recusado definido para a instância principal.

Posso cancelar a manutenção agendada?

Não pode cancelar uma janela de manutenção agendada, mas pode reagendá-la. Também pode configurar um período de manutenção recusado que se sobreponha à hora de manutenção agendada para ignorar eficazmente a manutenção.

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

Se o Cloud SQL cancelar um evento de manutenção, recebe uma notificação a informar que a manutenção foi cancelada com antecedência, quando possível.

Recebe uma nova notificação de manutenção futura quando o evento de manutenção for reagendado.

A manutenção do Cloud SQL é cumulativa?

As atualizações de manutenção são cumulativas. Não é necessário aplicar todas as atualizações de manutenção que possa ter perdido. A versão de manutenção mais recente é aplicada na próxima atualização de manutenção agendada. Em alternativa, pode aplicar a atualização de manutenção mais recente através da manutenção self-service.

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

Se uma instância for interrompida durante a atualização de manutenção agendada, o Cloud SQL ignora a atualização de manutenção. No entanto, da próxima vez que reiniciar a instância, o Cloud SQL atualiza-a automaticamente com a atualização de manutenção mais recente.

Quanto tempo demora a manutenção self-service para todas as réplicas de leitura de uma instância principal?

O tempo que uma atualização de manutenção autónoma demora 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 autosserviço pode demorar, pode atualizar algumas réplicas de leitura individualmente e, em seguida, fazer a atualização na instância principal para atualizar o resto 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 tiver várias réplicas de leitura da minha instância principal, posso fazer a manutenção self-service numa única réplica de leitura?

Sim, pode realizar a manutenção self-service numa instância de réplica de leitura individual. No entanto, recomendamos que atualize o resto das réplicas de leitura e a instância principal para a mesma versão de manutenção pouco depois. Recomendamos que opere todas as réplicas de leitura e a instância principal com uma versão de manutenção idêntica.

O que se segue?