Fazer upgrade da versão principal do servidor de um cluster

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

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

Clusters e compatibilidade com a versão do PostgreSQL

Ao criar um cluster do AlloyDB, você escolhe a versão principal do PostgreSQL compatível com as instâncias no cluster. O padrão é 15.

O AlloyDB faz upgrades automáticos de versões secundárias do banco de dados durante a manutenção periódica. Por exemplo, se você criou um cluster com compatibilidade com 15, o AlloyDB mantém os servidores de banco de dados atualizados para a versão secundária mais recente de 15.

No entanto, um upgrade de versão principal do PostgreSQL exige que você planeje, teste e faça o upgrade por conta própria.

Há vários métodos para fazer upgrades de versão principal do cluster:

  1. Um upgrade de versão principal no local que recomendamos usar.
  2. Migrar os dados com uma exportação de dados baseada em arquivos.
  3. Usar o serviço de migração de banco de dados.

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

Upgrade de versão principal no local Exportação de dados baseada em arquivos Migração com o Database Migration Service
Seu cluster, incluindo instâncias de leitura, é atualizado para a versão principal mais recente escolhida. As exportações baseadas em arquivos movem um resumo único dos seus bancos de dados. O Database Migration Service oferece recursos de replicação contínua durante o processo de migração, diminuindo a chance de dados ausentes no novo cluster.
Você pode continuar trabalhando no cluster durante a fase de pré-upgrade. O aplicativo tem um tempo de inatividade maior que começa quando você exporta os dados. Não é possível aceitar gravações de banco de dados no cluster original até que o novo cluster esteja totalmente operacional. O aplicativo tem um tempo de inatividade menor que começa quando você quer mudar o aplicativo para usar o novo cluster.
Dependendo do esquema, o tempo de inatividade durante o processo de upgrade pode ser de cerca de 20 minutos ou mais. Após o upgrade, você pode acessar o cluster com o mesmo endereço IP. Você tem um controle mais granular sobre quais dados incluir na exportação e pode escolher não migrar determinadas tabelas ou outras entidades. O Database Migration Service migra automaticamente todos os bancos de dados presentes nas instâncias e em todos os clusters. Não é possível excluir determinadas tabelas ou visualizações dos dados de migração.
O modo de aplicação do SSL pode estar ativado no cluster. Para fins de migração, o Database Migration Service exige que você desative o modo de aplicação do SSL no cluster de origem.


A próxima seção detalha o processo de upgrade de uma versão principal, incluindo a migração de dados.

Upgrade de versão principal no local

Isso oferece uma experiência de upgrade simplificada sem a necessidade de configurar clusters adicionais. Para mais informações, consulte Fazer upgrade da versão principal de um banco de dados no local.

Migrar usando a exportação de dados baseada em arquivos

Para usar um servidor de banco de dados compatível com uma versão principal mais recente do PostgreSQL, crie um cluster funcionalmente idêntico na mesma região e migre seus dados para ele.

Siga estas etapas:

  1. Crie um cluster configurado com a versão principal da compatibilidade do PostgreSQL que você quer usar. Crie o cluster na mesma região do cluster atual.

  2. Configure o novo cluster com a nova versão principal para corresponder à configuração atual do cluster:

    1. Crie outras instâncias do pool de leitura, conforme necessário.

    2. Crie clusters secundários conforme necessário.

      Ao criar clusters secundários, não é necessário especificar um número de versão principal do PostgreSQL. O AlloyDB aplica a versão do PostgreSQL do cluster principal a todos os clusters secundários.

    3. Atualize as flags do banco de dados do novo cluster para corresponder às configurações de flag do cluster atual.

    4. Ative todas as extensões necessárias para seus aplicativos.

  3. Exporte seus dados do cluster antigo para arquivos usando psql ou pg_dump.

  4. Importe os dados dos arquivos para o novo cluster.

Agora, seus aplicativos podem se conectar às instâncias do novo cluster nos novos endereços IP.

Migrar usando Database Migration Service

Use o Database Migration Service para migrar dados de bancos de dados PostgreSQL para clusters do AlloyDB. O Database Migration Service não oferece uma configuração dedicada especificamente para fontes de dados do AlloyDB, mas o AlloyDB é compatível com o PostgreSQL. Assim, você pode usar a configuração destinada a fontes genéricas do PostgreSQL.

