Esta página foi traduzida pela API Cloud Translation.

Atualize a versão principal do servidor de um cluster

Esta página detalha o processo do AlloyDB for PostgreSQL para atualizar as versões do servidor de base de dados e explica como migrar os seus dados para um cluster compatível com uma versão posterior do PostgreSQL.

Para mais informações sobre como criar um cluster, consulte o artigo Crie um cluster e a respetiva instância principal.

Compatibilidade dos clusters e da versão do PostgreSQL

Quando cria um cluster do AlloyDB, escolhe a versão principal do PostgreSQL compatível com as instâncias no cluster. Por predefinição, este valor é 16.

O AlloyDB realiza atualizações automáticas da versão secundária da base de dados durante a manutenção periódica. Por exemplo, se criou um cluster com compatibilidade com a versão 16, o AlloyDB mantém os servidores de base de dados atualizados para a versão secundária mais recente da versão 16.

No entanto, uma atualização da versão principal da versão do PostgreSQL requer que planeie, teste e execute a atualização por si.

Existem vários métodos para fazer atualizações de versões principais do cluster:

Uma atualização da versão principal no local que recomendamos que use.
Migrar os dados com uma exportação de dados baseada em ficheiros.
Usando o Database Migration Service.

Cada solução de atualização oferece diferentes vantagens e desvantagens. Consulte a tabela seguinte para uma breve comparação que lhe ajude a escolher a abordagem certa para o seu cenário.

Atualização da versão principal no local	Exportação de dados baseada em ficheiros	Migração com o Database Migration Service
O seu cluster, incluindo as instâncias de leitura, é atualizado para a versão principal superior escolhida.	As exportações baseadas em ficheiros movem um instantâneo único das suas bases de dados.	O Database Migration Service oferece capacidades de replicação contínua durante o processo de migração, o que reduz a probabilidade de faltarem dados no novo cluster.
Pode continuar a trabalhar no cluster durante a fase de pré-atualização.	A sua aplicação sofre um tempo de inatividade mais longo que começa quando exporta os dados. Não pode aceitar gravações na base de dados no cluster original até que o novo cluster esteja totalmente operacional.	A sua aplicação sofre um tempo de inatividade mais curto que começa quando quer mudar a aplicação para usar o novo cluster.
Pode esperar uma indisponibilidade de aproximadamente 20 minutos ou mais durante o processo de atualização, consoante o seu esquema. Após a atualização, pode aceder ao cluster com o mesmo endereço IP.	Tem um controlo mais detalhado sobre os dados a incluir na exportação e pode optar por não migrar determinadas tabelas ou outras entidades.	O serviço de migração de bases de dados migra automaticamente todas as bases de dados presentes nas suas instâncias e todas as instâncias no seu cluster. Não pode optar por excluir determinadas tabelas ou vistas dos dados de migração.
	O cluster pode ter o modo de aplicação de SSL ativado.	Para fins de migração, o serviço de migração de base de dados requer que desative o modo de aplicação de SSL no cluster de origem.

A secção seguinte detalha o processo de realização de uma atualização da versão principal, incluindo a migração dos seus dados.

Atualização da versão principal no local

Isto oferece uma experiência de atualização integrada sem necessidade de configurar clusters adicionais. Para mais informações, consulte o artigo Atualize uma versão principal no local de uma base de dados.

Migre através da exportação de dados baseada em ficheiros

Para usar um servidor de base de dados compatível com uma versão principal superior do PostgreSQL, tem de criar um cluster funcionalmente idêntico na mesma região e, em seguida, migrar os seus dados para o mesmo.

Siga estes passos:

Crie um cluster configurado com a versão principal da compatibilidade do PostgreSQL que quer usar. Crie o cluster na mesma região que o cluster atual.
Configure o novo cluster com a nova versão principal para corresponder à configuração do cluster atual:
1. Crie instâncias de pool de leitura adicionais conforme necessário.
2. Crie clusters secundários conforme necessário.
  
  Quando cria clusters secundários, não precisa de especificar um número de versão principal do PostgreSQL. O AlloyDB aplica a versão do PostgreSQL do cluster principal a todos os respetivos clusters secundários.
