Clonar um cluster de banco de dados em um único servidor usando um backup local

Esta página mostra como clonar um cluster de banco de dados em um único servidor usando o backup local.

As etapas desta página presumem que o cluster de banco de dados do Kubernetes de origem foi criado no Google Kubernetes Engine e que os discos de backup são discos persistentes do Compute Engine. Também pressupõe que o servidor único do AlloyDB Omni de destino esteja instalado em uma máquina virtual (VM) do Compute Engine.

Se você usa outros ambientes, consulte a documentação correspondente para replicar essas etapas no seu ambiente.

O fluxo de trabalho a seguir explica as etapas de clonagem:

  1. Identifique as informações do disco de backup, como o nome do volume persistente e o gerenciador disco permanente do Compute Engine, para o disco de backup do cluster do banco de dados de origem.
  2. Monte o disco de backup do cluster de banco de dados de origem no servidor de destino.
  3. Use comandos pgBackRest para verificar se os backups de origem podem ser acessados.
  4. Use comandos pgBackRest para restaurar o backup no cluster de banco de dados de destino.

Antes de começar

  • Verifique se você tem acesso ao disco de backup em que o backup do cluster de banco de dados de origem está armazenado.
  • Um cluster de banco de dados do AlloyDB Omni de destino do servidor único é criado. Para mais informações sobre como instalar o AlloyDB Omni no Kubernetes, consulte Instalar o AlloyDB Omni.
  • Verifique se você fez login no banco de dados como o usuário postgres.

Receber informações do disco de backup de origem

Como parte do processo de restauração, determine o nome da declaração de volume permanente (PVC) do disco de backup para o cluster de banco de dados de origem. Os PVCs são usados no Kubernetes para gerenciar o armazenamento permanente de aplicativos.

