Clone um cluster de base de dados num único servidor através de uma cópia de segurança local

Selecione uma versão da documentação:

Esta página mostra-lhe como clonar um cluster de base de dados num único servidor através da cópia de segurança local.

Os passos nesta página partem do princípio de que o cluster da base de dados Kubernetes de origem é criado no Google Kubernetes Engine e que os discos de cópia de segurança são discos persistentes do Compute Engine. Também pressupõe que o servidor único do AlloyDB Omni de destino está instalado numa máquina virtual (VM) do Compute Engine.

Se usar outros ambientes, consulte a documentação respetiva para replicar estes passos no seu ambiente.

O fluxo de trabalho seguinte explica os passos de clonagem:

  1. Identifique as informações do disco de cópia de segurança, como o nome do volume persistente e o controlador do disco persistente do Compute Engine, para o disco de cópia de segurança do cluster da base de dados de origem.
  2. Monte o disco de cópia de segurança do cluster da base de dados de origem no servidor de destino.
  3. Use comandos pgBackRest para verificar se é possível aceder às cópias de segurança da origem.
  4. Use os comandos pgBackRest para restaurar a cópia de segurança no cluster da base de dados de destino.

Antes de começar

  • Certifique-se de que tem acesso ao disco de cópia de segurança onde está armazenada a cópia de segurança do cluster da base de dados de origem.
  • É criado um único cluster de base de dados AlloyDB Omni de destino do servidor. Para mais informações sobre a instalação do AlloyDB Omni no Kubernetes, consulte o artigo Instale o AlloyDB Omni.
  • Certifique-se de que tem sessão iniciada na base de dados como utilizador postgres.

Obtenha informações do disco de cópia de segurança de origem

Como parte do processo de restauro, determine o nome da reivindicação de volume persistente (PVC) do disco de cópia de segurança para o cluster da base de dados de origem. Os PVCs são usados no Kubernetes para gerir o armazenamento persistente de aplicações.

Os seguintes comandos de exemplo ajudam a determinar o nome do PV subjacente e o controlador do disco persistente do Compute Engine através do nome do PVC do disco de cópia de segurança.

  1. Faça a ligação ao cluster do GKE onde criou o cluster da base de dados de origem do AlloyDB Omni:

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

    Substitua o seguinte:

    • DB_CLUSTER_NAMESPACE: o namespace do Kubernetes para esta cópia de segurança. Tem de corresponder ao espaço de nomes do cluster da base de dados.

    • DB_CLUSTER_NAME: o nome deste cluster de base de dados, por exemplo, my-db-cluster.

    Segue-se a resposta de exemplo.

      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 cópia de segurança do passo anterior, por exemplo, backupdisk-al-fe8c-dbcluster-sample-0, para encontrar o nome do volume físico subjacente:

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

    Substitua o seguinte:

    • PVC_NAME: o nome do PVC do disco de cópia de segurança da resposta no passo anterior, por exemplo, backupdisk-al-fe8c-dbcluster-sample-0.

  3. Encontre o controlador do disco persistente do Compute Engine subjacente:

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

    Substitua o seguinte:

    • PV_NAME: o nome do volume físico do disco de cópia de segurança da resposta no passo anterior.

    Segue-se a resposta de exemplo:

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

  4. Exporte o nome do disco de cópia de segurança como uma variável usada nas secções seguintes:

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

Monte o disco de cópia de segurança no servidor de destino

Partindo do princípio de que o servidor de destino é um servidor AlloyDB Omni instalado numa máquina virtual do Compute Engine, monte o disco de cópia de segurança 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 o seguinte:

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

    • GCE_ZONE: a zona onde existe a sua instância de máquina virtual do Compute Engine.

  2. Monte o disco de cópia de segurança no servidor de destino:

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

  3. Adicione uma montagem de ligação personalizada ao ficheiro 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 associações no Docker, consulte o artigo Montagens de associações.

  1. Reinicie o servidor de destino:

      alloydb database-server stop
  alloydb database-server start

Atualize o ficheiro de configuração pgBackRest

Atualize o ficheiro pgBackRest existente no diretório do disco de cópia de segurança com o novo caminho do repositório.

  1. No servidor de destino, aceda ao diretório /mnt/disks/backupdisk:

      cd /mnt/disks/backupdisk

  2. Atualize o caminho pg1-path para um diretório temporário no ficheiro pgbackrest.conf para evitar substituir os dados existentes. O diretório data-restored é criado automaticamente como parte do processo de restauro:

      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 ficheiro pgbackrest.conf:

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

Valide as cópias de segurança de origem no cluster da base de dados de destino

Inicie sessão no servidor de destino e execute comandos pgBackRest para verificar se as cópias de segurança do cluster da base de dados de origem estão acessíveis no servidor de destino:

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

Segue-se 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

As indicações de tempo na resposta são usadas para restaurar a cópia de segurança completa ou para restaurar a partir de um ponto específico no tempo da janela de recuperação.

Restaure a cópia de segurança no servidor de destino

Depois de identificar a cópia de segurança ou um ponto no tempo para o qual quer fazer o restauro, execute os comandos pgBackRest no servidor de destino. Para mais informações acerca destes comandos, consulte o artigo Comando Restore.

Seguem-se alguns exemplos de pgBackRest comandos de restauro:

  • Restauro a partir de cópia de segurança

    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 a partir de um momento específico

    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

Copie os dados para o servidor de destino

Depois de o comando de restauro ser concluído com êxito, pode copiar os dados do diretório temporário data-restored para o diretório de dados do AlloyDB atual.

  1. No servidor de destino, pare o serviço de base de dados:

    alloydb database-server stop

  2. Mude o nome do diretório de dados atual para outro nome como prática recomendada:

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

  3. Mude o nome do 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 ficheiro 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 base de dados:

    alloydb database-server start

Depois de o serviço de base de dados ser iniciado, pode estabelecer ligação à instância principal e executar consultas para verificar se os dados foram restaurados a partir da cópia de segurança. Para mais informações, consulte o artigo Estabeleça ligação ao AlloyDB Omni num único servidor.

O que se segue?