3. Atualize as flags da base de dados do novo cluster para corresponderem às definições das flags do cluster atual.
4. Ative todas as extensões de que as suas aplicações precisam.
Exporte os seus dados do cluster antigo para ficheiros através do psql ou pg_dump.
Importe os seus dados dos ficheiros para o novo cluster.

As suas aplicações podem agora estabelecer ligação às instâncias do novo cluster nos respetivos novos endereços IP.

Migre através do Database Migration Service

Pode usar o serviço de migração de bases de dados para mover dados de bases de dados PostgreSQL para clusters do AlloyDB. O serviço de migração de bases de dados não fornece uma configuração dedicada especificamente para origens de dados do AlloyDB, mas o AlloyDB é compatível com o PostgreSQL, pelo que pode usar a configuração destinada a origens genéricas do PostgreSQL.

Este caminho de migração não é uma atualização no local e resulta na criação de um novo cluster com um endereço IP diferente. Recomendamos que clone primeiro o cluster e faça uma migração de teste para verificar se a sua aplicação é compatível com esta abordagem.

Aspetos a ter em conta

Antes de se preparar para a migração com o Database Migration Service, considere cuidadosamente as seguintes limitações para se certificar de que este caminho de migração se adequa ao seu cenário de atualização.

Limitações

As ligações SSL têm de ser desativadas no cluster de origem.
As instâncias do AlloyDB configuradas com o Private Service Connect não são suportadas.
Não pode fazer atualizações de instâncias nem pedidos de comutação por falha no cluster de origem durante a migração. Estas operações podem fazer com que a tarefa de migração falhe.
Todas as limitações padrão para migrações do PostgreSQL para o AlloyDB aplicam-se a este cenário. Para ver a lista completa de outras limitações, consulte Limitações conhecidas na documentação do serviço de migração de bases de dados.

Fidelidade da migração

Determinados tipos de dados, como objetos grandes, não são migrados. Para ver a lista completa de dados suportados, consulte o artigo Fidelidade da migração na documentação do Database Migration Service.

Bloqueio e tempo de inatividade da base de dados de origem

O Database Migration Service usa migrações contínuas para mover dados para clusters do AlloyDB. Este tipo de migração incorre num breve bloqueio (inferior a 10 segundos) nas tabelas da base de dados de origem, uma de cada vez, à medida que é criado o despejo de dados inicial.

Quando a migração estiver concluída, tem de parar todas as escritas na base de dados de origem antes de poder mudar a sua aplicação para o novo cluster. Este procedimento requer algum tempo de inatividade. Para uma vista geral mais detalhada, consulte Migrações contínuas na documentação do Database Migration Service.

Limitações de replicação

Depois de a tarefa de migração passar para a fase de captura de dados de alterações (CDC), o serviço de migração de bases de dados replica continuamente os novos dados escritos nas suas bases de dados de origem.

Para tabelas que não têm chaves primárias, apenas as declarações INSERT são replicadas durante a fase de CDC. Todas as ações CREATE, UPDATE ou DELETE realizadas em tabelas que não têm chaves primárias durante a fase de CDC têm de ser recriadas manualmente na base de dados de destino para evitar a perda de dados.

Antes de começar

Enable the Database Migration Service API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the API

Make sure that you have the following role or roles on the project:
- One of the following:
  - Cloud AlloyDB > Cloud AlloyDB admin
  - Basic > Owner
  - Basic > Editor
- You must also have the compute.networks.list permission in the Google Cloud project you are using. To gain this permission while following the principle of least privilege, ask your administrator to grant you the Compute Engine > Compute Network User role (roles/compute.networkUser).
- Database Migration admin
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the project.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  Aceder ao IAM
2. Selecione o projeto.
3. Clique em Conceder acesso.
4. No campo Novos responsáveis, introduza o identificador do utilizador. Normalmente, este é o endereço de email de uma Conta Google.
5. Na lista Selecionar uma função, selecione uma função.
6. Para conceder funções adicionais, clique em Adicionar outra função e adicione cada função adicional.
7. Clique em Guardar.
Certifique-se de que a rede VPC no Google Cloud projeto que está a usar está configurada para acesso a serviços privados ao AlloyDB.
Decida em que região quer criar o cluster de destino. Todas as entidades do serviço de migração de bases de dados (perfis de ligação, tarefas de migração) têm de ser criadas na mesma região que o cluster de destino.
Prepare um utilizador da base de dados que quer associar ao seu cluster e execute declarações de migração nas bases de dados de origem. Este utilizador da base de dados requer um conjunto específico de autorizações e funções. Recomendamos que crie um novo utilizador da base de dados e o designe especificamente para realizar a migração.