Esse caminho de migração não é um upgrade no local e resulta na criação de um novo cluster com um endereço IP diferente. Recomendamos que você primeiro crie um clone do cluster e realize uma migração de teste para verificar se o aplicativo é compatível com essa abordagem.

Considerações importantes

Antes de se preparar para migrar com o Database Migration Service, considere cuidadosamente as limitações a seguir para garantir que esse caminho de migração se encaixe no seu cenário de upgrade.

Limitações
  • As conexões SSL precisam estar desativadas no cluster de origem.
  • Não há suporte para instâncias do AlloyDB configuradas com o Private Service Connect.
  • Não é possível realizar atualizações de instância ou solicitações de failover no cluster de origem durante a migração. Essas operações podem causar falhas no job de migração.
  • Todas as limitações padrão para migrações do PostgreSQL para o AlloyDB se aplicam a esse cenário. Para conferir a lista completa de outras limitações, consulte Limitações conhecidas na documentação do Database Migration Service.
Fidelidade de migração
Alguns tipos de dados, como objetos grandes, não são migrados. Para conferir a lista completa de dados compatíveis, consulte Fidelidade da migração na documentação do Database Migration Service.
Bloqueio e inatividade do banco de dados de origem

O Database Migration Service usa migrações contínuas para mover dados para clusters do AlloyDB. Esse tipo de migração gera um bloqueio curto (menos de 10 segundos) nas tabelas do banco de dados de origem, uma por vez, à medida que o despejo de dados inicial é criado.

Quando a migração for concluída, você precisará interromper todas as gravações no banco de dados de origem antes de alternar o aplicativo para o novo cluster. Esse procedimento requer algum tempo de inatividade. Para uma visão geral mais detalhada, consulte Migrações contínuas na documentação do Database Migration Service.

Limitações da replicação

Depois que o job de migração passa para a fase captura de dados alterados (CDC), o Database Migration Service replica continuamente os novos dados gravados nos bancos de dados de origem.

Para tabelas que não têm chaves primárias, somente instruçõ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 precisam ser recriadas manualmente no banco de dados de destino para evitar a perda de dados.

