Este documento descreve as atualizações da versão principal no local da base de dados do AlloyDB for PostgreSQL, que lhe permitem atualizar uma base de dados para uma versão superior sem migrar dados nem substituir a instância existente.
A comunidade PostgreSQL lança periodicamente novas versões principais que contêm novas funcionalidades, melhorias de desempenho e melhoramentos de segurança. Depois de o PostgreSQL lançar uma nova versão principal, o AlloyDB adiciona suporte para a versão compatível. Para manter a base de dados atualizada, pode atualizar o cluster do AlloyDB para uma versão principal superior. Pode atualizar o cluster através desta funcionalidade de atualização no local ou migrando os seus dados para um novo cluster do AlloyDB.
Para mais informações, consulte as políticas de versão da base de dados.
As atualizações da versão principal no local são uma forma eficiente de atualizar a versão principal do cluster pelos seguintes motivos:
- O AlloyDB retém os detalhes do cluster e da instância, bem como as definições da base de dados, como o nome da instância, o endereço IP e os indicadores da base de dados, após a atualização.
- Não precisa de alterar as strings de ligação da aplicação.
- Todas as instâncias do cluster (principal e conjunto de leitura) são atualizadas como parte da mesma operação.
Fluxo de trabalho de atualização da versão principal no local
Quando inicia uma atualização no cluster, o AlloyDB realiza as seguintes ações:
- Executa verificações pré-atualização para encontrar incompatibilidades que podem afetar a atualização.
- Prepara-se para a atualização da versão principal, que inclui a criação de um clone interno do cluster.
- Torna a instância principal indisponível. O período de descanso começa. As leituras continuam a poder ser feitas através de conjuntos de leitura.
- Inicia uma cópia de segurança pré-atualização.
- Atualiza a instância principal.
- Torna as instâncias do conjunto de leitura indisponíveis.
- Torna a instância principal disponível. O período de descanso termina.
- Inicia uma cópia de segurança após a atualização.
- As atualizações leem instâncias do conjunto.
Depois de as verificações pré-atualização serem aprovadas, o cluster é clonado para um cluster interno no mesmo projeto. A cópia de segurança e o restauro necessários para clonar o cluster demoram aproximadamente 10 minutos por terabyte de dados.
Durante a operação de clonagem, pode continuar a usar o cluster original. Após a conclusão da operação de clonagem, o processo de atualização é iniciado. A instância principal não está disponível para leituras nem escritas até ser atualizada. Normalmente, o tempo de inatividade esperado é de 20 minutos a 1 hora e depende principalmente do esquema da base de dados e do número de objetos.
Depois de atualizar a instância principal, as instâncias do conjunto de leitura ficam indisponíveis. As atualizações são tentadas em todas as instâncias do conjunto de leitura em simultâneo. A indisponibilidade deve durar aproximadamente 20 minutos.
Se a atualização da versão principal falhar em qualquer passo antes da atualização da instância principal, o AlloyDB reverte automaticamente todas as alterações.
Após a atualização da instância principal, a versão do cluster é atualizada para a versão de destino e não são acionadas reversões em caso de falha após este ponto. Por exemplo, o AlloyDB não reverte o cluster se uma ou mais atualizações de instâncias do conjunto de leitura falharem. Nestas situações, contacte o apoio técnico da CLI Google Cloud.
A tabela seguinte apresenta uma estimativa aproximada do tempo necessário para a conclusão da atualização para clusters de diferentes tamanhos de base de dados:
| Tamanho da base de dados | Pré-atualização (sem período de descanso) | Tempo de inatividade principal | Ler período de descanso da piscina | Duração total |
|---|---|---|---|---|
| 100 GB | Cerca de 15 minutos | Cerca de 20 minutos | Cerca de 20 minutos | ~1 hora |
| 1 TB | ~30 minutos | Cerca de 20 minutos | Cerca de 20 minutos | Cerca de 1 hora e 15 minutos |
| 4 TB | ~1 hora | Cerca de 20 minutos | Cerca de 20 minutos | ~1 hora e 45 minutos |
| 16 TB | Cerca de 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 | Cerca de 6 horas e 15 minutos |
| 64 TB | ~11 horas | Cerca de 20 minutos | Cerca de 20 minutos | ~12 horas |
| 128 TB | ~21 horas e 30 minutos | Cerca de 20 minutos | Cerca de 20 minutos | Cerca de 22 horas e 15 minutos |
Para mais informações, consulte o artigo Atualize uma versão principal no local de uma base de dados.
Estado da atualização
Pode monitorizar o estado de uma operação de atualização da versão principal da base de dados no local enquanto está em curso.
O processo de atualização inclui as seguintes fases:
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(apenas em caso de falha antes das atualizações do conjunto de leitura)CLEANUP
Os estados possíveis destas fases incluem o seguinte:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Cancelamentos de atualizações
Pode cancelar a operação de atualização até um determinado ponto durante a atualização da instância principal. Quando esse ponto é ultrapassado, não pode cancelar uma atualização.
Na Google Cloud consola, a operação não é cancelável se o botão
Cancelar atualização estiver esbatido. Através da CLI Google Cloud ou da API REST, pode determinar se pode cancelar a atualização verificando upgradeClusterStatus no estado da atualização:
- Se o
cancellableestivertrue, pode cancelar a atualização. - Se
cancellableforfalseou estiver em falta no estado, não pode cancelar a atualização.
Cópias de segurança automáticas antes e depois da atualização
Quando faz uma atualização da versão principal, o AlloyDB cria automaticamente as seguintes cópias de segurança contínuas, em que XX é a versão principal de origem e YY é a versão principal de destino.
- A cópia de segurança pré-atualização é criada imediatamente antes do início da atualização. Esta cópia de segurança tem o nome no formato
pre-upgrade-bkp-pgXX-pgYY-<uuid>. Pode usar esta cópia de segurança para restaurar o estado anterior à atualização. Tenha em atenção que o restauro não é uma operação no local e que cria um novo cluster. - A cópia de segurança pós-atualização é criada após a atualização da instância principal. Esta cópia de segurança tem o nome no formato
post-upgrade-bkp-pgXX-pgYY-<uuid>.
Uma cópia de segurança contínua é incremental, o que significa que a cópia de segurança armazena apenas os dados que foram alterados em relação à cópia de segurança contínua anterior. Esta abordagem reduz o tamanho e o custo (em recursos) da cópia de segurança e acelera o processo de criação da mesma. Para mais informações, consulte o artigo Vista geral da cópia de segurança e recuperação de dados.
Quando vê a sua lista de cópias de segurança, as cópias de segurança da atualização são apresentadas com o tipo
CONTINUOUS. Para mais informações, consulte o artigo
Veja uma lista de cópias de segurança.
A execução da recuperação pontual (PITR) requer que esteja disponível uma cópia de segurança de uma versão. A recuperação não está disponível no cluster atualizado até que a cópia de segurança pós-atualização ou outra cópia de segurança iniciada após a atualização da instância principal seja concluída.