Configure as instâncias de origem

O serviço de migração de bases de dados requer uma configuração específica para poder estabelecer ligação e copiar dados do cluster de origem para o novo cluster de destino.

Para configurar as instâncias de origem do AlloyDB, siga estes passos:

Configure asflags da base de dados em todas as instâncias no cluster de origem. Use os seguintes valores:

Bandeira	Valor
`alloydb.logical_decoding`	Definido como `on`.
`alloydb.enable_pglogical`	Definido como `on`.
`max_replication_slots`	Esta flag define o número máximo de slots de replicação que a instância de origem pode suportar. O valor mínimo para esta flag é `50`. Calcule o valor mínimo através da seguinte fórmula: `(the number of databases in your instance) * (the number of simultaneous migration jobs you want to perform) + (slots reserved for table synchronization) + (the number of replication slots you currently use for your read replicas)` Considere um exemplo em que o seguinte é verdadeiro: Não tem réplicas de leitura na sua origem. Tem 30 bases de dados na instância de origem principal. Quer criar 2 tarefas de migração para o cluster de origem. Quiser usar 10 espaços para a replicação de tabelas. Nesse caso, o número de `max_replication_slots` tem de ser, pelo menos, `70`, calculado como `30 * 2 + 10 + 0`.
`max_wal_senders`	Defina esta flag para, pelo menos, 10 mais do que o valor `max_replication_slots`, mais o número de remetentes já usados na sua instância. Por exemplo, se definir o `max_replication_slots flag` como `70` e já usar 2 remetentes, `max_wal_senders` deve ser, pelo menos, `82` (calculado como `70 + 10 + 2 = 82`).
`max_worker_processes`	Defina esta flag, pelo menos, para o número de bases de dados na sua instância, mais o número de `max_worker_processes` que já usa. Por exemplo, se tiver 30 bases de dados na instância de origem e não usar processos de trabalho, defina esta flag como `30`.

Desative o modo de aplicação de SSL em todas as instâncias no cluster de origem.

Configure as bases de dados de origem

Tem de instalar a extensão pglogical e conceder as autorizações necessárias ao utilizador da base de dados que designar como utilizador de migração em todas as bases de dados nas suas instâncias.

Para configurar as bases de dados, siga estes passos:

Associe à base de dados postgres predefinida através do psql cliente.
Instale a extensão pglogical executando o seguinte comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Conceda autorizações ao utilizador da base de dados de migração em todos os esquemas, exceto no esquema information e nos esquemas cujos nomes comecem pelo prefixo pg_. Execute as seguintes declarações:
```
GRANT USAGE on SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA_NAME to USER_NAME;
```
Substitua o seguinte:
- SCHEMA_NAME: o nome de um esquema presente na sua base de dados
- USER_NAME: o nome do utilizador da base de dados que preparou na secção Antes de começar
Repita este passo para todos os esquemas na sua base de dados exceto o esquema information e os esquemas cujos nomes começam com o prefixo pg_. Pode apresentar uma lista de todos os esquemas da base de dados com o metacomando \dn.
Conceda as restantes autorizações necessárias. Execute as seguintes declarações:
```
GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;
```
Substitua USER_NAME pelo nome do utilizador da base de dados que preparou na secção Antes de começar.
Associe a todas as outras bases de dados na sua instância e repita os passos 2, 3 e 4.
- Pode listar todas as bases de dados na sua instância com o metacomando \list.
- Pode mudar para outra base de dados sem repor a ligação do cliente psql usando o comando \connect {database_name_here}.
Repita este procedimento para cada instância no cluster do AlloyDB de origem.

Execute a migração no Database Migration Service