Clone um cluster de base de dados no Kubernetes com uma cópia de segurança local

Selecione uma versão da documentação:

Este documento descreve como clonar um cluster de base de dados no Kubernetes através da cópia de segurança local de um cluster de base de dados do AlloyDB Omni.

Este documento pressupõe o seguinte:

  • Os clusters de base de dados de origem e de destino são criados no Google Kubernetes Engine, e os discos de cópia de segurança são discos persistentes do Compute Engine.
  • Os discos persistentes do Compute Engine que são usados como um disco de cópia de segurança na base de dados não são usados por outros clusters de bases de dados.

Quando clona um cluster de base de dados, segue estes passos:

  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. Certifique-se de que ativou a funcionalidade de cópia de segurança para o cluster da base de dados de origem e que tem, pelo menos, uma cópia de segurança bem-sucedida. Se estas condições não forem cumpridas, siga as instruções em Ative e agende cópias de segurança.
  2. Crie um recurso PersistentVolume para usar um disco de cópia de segurança existente no cluster da base de dados de destino para aceder ao disco de cópia de segurança do cluster da base de dados de origem.
  3. Crie e aplique o ficheiro de manifesto do recurso DBCluster no cluster da base de dados de destino com o parâmetro livenessProbe desativado e as informações do disco de cópia de segurança adicionadas.
  4. Use comandos pgBackRest para verificar se é possível aceder às cópias de segurança da origem.
  5. 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.
  • O disco de cópia de segurança do cluster da base de dados de origem tem de poder ser montado no cluster da base de dados de destino. Para mais informações, consulte o artigo Volumes persistentes. Se o back-end de armazenamento subjacente não suportar o acesso ReadOnlyMany (ROX), certifique-se de que o disco de cópia de segurança não está a ser usado por nenhum pod no cluster de origem.
  • Uma vez que o disco de cópia de segurança de origem está montado no cluster da base de dados de destino, o ficheiro pgBackRest.conf é reutilizado tal como está.
  • 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 localizar o nome do PV subjacente e o controlador do disco persistente do Compute Engine. No exemplo, todos os discos de cópia de segurança são discos persistentes do Compute Engine, aos quais é possível aceder em VMs do Compute Engine através do identificador do controlador de disco.

  1. Ligue-se ao cluster da base de dados de destino para encontrar o nome do PVC:

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

    Substitua o seguinte:

    • DB_CLUSTER_NAMESPACE: o namespace do Kubernetes para este plano de 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.

        backuprepodisk-my-db-cluster-br-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h

  2. Use o nome do PVC do disco de cópia de segurança do passo anterior, por exemplo, backuprepodisk-my-db-cluster-br-0, para encontrar o nome do PV subjacente e o controlador do disco persistente do Compute Engine:

      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, backuprepodisk-my-db-cluster-br-0.

  3. Exporte as configurações com base no nome da PV como variáveis a usar nas secções subsequentes:

      export BACKUP_DISK_SIZE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.capacity.storage}")
  export FS_TYPE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.fsType}")
  export VOLUME_HANDLER=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.volumeHandle}")
  export STORAGE_CLASS=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.storageClassName}")

    Substitua o seguinte:

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

Crie um recurso de volume persistente

Usando o nome do controlador de disco, crie um recurso PersistentVolume.

  1. No cluster Kubernetes de destino, crie o ficheiro de manifesto PersistentVolume:

        apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: PV_NAME
    spec:
      storageClassName: "${STORAGE_CLASS}"
      capacity:
        storage: "${BACKUP_DISK_SIZE}"
      accessModes:
        - ReadWriteOnce
      csi:
        driver: pd.csi.storage.gke.io
        volumeHandle: "${VOLUME_HANDLER}"
        fsType: "${FS_TYPE}"

    Substitua o seguinte:

    • PV_NAME: o nome do recurso PersistentVolume que vai ser criado.

  2. Aplique o ficheiro de manifesto:

      kubectl apply -f PV_FILENAME

    Substitua o seguinte:

    • PV_FILENAME: o nome do ficheiro de manifesto PersistentVolume criado no passo anterior.

Crie um cluster de base de dados de destino

Crie um cluster de base de dados desativando temporariamente o parâmetro livenessProbe. Após a conclusão do restauro, reconfigure o parâmetro livenessProbe.

  1. Crie o ficheiro de manifesto DBCluster:

      apiVersion: v1
  kind: Secret
  metadata:
    name: db-pw-DB_CLUSTER_NAME
  type: Opaque
  data:
    DB_CLUSTER_NAME: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: DBCluster
  metadata:
    name: DB_CLUSTER_NAME
  spec:
    databaseVersion: "15.7.1"
    primarySpec:
      availabilityOptions:
        livenessProbe: "Disabled"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DATA_DISK_SIZE
        - name: BackupDisk
          size: ${BACKUP_DISK_SIZE}
          storageClass: ${STORAGE_CLASS}
          volumeName: PV_NAME

    Substitua o seguinte:

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

    • ENCODED_PASSWORD: a palavra-passe de início de sessão na base de dados para a função de utilizador postgres predefinida, codificada como uma string base64, por exemplo, Q2hhbmdlTWUxMjM= para ChangeMe123.

    • CPU_COUNT: o número de CPUs disponíveis para cada instância da base de dados neste cluster de base de dados.

    • MEMORY_SIZE: a quantidade de memória por instância da base de dados deste cluster de base de dados. Recomendamos que defina este valor para 8 gigabytes por CPU. Por exemplo, se definir CPU_COUNT como 2, recomendamos que defina memory como 16Gi.

    • DATA_DISK_SIZE: o tamanho do disco por instância da base de dados, por exemplo, 10Gi.

  2. Aplique o ficheiro de manifesto:

      kubectl apply -f DBCLUSTER_FILENAME

    Substitua o seguinte:

    • DBCLUSTER_FILENAME: o nome do ficheiro de manifesto DBCluster criado no passo anterior.

Use o comando kubectl describe para verificar se o recurso do cluster da base de dados está no estado READY.

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

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 cluster da base de dados de destino.

  1. No cluster de base de dados de destino, encontre os detalhes do pod do cluster de base de dados:

      kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"

    A resposta inclui o nome do pod da base de dados do cluster.

  2. Inicie sessão no pod da base de dados:

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

    Substitua o seguinte:

    • DATABASE_POD_NAME : o nome do pod do cluster da base de dados do passo anterior.

  3. Pare o pod antes de atualizar o ficheiro de configuração pgBackRest:

      supervisorctl.par stop postgres

  4. Atualize o ficheiro de configuração pgBackRest:

      cp /backup/pgbackrest.conf /backup/pgbackrest.conf.bak
  rm /backup/pgbackrest.conf
  cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/backup/logs
  log-level-file=info
  EOF

  5. Valide as cópias de segurança de origem no pod do cluster da base de dados:

    pgbackrest --config-path=/backup --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 cluster da base de dados 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 cluster da base de dados de destino. Para mais informações sobre estes 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=/backup --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=/backup --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

Reinicie o pod

Depois de o comando de restauro ser concluído com êxito, pode iniciar o processo postgres.

supervisorctl.par start postgres

Depois de o processo postgres 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 em execução no Kubernetes.

Configure o cluster da base de dados

Depois de clonar um cluster de base de dados, configure as especificações do cluster de base de dados. Certifique-se de que ativa o parâmetro livenessProbe através do seguinte comando:

    kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'

O que se segue?