Visão geral do upgrade da versão principal do banco de dados no local

Visualização — AlloyDB for PostgreSQL

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. É possível processar dados pessoais para esse recurso conforme descrito no Adendo sobre processamento de dados do Cloud, sujeito às obrigações e restrições descritas no contrato em que você acessa o Google Cloud. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Este documento descreve os upgrades de versão principal no local do banco de dados do AlloyDB para PostgreSQL, que permitem fazer upgrade de um banco de dados para uma versão mais recente sem migrar dados ou substituir a instância atual.

Observação: o recurso de upgrade de versão principal no local do AlloyDB só oferece suporte ao upgrade do cluster do PostgreSQL 14 para o PostgreSQL 15.

A comunidade do PostgreSQL lança periodicamente novas versões principais que contêm novos recursos, melhorias de desempenho e melhorias de segurança. Depois que o PostgreSQL lança uma nova versão principal, o AlloyDB adiciona suporte à versão compatível. Para manter seu banco de dados atualizado, faça upgrade do cluster do AlloyDB para uma versão principal mais recente. É possível fazer upgrade do cluster usando esse recurso de upgrade no local ou migrando seus dados para um novo cluster do AlloyDB.

Para mais informações, consulte as políticas de versão do banco de dados.

Os upgrades de versão principal no local são uma maneira eficiente de fazer upgrade da versão principal do cluster pelos seguintes motivos:

• O AlloyDB mantém os detalhes do cluster e da instância e as configurações do banco de dados, como o nome da instância, o endereço IP e as flags do banco de dados, após o upgrade.
• Não é necessário mudar as strings de conexão do aplicativo.
• Todas as instâncias do cluster (primário e pool de leitura) são atualizadas como parte da mesma operação.

Observação: para verificar o processo de upgrade e verificar incompatibilidades, recomendamos que você verifique o processo de upgrade em um cluster clonado antes de fazer upgrade do cluster real.

Fluxo de trabalho de upgrade da versão principal no local

Quando você inicia um upgrade no cluster, o AlloyDB executa as seguintes ações:

1. Executa verificações pré-upgrade para encontrar incompatibilidades que podem afetar o upgrade.
2. Prepara-se para o upgrade da versão principal, que inclui a criação de um clone interno do cluster.
3. Torna a instância principal indisponível. O intervalo começa. As leituras ainda podem ser feitas por pools de leitura.
4. Inicia um backup pré-upgrade.
5. Faz upgrade da instância principal.
6. Torna as instâncias do pool de leitura indisponíveis.
7. Disponibiliza a instância principal. O intervalo termina.
8. Inicia um backup pós-upgrade.
9. Faz upgrade de instâncias do pool de leitura.

Observação: ao realizar um upgrade de versão principal no local, os valores padrão específicos da versão das flags do banco de dados podem mudar. Para mais informações, consulte Configurar flags de banco de dados de uma instância.

Depois que as verificações de pré-upgrade forem aprovadas, seu cluster será clonado para um cluster interno no mesmo projeto. O backup e a restauração necessários para clonar o cluster podem demorar para serem concluídos, dependendo do tamanho do banco de dados. Confira a seguir exemplos de tamanho do banco de dados e durações de backup e restauração correspondentes:

• O cluster de 1 TB leva cerca de 30 minutos para ser clonado.
• 10 TB leva cerca de 2 horas para clonar seu cluster.

Durante a operação de clonagem, você pode continuar usando o cluster original. Depois que a operação de clonagem for concluída, o processo de upgrade vai começar. A instância principal fica indisponível para leituras e gravações até que seja atualizada. O tempo de inatividade esperado é geralmente de 20 minutos a uma hora e depende principalmente do esquema do banco de dados e do número de objetos.

Observação: é possível continuar usando as instâncias do pool de leitura enquanto a instância principal está sendo atualizada.

Se o upgrade da versão principal falhar em qualquer etapa antes que a instância principal seja atualizada, o AlloyDB vai reverter automaticamente todas as mudanças.

Depois que a instância principal é atualizada, a versão do cluster é atualizada para a versão de destino, e nenhuma reversão é acionada para qualquer falha após esse ponto. Por exemplo, o AlloyDB não reverter o cluster se um ou mais upgrades de instâncias do pool de leitura falharem. Nesses casos, entre em contato com o suporte da CLI do Google Cloud.

Para mais informações, consulte Fazer upgrade da versão principal de um banco de dados no local.

Status do upgrade

É possível monitorar o status de uma operação de upgrade de versão principal do banco de dados no local enquanto ela está em andamento.

O processo de upgrade inclui as seguintes etapas:

• ALLOYDB_PRECHECK
• PG_UPGRADE_CHECK
• PREPARE_FOR_UPGRADE
• PRIMARY_INSTANCE_UPGRADE
• READ_POOL_INSTANCES_UPGRADE
• ROLLBACK(somente em caso de falha antes dos upgrades do pool de leitura)
• CLEANUP

Os possíveis estados desses estágios incluem:

• NOT_STARTED
• IN_PROGRESS
• SUCCESS
• FAILED
• CANCEL_IN_PROGRESS
• CANCELLED

Cancelamentos de upgrade

É possível cancelar a operação de upgrade até certo ponto durante o upgrade da instância principal. Depois que esse ponto é atingido, não é possível cancelar um upgrade.

No console do Google Cloud, a operação não pode ser cancelada se o botão Cancelar upgrade estiver esmaecido. Usando a Google Cloud CLI ou a API REST, é possível determinar se é possível cancelar o upgrade verificando upgradeClusterStatus no status do upgrade:

• Se cancellable for true, você poderá cancelar o upgrade.
• Se cancellable for false ou estiver ausente no status, não será possível cancelar o upgrade.

Backups automáticos antes e depois do upgrade

Quando você realiza um upgrade de versão principal, o AlloyDB cria automaticamente os seguintes backups contínuos, em que XX é a versão principal de origem e YY é a versão principal de destino.

• O backup pré-upgrade é criado imediatamente antes do início do upgrade. Esse backup é nomeado usando o formato pre-upgrade-bkp-pgXX-pgYY-<uuid>. Você pode usar esse backup para restaurar o estado pré-upgrade. A restauração não é uma operação no local e cria um novo cluster.
• O backup pós-upgrade é criado após a atualização da instância principal. Esse backup é nomeado usando o formato post-upgrade-bkp-pgXX-pgYY-<uuid>.

Um backup contínuo é incremental, o que significa que ele armazena apenas os dados que foram alterados em relação ao backup contínuo anterior. Essa abordagem reduz o tamanho e o custo (em recursos) do backup e acelera o processo de criação dele. Para mais informações, consulte Visão geral do backup e da recuperação de dados.

Quando você acessa a lista de backups, os backups de upgrade são listados com o tipo CONTINUOUS. Para mais informações, consulte Conferir uma lista de backups.

Para executar a recuperação pontual (PITR, na sigla em inglês), é necessário que um backup de uma versão esteja disponível. A recuperação não estará disponível no cluster atualizado até que o backup pós-upgrade ou outro backup iniciado após a atualização da instância principal seja concluído.

A seguir

• Fazer upgrade da versão principal de um banco de dados no local.