Para adotar novos recursos do PostgreSQL, melhorias de desempenho e melhorias de segurança sem migrar dados ou alterar strings de conexão de aplicativos, é possível realizar um upgrade de versão principal no cluster do AlloyDB para PostgreSQL.
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 para a versão compatível. Para manter o 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 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, além das configurações do banco de dados, como o nome da instância, o endereço IP e as flags de 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 (pool principal e de leitura) são atualizadas como parte da mesma operação.
Além disso, as associações de papéis com concedentes inexistentes (associações órfãs) não são preservadas. Se algum cluster tiver assinaturas órfãs no catálogo pg_auth_members, elas serão perdidas após o upgrade. Para mais informações, consulte
Preparar o cluster para um upgrade de versão principal.
Fluxo de trabalho de upgrade de versão principal no local
Quando você inicia um upgrade no cluster, o AlloyDB executa as seguintes ações:
- Executa verificações pré-upgrade para encontrar incompatibilidades que podem afetar o upgrade.
- Prepara o upgrade da versão principal, o 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 por pools de leitura.
- Inicia um backup pré-upgrade.
- Faz upgrade da instância principal.
- Torna as instâncias do pool de leitura indisponíveis.
- Disponibiliza a instância principal. O intervalo 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, o 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 leituras e gravações até que o upgrade seja concluído. 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.
Depois que a instância principal é atualizada, as instâncias do pool de leitura ficam indisponíveis. Os upgrades são tentados em todas as instâncias do pool de leitura simultaneamente. A previsão é que o tempo de inatividade dure cerca de 20 minutos.
Se o upgrade da versão principal falhar em qualquer etapa antes do upgrade da instância principal, o AlloyDB vai reverter automaticamente todas as alterações.
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ância do pool de leitura falharem. Nessas situações, entre em contato com o Google Cloud suporte.
A tabela a seguir mostra uma estimativa aproximada do tempo necessário para que o upgrade seja concluído 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 | Cerca de 20 minutos | Cerca de 20 minutos | Aproximadamente 1 hora |
| 1 TB | Cerca de 30 minutos | Cerca de 20 minutos | Cerca de 20 minutos | ~1 hora e 15 minutos |
| 4 TB | Aproximadamente 1 hora | Cerca de 20 minutos | Cerca de 20 minutos | ~1 hora e 45 minutos |
| 16 TB | Aproximadamente 3 horas | Cerca de 20 minutos | Cerca de 20 minutos | ~3 horas e 45 minutos |
| 32 TB | ~5 horas e 30 minutos | Cerca de 20 minutos | Cerca de 20 minutos | ~6 horas e 15 minutos |
| 64 TB | Cerca de 11 horas | Cerca de 20 minutos | Cerca de 20 minutos | Cerca de 12 horas |
| 128 TB | ~21 horas e 30 minutos | Cerca de 20 minutos | Cerca de 20 minutos | ~22 horas e 15 minutos |
Para mais informações, consulte Fazer upgrade de uma versão principal do 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_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(somente em caso de falha antes dos upgrades do pool de leitura)CLEANUP
Os estados possíveis desses estágios 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 que esse ponto é ultrapassado, não é possível cancelar um upgrade.
No console do Google Cloud , a operação não poderá 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
cancellablefortrue, será possível 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. Esse backup é nomeado usando o formato
pre-upgrade-bkp-pgXX-pgYY-<uuid>. Use esse backup para restaurar o estado anterior ao 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. 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 de backup. Para mais informações, consulte Visão geral de backup e 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 realizar 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 o upgrade da instância principal seja concluído.