Os comandos de exemplo a seguir ajudam a determinar o nome do PV e o gerenciador de disco permanente do Compute Engine usando o nome da PVC do disco de backup.

  1. Conecte-se ao cluster do GKE em que você criou o cluster de banco de dados de origem do AlloyDB Omni:

     kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backupdisk

    Substitua:

    • DB_CLUSTER_NAMESPACE: o namespace do Kubernetes para este backup. Ele precisa corresponder ao namespace do cluster do banco de dados.

    • DB_CLUSTER_NAME: o nome desse cluster de banco de dados, por exemplo, my-db-cluster.

    Confira a seguir um exemplo de resposta.

      backupdisk-al-fe8c-dbcluster-sample-0   Bound
  pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
  ```

  2. Use o nome do disco de backup da etapa anterior, por exemplo, backupdisk-al-fe8c-dbcluster-sample-0, para encontrar o nome do PV:

      kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}

    Substitua:

    • PVC_NAME: o nome do PVC do disco de backup da resposta na etapa anterior, por exemplo, backupdisk-al-fe8c-dbcluster-sample-0.

  3. Encontre o gerenciador de disco permanente do Compute Engine:

      kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle

    Substitua:

    • PV_NAME: o nome do PV do disco de backup da resposta na etapa anterior.

    Confira a seguir um exemplo de resposta:

      projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

  4. Exporte o nome do disco de backup como uma variável usada nas próximas seções:

      export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

Monte o disco de backup no servidor de destino

Supondo que o servidor de destino seja um servidor AlloyDB Omni instalado em uma máquina virtual do Compute Engine, monte o disco de backup no servidor.

  1. Execute o comando gcloud compute instances attach-disk para montar o disco:

      gcloud compute instances attach-disk GCE_INSTANCE_NAME \
  --disk ${BACKUP_DISK} \
  --zone=$GCE_ZONE

    Substitua:

    • GCE_INSTANCE_NAME: o nome da instância em que o servidor de destino está instalado na máquina virtual do Compute Engine.

    • GCE_ZONE: a zona em que a instância da máquina virtual do Compute Engine existe.

  2. Monte o disco de backup no servidor de destino:

       lsblk
   mkdir -p /mnt/disks/backupdisk
   mount -o discard,defaults /dev/sdb /mnt/disks/backupdisk

  3. Adicione um bind mount personalizado ao arquivo dataplane.conf do AlloyDB Omni no diretório /var/alloydb/config:

      PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared

Para mais informações sobre as montagens de vinculação no Docker, consulte Montagens de vinculação.

  1. Reinicie o servidor de destino:

Docker 

  docker restart CONTAINER_NAME

Substitua CONTAINER_NAME pelo nome de um novo contêiner do AlloyDB Omni, por exemplo, my-omni-1.

Podman 

  podman restart CONTAINER_NAME

Substitua CONTAINER_NAME pelo nome de um novo contêiner do AlloyDB Omni, por exemplo, my-omni-1.

Atualizar o arquivo de configuração pgBackRest

Atualize o arquivo pgBackRest no diretório de disco de backup com o novo caminho do repositório.

  1. No servidor de destino, acesse o diretório /mnt/disks/backupdisk:

      cd /mnt/disks/backupdisk

  2. Atualize o caminho pg1-path para um diretório temporário no arquivo pgbackrest.conf para evitar a substituição dos dados atuais. O diretório data-restored é criado automaticamente como parte do processo de restauração:

      sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.conf

  3. Atualize o caminho repo1-path para um diretório temporário no arquivo pgbackrest.conf:

      sudo sed -i 's|.*repo1-path.*|repo1-path=/mnt/disks/backups/repo|' conf.d/repo1-local-backupplan.conf

Verificar backups de origem no cluster de banco de dados de destino

Faça login no servidor de destino e execute comandos pgBackRest para verificar se os backups do cluster de banco de dados de origem estão acessíveis no servidor de destino:

Docker 

  sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Podman 

  sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Veja a seguir um exemplo de resposta:

    stanza: db
    status: ok
    cipher: none
    db (current)
        wal archive min/max (15): 000000010000000000000002/00000001000000000000000D
        full backup: 20240213-231400F
            timestamp start/stop: 2024-02-13 23:14:00+00 / 2024-02-13 23:17:14+00
            wal start/stop: 000000010000000000000003 / 000000010000000000000003
            database size: 38.7MB, database backup size: 38.7MB
            repo1: backup set size: 4.6MB, backup size: 4.6MB
        incr backup: 20240213-231400F_20240214-000001I
            timestamp start/stop: 2024-02-14 00:00:01+00 / 2024-02-14 00:00:05+00
            wal start/stop: 00000001000000000000000D / 00000001000000000000000D
            database size: 38.7MB, database backup size: 488.3KB
            repo1: backup set size: 4.6MB, backup size: 84.2KB
            backup reference list: 20240213-231400F

Os carimbos de data/hora na resposta são usados para restaurar o backup completo ou de um ponto no tempo da janela de recuperação.

Restaurar o backup no servidor de destino

Depois de identificar o backup ou um ponto no tempo para o qual você quer restaurar, execute comandos pgBackRest no servidor de destino. Para mais informações sobre esses comandos, consulte Restore Command.

Confira a seguir alguns exemplos de comandos de restauração pgBackRest:

  • Restaurar a partir de um backup

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info

  • Restaurar de um momento

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

Copiar dados para o servidor de destino

Depois que o comando de restauração for concluído, será possível copiar os dados do diretório temporário data-restored para o diretório de dados atual do AlloyDB.

  1. No servidor de destino, interrompa o serviço de banco de dados:

    Docker 

    docker stop CONTAINER_NAME

    Podman 

    podman stop CONTAINER_NAME

  2. Como prática recomendada, renomeie o diretório de dados atual para outro nome:

      mv ~/alloydb-data/data  ~/alloydb-data/data-old

  3. Renomeie o diretório temporário data-restored para o diretório de dados atual:

      mv ~/alloydb-data/data-restored ~/alloydb-data/data

  4. Atualize o valor pg1-path no arquivo postgresql.auto.conf para carregar os dados restaurados:

        vim ~/alloydb-data/data/postgresql.auto.conf
    # Verify postgresql.auto.conf.
    # Do not edit this file manually!
    # It will be overwritten by the ALTER SYSTEM command.
    # Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11
    restore_command = 'pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f "%p"'
    recovery_target = 'immediate'
    recovery_target_action = 'promote'
    recovery_target_timeline = 'current'

  5. No servidor de destino, inicie o serviço de banco de dados:

    Docker 

    docker start CONTAINER_NAME

    Podman 

    podman start CONTAINER_NAME

Depois que o serviço do banco de dados for iniciado, você poderá se conectar à instância principal e executar consultas para verificar se os dados foram restaurados do backup. Para mais informações, consulte Conectar-se ao AlloyDB Omni em um único servidor.

A seguir