Esta página mostra como clonar um cluster de banco de dados no Kubernetes usando o backup local de um cluster de banco de dados do AlloyDB Omni.
As etapas desta página presumem que os clusters de banco de dados de origem e de destino foram criados no Google Kubernetes Engine e que os discos de backup são discos persistentes do Compute Engine. Também pressupõe que os discos permanentes do Compute Engine usados como backup no banco de dados não são usados por nenhum outro cluster de banco de dados.
O fluxo de trabalho a seguir explica as etapas usadas para clonar:
- Identifique as informações do disco de backup, como o nome do volume persistente e o gerenciador disco permanente do Compute Engine, para o disco de backup do cluster do banco de dados de origem.
- Crie um recurso
PersistentVolume
para usar um disco de backup no cluster de banco de dados de destino e acessar o disco de backup do cluster de banco de dados de origem. - Crie e aplique o arquivo de manifesto de recursos
DBCluster
no cluster de banco de dados de destino com o parâmetrolivenessProbe
desativado e as informações de backup do disco adicionadas. - Use comandos
pgBackRest
para verificar se os backups de origem podem ser acessados. - 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 sobre as etapas para garantir que o disco possa ser montado, consulte Volumes permanentes.
- Como o disco de backup de origem é 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. Os PVCs são usados no Kubernetes para gerenciar o armazenamento permanente de aplicativos.
Os comandos de exemplo a seguir ajudam a localizar o nome do PV e o gerenciador de disco permanente do Compute Engine. No exemplo, todos os discos de backup são discos permanentes do Compute Engine, que podem ser acessados em VMs do Compute Engine usando o identificador do gerenciador de disco.
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 esse plano de backup. Ele precisa corresponder ao namespace do cluster do banco de dados.DB_CLUSTER_NAME
: o nome desse 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
Use o nome do PVC do disco de backup da etapa anterior, por exemplo,
backuprepodisk-my-db-cluster-br-0
, para encontrar o nome do PV e o gerenciador 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
.
Exporte as configurações com base no nome do PV como variáveis a serem usadas nas seções seguintes:
export 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.
Criar um recurso de volume permanente no cluster de banco de dados de destino
Usando o nome do gerenciador de disco, crie um recurso PersistentVolume
.
No cluster de banco de dados de destino, crie o arquivo de manifesto
PersistentVolume
:apiVersion: v1 kind: PersistentVolume metadata: name: backupdisk spec: storageClassName: "${STORAGE_CLASS}" capacity: storage: "${DISK_SIZE}" accessModes: - ReadWriteOnce csi: driver: pd.csi.storage.gke.io volumeHandle: "${VOLUME_HANDLER}" fsType: "${FS_TYPE}"
Aplique o arquivo de manifesto:
kubectl apply -f PV_FILENAME
Substitua:
- PV_FILENAME: o nome do arquivo de manifesto
PersistentVolume
criado na etapa anterior.
- PV_FILENAME: o nome do arquivo de manifesto
Criar um cluster de banco de dados de destino
Crie um cluster de banco de dados desativando temporariamente o parâmetro livenessProbe
enquanto o processo de restauração é concluído.
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: primarySpec: availabilityOptions: livenessProbe: "Disabled" adminUser: passwordRef: name: db-pw-DB_CLUSTER_NAME resources: memory: 100Gi cpu: 10 disks: - name: DataDisk size: 40Gi - name: BackupDisk size: ${DISK_SIZE} storageClass: ${STORAGE_CLASS} volumeName: backupdisk
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áriopostgres
padrão, codificada como uma string base64. Por exemplo,Q2hhbmdlTWUxMjM=
paraChangeMe123
.
Aplique o arquivo de manifesto:
kubectl apply -f DBCLUSTER_FILENAME
Substitua:
- DBCLUSTER_FILENAME: o nome do arquivo de manifesto
DBCluster
criado na etapa anterior.
- DBCLUSTER_FILENAME: o nome do arquivo de manifesto
Use o comando kubectl describe
para verificar se o recurso de cluster de banco de dados está no status READY
.
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.
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.
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 do banco de dados da etapa anterior.
Pare o pod antes de atualizar o arquivo de configuração
pgBackRest
:supervisorctl.par stop postgres
Atualize o arquivo de configuração
pgBackRest
:cp /backup/pgbackrest.conf 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
Verifique os backups de origem no pod do cluster do banco de dados:
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 Comando de restauração.
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.