Clonar um cluster de banco de dados no Kubernetes usando um backup do Cloud Storage

Esta página mostra como clonar um cluster de banco de dados no Kubernetes usando um backup do Cloud Storage de um cluster de banco de dados do AlloyDB Omni.

O fluxo de trabalho a seguir explica as etapas usadas para clonar:

  1. Crie e aplique o arquivo de manifesto DBCluster no cluster de banco de dados de destino com o parâmetro livenessProbe desativado.
  2. Crie e configure o arquivo pgbackrest.conf para acessar o backup do Cloud Storage.
  3. Use comandos pgBackRest para verificar se você pode 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 caminho completo do bucket do Cloud Storage em que o backup do cluster de banco de dados de origem está armazenado. Esse é o mesmo caminho usado quando você criou o recurso BackupPlan para o cluster de banco de dados de origem.
  • Crie um cluster de banco de dados do AlloyDB Omni de destino. Para mais informações sobre como instalar o AlloyDB Omni no Kubernetes, consulte Criar um cluster de banco de dados.
  • Verifique se você fez login no banco de dados como o usuário postgres.

Criar um cluster de banco de dados em um cluster 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 de recursos 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:
    primarySpec:
      availabilityOptions:
        livenessProbe: "Disabled"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DISK_SIZE
          storageClass: standard

    Substitua:

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

    • ENCODED_PASSWORD: a senha de login do banco de dados para a função do usuário postgres padrão, 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 neste cluster de banco de dados.

    • MEMORY_SIZE: a quantidade de memória por instância de banco de dados deste cluster de banco de dados. Recomendamos definir esse valor como 8 gigabytes por CPU. Por exemplo, se você definir cpu como 2 anteriormente neste manifesto, recomendamos definir memory como 16Gi.

    • 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.

Configurar o arquivo pgBackRest

Configure o arquivo pgBackRest para permitir que o cluster de banco de dados de destino acesse o bucket do Cloud Storage onde os backups de origem estão armazenados.

  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=<var>DB_CLUSTER_NAME</var>, 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:

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

    Substitua:

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

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

      supervisorctl.par stop postgres

  4. Crie um arquivo de configuração pgBackRest para acessar os backups armazenados no Cloud Storage:

      cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/obs/pgbackrest
  log-level-file=info
  repo1-type=gcs
  repo1-gcs-bucket=GCS_SOURCE_BACKUP_BUCKET_NAME
  repo1-path=GCS_SOURCE_BACKUP_BUCKET_PATH
  repo1-storage-ca-file=/etc/ssl/certs/ca-certificates.crt
  repo1-retention-full=9999999
  repo1-gcs-key-type=auto

    Substitua:

    • GCS_SOURCE_BACKUP_BUCKET_NAME: o nome do bucket do Cloud Storage que você criou ao criar o arquivo de manifesto de recursos BackupPlan para o cluster de banco de dados de origem. Esse não é o URL completo do bucket. Não use o prefixo gs:// no nome do bucket.
    • GCS_SOURCE_BACKUP_BUCKET_PATH: o caminho do diretório em que o operador do AlloyDB Omni grava backups no bucket do Cloud Storage para o cluster de banco de dados de origem. O caminho precisa ser absoluto e começar com /.

    O repo1-gcs-key-type é definido como auto para usar a conta de serviço da instância. Para mais informações sobre outras opções, consulte Opção de tipo de chave do repositório do GCS.

Verificar 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 destino.

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

Depois de identificar o backup ou um ponto no tempo para o qual você quer restaurar, execute comandos pgBackRest no cluster de banco de dados 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=/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 do banco de dados

Depois de clonar um cluster de banco de dados, configure as especificações dele. O mais importante é não esquecer de ativar o parâmetro livenessProbe com o seguinte comando:

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

A seguir