Antes de começar

  1. Enable the Database Migration Service API.

    Enable the API

  2. 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.

      Acessar o IAM
    2. Selecionar um projeto.
    3. Clique em CONCEDER ACESSO.

    4. No campo Novos principais, insira seu identificador de usuário. Normalmente, é o endereço de e-mail de uma Conta do Google.

    5. Na lista Selecionar um papel, escolha um.
    6. Para conceder outros papéis, clique em Adicionar outro papel e adicione cada papel adicional.
    7. Clique em Salvar.
    8. Verifique se a rede VPC no projeto do Google Cloud que você está usando está configurada para acesso a serviços particulares ao AlloyDB.
    9. Decida em qual região você quer criar o cluster de destino. Todas as entidades do Database Migration Service (perfis de conexão, jobs de migração) precisam ser criadas na mesma região que o cluster de destino.
    10. Prepare um usuário de banco de dados que você quer conectar ao cluster e execute instruções de migração nos bancos de dados de origem. Esse usuário do banco de dados requer um conjunto específico de permissões e funções. Recomendamos que você crie um novo usuário de banco de dados e o designe especificamente para realizar a migração.

    Configurar as instâncias de origem

    O Database Migration Service requer uma configuração específica para se conectar e copiar dados do cluster de origem para o novo cluster de destino.

    Para configurar as instâncias de origem do AlloyDB, siga estas etapas:

    1. Configure as flags do banco de dados em cada instância do cluster de origem. Use os valores a seguir:
      Sinalização Valor
      alloydb.logical_decoding Defina como on.
      alloydb.enable_pglogical Defina como on.
      max_replication_slots Essa 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 essa flag é 50.

      Calcule o valor mínimo usando a 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:

      • Você não tem réplicas de leitura na sua origem.
      • Você tem 30 bancos de dados na instância de origem principal.
      • Você quer criar dois jobs de migração para o cluster de origem.
      • Você quer usar 10 slots para a replicação de tabelas.
      Nesse caso, o número de max_replication_slots precisa ser pelo menos 70, calculado como 30 * 2 + 10 + 0.
      max_wal_senders Defina essa flag com pelo menos 10 a mais do que o valor max_replication_slots mais o número de remetentes já usados na sua instância.

      Por exemplo, se você definir max_replication_slots flag como 70 e já usar dois remetentes, o max_wal_senders precisará ser pelo menos 82 (calculado como 70 + 10 + 2 = 82).

      max_worker_processes Defina essa flag como pelo menos o número de bancos de dados na sua instância, além do número de max_worker_processes que você já usa.

      Por exemplo, se você tiver 30 bancos de dados na instância de origem e não usar nenhuma worker process, defina essa flag como 30.
    2. Desative o modo de aplicação do SSL em todas as instâncias do cluster de origem.

    Configurar os bancos de dados de origem

    É necessário instalar a extensão pglogical e conceder as permissões necessárias ao usuário do banco de dados que você designou como usuário de migração em todos os bancos de dados nas suas instâncias.

    Para configurar seus bancos de dados, siga estas etapas:

    1. Conecte-se ao banco de dados postgres padrão usando o cliente psql.

    2. Instale a extensão pglogical executando o seguinte comando:

      CREATE EXTENSION IF NOT EXISTS pglogical;

    3. Conceda permissões ao usuário do banco de dados de migração em todos os esquemas exceto o esquema information e os esquemas com nomes que começam com o prefixo pg_. Execute as seguintes instruçõ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:

      • SCHEMA_NAME: o nome de um esquema presente no seu banco de dados
      • USER_NAME: o nome do usuário do banco de dados que você preparou na seção Antes de começar.

      Repita essa etapa para todos os esquemas no seu banco de dados exceto o esquema information e os esquemas com nomes que começam com o prefixo pg_. É possível listar todos os esquemas de banco de dados com o metacomando \dn.

    4. Conceda as permissões restantes. Execute as seguintes instruçõ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 usuário do banco de dados que você preparou na seção Antes de começar.

    5. Conecte-se a todos os outros bancos de dados na sua instância e repita as etapas 2, 3 e 4.

      • É possível listar todos os bancos de dados na sua instância com o metacomando \list.

      • É possível alternar para outro banco de dados sem redefinir a conexão do cliente psql usando o comando \connect {database_name_here}.

    6. Repita esse procedimento para cada instância no cluster de origem do AlloyDB.

    Executar a migração no Database Migration Service

    Siga estas etapas:

    1. Crie um perfil de conexão de origem para seu cluster do AlloyDB. Use os valores a seguir:

      • Mecanismo de banco de dados: selecione PostgreSQL.
      • Hostname/IP: use o endereço IP da instância principal no cluster.
      • Nome de usuário/senha: insira as credenciais do usuário do banco de dados que você preparou na seção Antes de começar.
      • Porta: insira 5432.
      • Região: selecione a região em que o cluster de destino está localizado.
      • Tipo de criptografia: selecione Nenhum.

    2. Crie e execute o job de migração.

      Você pode criar seu novo cluster do AlloyDB com antecedência ou pedir que o Database Migration Service crie o cluster para você durante a configuração do job de migração. Para mais informações, consulte Visão geral dos jobs de migração na documentação do Database Migration Service.

      Se você quiser que o Database Migration Service crie o cluster de destino para você durante a configuração do job de migração, siga as etapas no procedimento Criar um job de migração para uma nova instância de destino.

      Se você quiser criar o cluster de destino fora do Database Migration Service, siga as etapas no procedimento Criar um job de migração para uma instância de destino atual.

    3. Quando o status do job de migração mudar para CDC, promova o job de migração. É possível verificar o status do job de migração na página de visão geral da migração. Consulte Como revisar um job de migração na documentação do Database Migration Service.

      Essa ação faz com que o cluster de destino saia do modo de inicialização, ou seja, o cluster de destino do AlloyDB não está mais no estado somente leitura.

    4. (Opcional) Verifique se há instruções ausentes em tabelas que não têm chaves primárias.

      Se os bancos de dados de origem do AlloyDB contiverem tabelas que não tenham chaves primárias, talvez seja necessário migrar manualmente as instruções UPDATE ou DELETE ausentes. Consulte Migrar operações UPDATE e DELETE para chave primária não primária na documentação do Database Migration Service.

    5. Mude o aplicativo para o novo cluster. Agora, seus aplicativos podem se conectar às instâncias do novo cluster nos novos endereços IP.