Clonar um cluster de banco de dados no Kubernetes usando um backup local

Selecione uma versão da documentação:

Neste documento, descrevemos como clonar um cluster de banco de dados no Kubernetes usando um backup local de um cluster de banco de dados do AlloyDB Omni.

Neste documento, partimos das seguintes premissas:

  • Os clusters de banco de dados de origem e de destino são criados no Google Kubernetes Engine, e os discos de backup são discos permanentes do Compute Engine.
  • Os discos permanentes do Compute Engine usados como disco de backup no banco de dados não são usados por outros clusters de banco de dados.

Ao clonar um cluster de banco de dados, siga estas etapas:

  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. Verifique se você ativou o recurso de backup para o cluster de banco de dados de origem e se tem pelo menos um backup bem-sucedido. Se essas condições não forem atendidas, siga as instruções em Ativar e programar backups.
  2. Crie um recurso PersistentVolume para usar um disco de backup existente no cluster de banco de dados de destino e acessar o disco de backup do cluster de banco de dados de origem.
  3. Crie e aplique o arquivo de manifesto de recursos DBCluster no cluster de banco de dados de destino com o parâmetro livenessProbe desativado e as informações do disco de backup adicionadas.
  4. Use comandos pgBackRest para verificar se é possível acessar os backups de origem.
  5. 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.
  • O disco de backup do cluster de banco de dados de origem precisa ser montado no cluster de banco de dados de destino. Para mais informações, consulte Volumes permanentes. Se o back-end de armazenamento subjacente não for compatível com o acesso ReadOnlyMany (ROX), verifique se o disco de backup não está sendo usado por nenhum pod no cluster de origem.
  • Como o disco de backup de origem está montado no cluster de banco de dados de destino, o arquivo pgBackRest.conf é reutilizado como está.
  • 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 localizar o nome do PV subjacente e o manipulador do disco permanente do Compute Engine. No exemplo, todos os discos de backup são discos permanentes do Compute Engine, que podem ser acessados em todas as VMs do Compute Engine usando o identificador do manipulador de disco.

  1. Conecte-se ao cluster de banco de dados de destino para encontrar o nome do PVC:

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

    Substitua:

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

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

  2. Use o nome da PVC do disco de backup da etapa anterior, por exemplo, backuprepodisk-my-db-cluster-br-0, para encontrar o nome do PV subjacente e o manipulador de disco permanente do Compute Engine:

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

  3. Exporte as configurações com base no nome do PV como variáveis a serem usadas nas seçõ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:

    • PV_NAME: o nome do PV do disco de backup da resposta na etapa anterior. Por exemplo, "backupDiskVolume".

Criar um recurso de volume permanente

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

  1. No cluster de destino do Kubernetes, crie o arquivo 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:

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

  2. Aplique o arquivo de manifesto:

      kubectl apply -f PV_FILENAME

    Substitua:

    • PV_FILENAME: o nome do arquivo de manifesto PersistentVolume criado na etapa anterior.

Criar um cluster de banco de dados de destino

Crie um cluster de banco de dados desativando temporariamente o parâmetro livenessProbe. Depois que a restauração for concluída, reconfigure o parâmetro livenessProbe.

  1. Crie o arquivo 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: "16.8.0"
    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:

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

    • ENCODED_PASSWORD: a senha de login do banco de dados para a função de usuário padrão postgres, codificada como uma string base64. Por exemplo, Q2hhbmdlTWUxMjM= para ChangeMe123.

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

    • MEMORY_SIZE: a quantidade de memória por instância de banco de dados deste cluster de banco de dados. Recomendamos definir isso como 8 gigabytes por CPU. Por exemplo, se você definir CPU_COUNT como 2, recomendamos que defina memory como 16Gi.

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

  2. Aplique o arquivo de manifesto:

      kubectl apply -f DBCLUSTER_FILENAME

    Substitua:

    • DBCLUSTER_FILENAME: o nome do arquivo de manifesto DBCluster criado na etapa anterior.

Use o comando kubectl describe para verificar se o recurso de cluster de banco de dados está no status READY.

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

Execute comandos pgBackRest para verificar se os backups do cluster de banco de dados de origem estão acessíveis no cluster de banco de dados de destino.

  1. No cluster de banco de dados de destino, encontre os detalhes do pod do cluster de banco 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 do banco de dados do cluster.

  2. Faça login no pod do banco de dados:

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

    Substitua:

    • DATABASE_POD_NAME : o nome do pod do cluster de banco de dados da etapa anterior.

  3. Interrompa o pod antes de atualizar o arquivo de configuração pgBackRest:

      supervisorctl.par stop postgres

  4. Atualize o arquivo 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. Verifique os backups de origem no pod do cluster de banco de dados:

    pgbackrest --config-path=/backup --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 cluster de banco de dados de destino

Depois de identificar o backup ou um momento específico para restauração, execute os comandos pgBackRest no cluster de banco de dados 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=/backup --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=/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

Reiniciar o pod

Depois que o comando de restauração for concluído, você poderá iniciar o processo postgres.

supervisorctl.par start postgres

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

Configurar o cluster de banco de dados

Depois de clonar um cluster de banco de dados, configure as especificações dele. Não se esqueça de ativar o parâmetro livenessProbe usando o seguinte comando:

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

A seguir