Este documento descreve os upgrades in-loco da versão principal 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.
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 os dados para um novo cluster do AlloyDB.
Para mais informações, consulte Políticas de versão do banco de dados.
Os upgrades no local da versão principal são uma maneira eficiente de fazer upgrade da versão principal do cluster pelos seguintes motivos:
- O AlloyDB retém detalhes do cluster e da instância, além de configurações do banco de dados, como nome da instância, endereço IP e 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 (principal e pool de leitura) são atualizadas como parte da mesma operação.
Fluxo de trabalho de upgrade da versão principal no local
Quando você inicia um upgrade no cluster, o AlloyDB realiza as seguintes ações:
- Executa verificações pré-upgrade para encontrar incompatibilidades que podem afetar o upgrade.
- Prepara para o upgrade da versão principal, que inclui a criação de um clone interno do cluster.
- Torna a instância principal indisponível. O intervalo começa. As leituras ainda podem ser feitas usando pools de leitura.
- Inicia um backup pré-upgrade.
- Faz upgrade da instância principal.
- Torna as instâncias do pool de leitura indisponíveis.
- Torna a instância principal disponível. O tempo de inatividade termina.
- Inicia um backup pós-upgrade.
- Faz upgrade das instâncias do pool de leitura.
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 levam aproximadamente 10 minutos por terabyte de dados.
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 será iniciado. A instância principal fica indisponível para leitura e gravação até que seja atualizada. O tempo de inatividade esperado é de 20 minutos a uma hora e depende principalmente do esquema do banco de dados e do número de objetos.
Depois que a instância principal é atualizada, as instâncias do pool de leitura ficam indisponíveis. As tentativas de upgrade são feitas em todas as instâncias do pool de leitura simultaneamente. O tempo de inatividade deve durar aproximadamente 20 minutos.
Se o upgrade da versão principal falhar em qualquer etapa antes da atualização da instância principal, o AlloyDB vai reverter automaticamente todas as mudanças.
Depois que a instância principal é atualizada, a versão do cluster também é atualizada para a versão de destino, e nenhum rollback é acionado por falhas 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. Nessas situações, entre em contato com o suporte da CLI do Google Cloud.
A tabela a seguir mostra uma estimativa aproximada do tempo necessário para concluir o upgrade em clusters de diferentes tamanhos de banco de dados:
| Tamanho do banco de dados | Pré-upgrade (sem inatividade) | Inatividade principal | Tempo de inatividade do pool de leitura | Duração total |
|---|---|---|---|---|
| 100 GB | ~15 minutos | ~20 minutos | ~20 minutos | Aproximadamente 1 hora |
| 1 TB | Cerca de 30 minutos | ~20 minutos | ~20 minutos | ~1 hora e 15 minutos |
| 4 TB | Aproximadamente 1 hora | ~20 minutos | ~20 minutos | ~1 hora e 45 minutos |
| 16 TB | Aproximadamente 3 horas | ~20 minutos | ~20 minutos | ~3 horas e 45 minutos |
| 32 TB | Aproximadamente 5 horas e 30 minutos | ~20 minutos | ~20 minutos | ~6 horas e 15 minutos |
| 64 TB | Cerca de 11 horas | ~20 minutos | ~20 minutos | Cerca de 12 horas |
| 128 TB | Cerca de 21 horas e 30 minutos | ~20 minutos | ~20 minutos | ~22 horas e 15 minutos |
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 da versão principal do banco de dados no local enquanto ela está em andamento.
O processo de upgrade inclui as seguintes etapas:
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(somente em caso de falha antes dos upgrades do pool de leitura)CLEANUP
Os possíveis estados dessas etapas incluem:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Cancelamentos de upgrade
É possível cancelar a operação de upgrade até um determinado ponto durante o upgrade da instância principal. Depois desse ponto, não é possível cancelar um upgrade.
No console 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 você pode cancelar o upgrade verificando
upgradeClusterStatus no status do upgrade:
- Se
cancellablefortrue, você poderá cancelar o upgrade. - Se
cancellableforfalseou estiver ausente no status, não será possível cancelar o upgrade.
Backups automáticos antes e depois do upgrade
Quando você faz 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. O 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 depois que a instância principal é
atualizada. O 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 mudaram 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. Para mais informações, consulte Visão geral do backup e da recuperação de dados.
Quando você visualiza sua lista de backups, os backups de upgrade são listados com o tipo
CONTINUOUS. Para mais informações, consulte
Ver uma lista de backups.
Para fazer uma recuperação pontual (PITR), é necessário ter um backup de uma versão disponível. A recuperação não fica disponível no cluster atualizado até que o backup pós-upgrade ou outro backup iniciado após o upgrade da instância principal seja concluído.