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

Selecione uma versão da documentação:

Nesta página, mostramos como clonar um cluster de banco de dados em um único servidor usando o backup local.

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

Se você usa outros ambientes, consulte a documentação respectiva 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 permanente e o manipulador do disco permanente do Compute Engine, para o disco de backup do cluster de 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 é possível acessar os backups de origem.
  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 de destino do AlloyDB Omni de 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. As PVCs são usadas no Kubernetes para gerenciar o armazenamento permanente de aplicativos.

Os comandos de exemplo a seguir ajudam a determinar o nome do PV subjacente e o manipulador 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 de banco de dados.

    • DB_CLUSTER_NAME: o nome do 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 subjacente:

      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 manipulador de disco permanente do Compute Engine subjacente:

      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

Ative o disco de backup no servidor de destino

Supondo que o servidor de destino seja um servidor do 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 ativar 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 de máquina virtual do Compute Engine existe.

  2. Ative 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 uma vinculação de montagem personalizada 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 vinculações de montagem no Docker, consulte Vinculações de montagem.

  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 do 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 os 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

Confira 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 momento específico para restauração, execute os comandos pgBackRest no servidor de destino. Para mais informações sobre esses comandos, consulte Comando Restore.

Confira alguns exemplos de comandos de restauração do 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, copie 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. Renomeie o diretório de dados atual para outro nome como prática recomendada:

      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 de 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