Esta página documenta a versão 15.5.5 do AlloyDB Omni usando a opção de implantação de contêineres. Escolha outra opção de implantação.

Esta página foi traduzida pela API Cloud Translation.

Clone um cluster de base de dados no Kubernetes através de uma cópia de segurança do Cloud Storage

Selecione uma versão da documentação:

Esta página mostra como clonar um cluster de base de dados no Kubernetes através de uma cópia de segurança do Cloud Storage de um cluster de base de dados do AlloyDB Omni.

O fluxo de trabalho seguinte explica os passos usados para clonar:

Crie e aplique o ficheiro de manifesto DBCluster no cluster da base de dados de destino com o parâmetro livenessProbe desativado.
Crie e configure o ficheiro pgbackrest.conf para aceder à cópia de segurança do Cloud Storage.
Use os comandos pgBackRest para verificar se consegue aceder às cópias de segurança de origem.
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 caminho completo do contentor do Cloud Storage onde está armazenada a cópia de segurança do cluster da base de dados de origem. Este é o mesmo caminho que usou quando criou o recurso BackupPlan para o cluster da base de dados de origem.
Crie um cluster de base de dados AlloyDB Omni de destino. Para mais informações sobre a instalação do AlloyDB Omni no Kubernetes, consulte o artigo Crie um cluster de base de dados.
Certifique-se de que tem sessão iniciada na base de dados como utilizador postgres.

Crie um cluster de base de dados num 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.

Crie o ficheiro 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 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 como 2 anteriormente neste manifesto, recomendamos que defina memory como 16Gi.
- DISK_SIZE: o tamanho do disco por instância da base de dados, por exemplo, 10Gi.
Aplique o ficheiro de manifesto:
```
  kubectl apply -f DBCLUSTER_FILENAME
```
Substitua o seguinte:
- DBCLUSTER_FILENAME: o nome do ficheiro de DBClustermanifesto criado no passo anterior.

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

Configure o ficheiro `pgBackRest`

Configure o ficheiro pgBackRest para permitir que o cluster da base de dados de destino aceda ao contentor do Cloud Storage onde residem as cópias de segurança de origem.

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=<var>DB_CLUSTER_NAME</var>, alloydbomni.internal.dbadmin.goog/task-type=database"
```
A resposta inclui o nome do pod da base de dados do cluster.
Inicie sessão no agrupamento:
```
  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.
Pare o pod antes de atualizar o ficheiro de configuração pgBackRest:
```
  supervisorctl.par stop postgres
```
Crie um ficheiro de configuração pgBackRest para aceder às cópias de segurança armazenadas 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 o seguinte:
- GCS_SOURCE_BACKUP_BUCKET_NAME: o nome do contentor do Cloud Storage que criou quando criou o ficheiro BackupPlan do manifesto de recursos para o cluster da base de dados de origem. Este não é o URL completo do contentor. Não adicione o prefixo gs:// ao nome do contentor.
- GCS_SOURCE_BACKUP_BUCKET_PATH: o caminho do diretório no qual o AlloyDB Omni Operator escreve as cópias de segurança, no contentor do Cloud Storage para o cluster de base de dados de origem. O caminho tem de ser absoluto, começando com /.
O repo1-gcs-key-type está definido como auto para usar a conta de serviço da instância. Para mais informações sobre outras opções, consulte o artigo Tipo de chave do repositório do GCS Opção.

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.

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 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=/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 postgres processo.

supervisorctl.par start postgres

Após o início do processo postgres, 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. Mais importante ainda, não se esqueça de ativar o parâmetro livenessProbe com o seguinte comando:

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

O que se segue?

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

Clone um cluster de base de dados no Kubernetes através de uma cópia de segurança do Cloud Storage Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.