Backup/restauração do Couchbase no ambiente K8s

1. Introdução

O backup periódico dos dados é uma parte importante de qualquer implantação de banco de dados de produção, o que ajuda a garantir a recuperação dos dados em caso de desastre e também minimiza a inconsistência dos dados quando uma restauração é necessária.

O Couchbase fornece cbbackupmgr que foi aprimorado ao longo dos anos para se tornar uma ferramenta de backup e restauração de nível empresarial para fazer backup de grandes conjuntos de dados com desempenho muito mais alto; portanto, recomendamos que essa ferramenta seja usada na produção. Vale a pena mencionar que, em Servidor Couchbase 6.5 reformulamos completamente o mecanismo de armazenamento de backup e introduzimos uma taxa de compactação mais alta, o que resultou em um desempenho de backup-restauração muito melhor e reduziu os requisitos de armazenamento para cada instantâneo de backup, resultando em economia de custos.

2. Melhores práticas

Embora cbbackupmgr existe em Couchbase_HOME, ele é não Recomenda-se executar esse utilitário em qualquer um dos nós ativos do cluster. Como ele estaria competindo por recursos de solicitações ativas, poderia prejudicar o desempenho do seu sistema de banco de dados.

Portanto, é uma prática recomendada fornecer uma instância separada (para necessidades de backup e restauração) com apenas os binários do Couchbase instalados, mas sem serviços do Couchbase em execução, para que os recursos possam ser mais bem gerenciados para o cluster do banco de dados e o nó de backup.

Como pode ser visto na figura acima, um nó de backup/restauração separado é provisionado além de um cluster do Couchbase de cinco nós. Outra prática recomendada é alocar armazenamento suficiente para manter pelo menos 5x o tamanho do conjunto de dados do Couchbase, de modo que haja espaço suficiente para armazenar os snapshots necessários do banco de dados para atender aos requisitos de Objetivo do ponto de recuperação (RPO) da empresa.

3. Estratégia de backup

cbbackupmgr fornece um conjunto de comandos que permite que os DBAs implementem uma estratégia de backup que atenda melhor às suas necessidades comerciais. Veja a seguir alguns dos comandos:

• cbbackupmgr backup - Faz o backup dos dados de um cluster do Couchbase.
• cbbackupmgr compact - Compacta um backup
• cbbackupmgr merge - Mescla backups
• Configuração do cbbackupmgr - Cria um novo repositório de backup
• Lista cbbackupmgr - Lista os backups no arquivo

Usando esses comandos, é possível implementar qualquer uma das três estratégias de backup mencionadas na seção documentação. No exemplo abaixo, descreveremos Mesclagem periódica no contexto do Couchbase Cluster em execução no ambiente Kubernetes.

4. Mesclagem periódica

Essa estratégia de backup deve ter a menor sobrecarga de banco de dados, pois requer o menor tempo possível para fazer o backup das alterações e praticamente nenhum consumo de recursos do cluster do banco de dados para consolidar os dados durante o processo de compactação e mesclagem (como ocorre no nó de backup).

Em um nível elevado, veja como Mesclagem periódica estratégia funciona:

1. Configurar o repositório de backup usando Configuração do cbbackupmgr
2. Faça um backup incremental do banco de dados (no repositório) usando cbbackupmgr backup
3. Executar a compactação de backup usando cbbackupmgr compact para que o espaço em disco possa ser usado com eficiência.
4. Mesclar os backups mais antigos usando cbbackupmgr merge para que o número de backups no repositório não cresça infinitamente e os requisitos de espaço permaneçam sob controle.

Observação: As etapas acima são capturadas no backup-com-periodic-merge.sh que usaremos posteriormente em nossa configuração do Kubernetes para fazer backups periódicos.

5. Backup dos dados do Couchbase

No meu último blog sobre o Couchbase Autonomous Operator, descrevi passo a passo como como implantar um cluster do Couchbase com autocorreção e alta disponibilidade usando Persistent Volumes. Supondo que você tenha seguido essas etapas e já tenha implantado o cluster, as etapas abaixo descreverão como você pode configurar o recurso de backup automático usando o cronjob. É considerada uma prática recomendada fazer backups regulares dos dados e também testar a restauração de backups para confirmar o processo de restauração antes que a recuperação de desastres seja realmente necessária.

Essa funcionalidade não é fornecida pelo Operador e é deixada para o administrador do cluster definir políticas de backup e testar a restauração de dados. Esta seção descreve alguns padrões comuns que podem ser empregados para executar as funções necessárias.

5.1. Criar classe de armazenamento

As definições de recursos do Kubernetes abaixo ilustram um arranjo típico para backup que salva o estado de todo o cluster. Primeiro, precisaríamos definir o recurso Classe de armazenamento que será formatado usando xfs para obter o melhor desempenho possível.

# Criar classe de armazenamento para operações de backup/restauração
apiVersion: storage.k8s.io/v1
tipo: StorageClass
metadados:
  labels:
    k8s-addon: storage-aws.addons.k8s.io
  nome: gp2-backup-storage
parâmetros:
  type: gp2
  fsType: xfs
provisionador: kubernetes.io/aws-ebs
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

Usando a definição acima em backup-sc.yaml podemos criar uma classe de armazenamento como esta:

$ kubectl create -f backup-sc.yaml -n emart

5.2. Criar volume persistente

Um volume persistente é reivindicado para manter os dados seguros no caso de uma interrupção. Você precisará planejar o tamanho da reivindicação com base no tamanho esperado do conjunto de dados, no número de dias de retenção de dados e se os backups incrementais são usados.

# Definir volume de armazenamento de backup
Tipo: PersistentVolumeClaim
apiVersion: v1
metadados:
  name: backup-pvc
especificações:
  storageClassName: gp2-backup-storage
  recursos:
    requests:
      storage: 50Gi
  accessModes:
    - ReadWriteOnce

Salvar a definição acima em backup-pvc.yaml e criar a reivindicação:

$ kubectl create -f backup-pvc.yaml -n emart

5.3. Configurar o repositório de backup

Antes de começarmos a tirar instantâneos de nossos dados periodicamente, precisamos configurar o local do arquivo de backup. É criado um trabalho para montar o volume persistente e inicializar um repositório de backup. O repositório é denominado couchbase que será mapeado para o nome do cluster em especificações posteriores.

# Criar um repositório de backup
Tipo: Job
apiVersion: batch/v1
metadados:
  name: couchbase-cluster-backup-config
spec:
  template:
    spec:
      contêineres:
        - name: backup-config
          imagem: couchbase/server:enterprise-6.5.0
          comando: ["cbbackupmgr", "config", "--archive", "/backups", "--repo", "couchbase"]
          volumeMounts:
            - nome: "couchbase-cluster-backup-volume"
              mountPath: "/backups"
      volumes:
        - name: couchbase-cluster-backup-volume
          persistentVolumeClaim:
            claimName: backup-pvc
      restartPolicy: Never

Salvar a definição acima em config.yaml e criar um repositório de backup:

$ kubectl create -f config.yaml -n emart

5.3. Executar backup como CronJob

Crie um cronjob conforme descrito na seção periodic-backup.yaml que faz um backup do cluster do Couchbase: a) baixando o script de backup no pod; b) executando o script e fazendo o backup dos dados do cluster usando o volume de armazenamento persistente.

tipo: CronJob
apiVersion: batch/v1beta1
metadados:
  nome: couchbase-cluster-backup-create
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            #Delete o script backup-with-periodic-merge para que um novo script possa ser extraído a cada execução
            - nome: delete-script
              imagem: couchbase/server:enterprise-6.5.0
              comando: ["rm", "/backups/backup-with-periodic-merge.sh"]
              volumeMounts:
                - nome: "couchbase-cluster-backup-volume"
                  mountPath: "/backups"
          initContainers:
            #Baixe o script de backup do repositório git
            - nome: wget-backup-script
              imagem: couchbase/server:enterprise-6.5.0
              comando: ["wget", "https://raw.githubusercontent.com/couchbaselabs/cboperator-hol/master/eks/cb-operator-guide/files/sh/backup-with-periodic-merge.sh", "-P", "/backups/."]
              volumeMounts:
                - nome: "couchbase-cluster-backup-volume"
                  mountPath: "/backups"
            1TP5Altere o mod do script de backup para execução
            - nome: chmod-script
              imagem: couchbase/server:enterprise-6.5.0
              comando: ["chmod", "700", "/backups/backup-with-periodic-merge.sh"]
              volumeMounts:
                - nome: "couchbase-cluster-backup-volume"
                  mountPath: "/backups"
            1TP5Execute o script para que ele possa fazer a) Backup b) Compactação c) Mesclagem com cada snapshot
            - nome: periodic-merge
              imagem: couchbase/server:enterprise-6.5.0
              comando: ["sh", "-c" ,"/backups/backup-with-periodic-merge.sh --cluster cbdemo-srv.emart.svc"]
              volumeMounts:
                - name: "couchbase-cluster-backup-volume"
                  mountPath: "/backups"
          volumes:
            - name: couchbase-cluster-backup-volume
              persistentVolumeClaim:
                claimName: backup-pvc
          restartPolicy: Never

No YAML acima, estamos executando o backup a cada 5 minutos, mas você pode alterar a frequência para que ele possa atender ao RPO da sua empresa. Como nosso cluster do Couchbase está implantado no namespace emart portanto, implantaremos o cronjob de backup no mesmo namespace:

$ kubectl apply -f periodic-backup.yaml -n emart

cronjob.batch/couchbase-cluster-backup-create created

5.4 Validar trabalho de backup periódico

Nesse ponto, você pode começar a observar o cronjob entrando em ação a cada 5 minutos. E assim que ele se tornar ativo, executará três initContainers (wget-backup-script, chmod-script, periodic-merge) em ordem sequencial, seguidos pelos comandos contêineres (script de exclusão):

$ kubectl get pods -n emart -w

NOME READY STATUS RESTARTS AGE
backup-node 1/1 Em execução 0 1d
cbdemo-0000 1/1 Em execução 0 5d
cbdemo-0001 1/1 Em execução 0 5d
cbdemo-0002 1/1 Em execução 0 5d
cbdemo-0003 1/1 Em execução 0 5d
cbdemo-0004 1/1 Em execução 0 5d
couchbase-operator-7654d844cb-gn4bw 1/1 Em execução 0 5d
couchbase-operator-admission-7ff868f54c-5pklx 1/1 Em execução 0 5d

couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Pendente 0 2s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Pendente 0 2s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:0/3 0 2s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:1/3 0 3s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:2/3 0 4s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Init:2/3 0 6s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 PodInitializing 0 27s
couchbase-cluster-backup-create-1580357820-tz2hg 0/1 Concluído 0 30s

Você pode visualizar os registros de cada initContainers depois que o pod exibir o status Concluído. O initContainers em que estamos interessados é chamado de mesclagem periódica:

$ kubectl logs couchbase-cluster-backup-create-1580357820-tz2hg -n emart -c periodic-merge


---------------------------------------------------------
INICIAR ETAPA 1: BACKUP : Thu Jan 30 04:17:12 UTC 2020
Executando o backup...
 Comando: cbbackupmgr backup --archive /backups --repo couchbase --cluster couchbase://cbdemo-srv.emart.svc --username Administrator --password password --threads 2
Aviso: Barra de progresso desativada porque a largura do terminal é menor que 80 caracteres
Backup concluído com êxito
O backup do bucket "gamesim-sample" foi bem-sucedido
Mutações com backup; 586, Mutações com falha no backup: 0
Foi feito o backup das exclusões: 0, Falha no backup das exclusões: 0
O backup do bucket "travel-sample" foi bem-sucedido
Mutações com backup; 0, Mutações com falha no backup: 0
Foi feito o backup das exclusões: 0, Falha no backup das exclusões: 0
---------------------------------------------------------
INICIAR ETAPA 2: COMPACTAÇÃO : Thu Jan 30 04:17:20 UTC 2020
Lista de snapshots de backup ...

2020-01-28T23_01_37.592188562Z
2020-01-28T23_03_34.160387835Z
2020-01-28T23_05_08.103740281Z
2020-01-30T04_17_12.702824188Z
O nome do último backup é: 2020-01-30T04_17_12.702824188Z
Compactando o backup...
 Comando: cbbackupmgr compact --archive /backups --repo couchbase --backup 2020-01-30T04_17_12.702824188Z
Compactação bem-sucedida, 0 bytes liberados
---------------------------------------------------------
INICIAR ETAPA 3: mesclando o backup antigo: Thu Jan 30 04:17:24 UTC 2020

 Tamanho Itens Nome
 604,93 MB - + couchbase
 192.00MB - + 2020-01-28T23_01_37.592188562Z
 192.00MB - + amostra de cerveja
 37B 0 analytics.json
 414B 0 bucket-config.json
 192,00 MB 7303 + dados
 192,00MB 7303 1024 fragmentos
 2B 0 full-text.json
 1.94KB 1 gsi.json
 784B 1 views.json
 192.02MB - + 2020-01-28T23_03_34.160387835Z
 192.02MB - + travel-sample
 0B 0 analytics.json
 416B 0 bucket-config.json
 192,00 MB 31591 + dados
 192,00MB 31591 1024 fragmentos
 2B 0 full-text.json
 15.57KB 10 gsi.json
 2B 0 views.json
 64.02MB - + 2020-01-28T23_05_08.103740281Z
 64.02MB - + travel-sample
 0B 0 analytics.json
 416B 0 bucket-config.json
 64,00 MB 0 + dados
 64,00MB 0 1024 fragmentos
 2B 0 full-text.json
 15.57KB 10 gsi.json
 2B 0 views.json
 156.89MB - + 2020-01-30T04_17_12.702824188Z
 92.88MB - + gamesim-sample
 0B 0 analytics.json
 417B 0 bucket-config.json
 92,88 MB 586 + dados
 92,88 MB 586 1024 fragmentos
 2B 0 full-text.json
 1.95KB 1 gsi.json
 501B 1 views.json
 64,02 MB - + amostra de viagem
 0B 0 analytics.json
 416B 0 bucket-config.json
 64,00MB 0 + dados
 64,00 MB 0 1024 fragmentos
 2B 0 full-text.json
 15.57KB 10 gsi.json
 2B 0 views.json
Início 2020-01-28T23_01_37.592188562Z, FIM 2020-01-28T23_03_34.160387835Z
Mesclando backups antigos...
 Comando: cbbackupmgr merge --archive /backups --repo couchbase --start 2020-01-28T23_01_37.592188562Z --end 2020-01-28T23_03_34.160387835Z

A mesclagem foi concluída com êxito

Tamanho Itens Nome
 412.92MB - + couchbase
 192.02MB - + 2020-01-28T23_03_34.160387835Z
 192.02MB - + travel-sample
 37B 0 analytics.json
 416B 0 bucket-config.json
 192,00 MB 31591 + dados
 192,00 MB 31591 1024 fragmentos
 2B 0 full-text.json
 15.57KB 10 gsi.json
 2B 0 views.json
 64.02MB - + 2020-01-28T23_05_08.103740281Z
 64.02MB - + travel-sample
 0B 0 analytics.json
 416B 0 bucket-config.json
 64,00 MB 0 + dados
 64,00MB 0 1024 fragmentos
 2B 0 full-text.json
 15.57KB 10 gsi.json
 2B 0 views.json
 156.89MB - + 2020-01-30T04_17_12.702824188Z
 92.88MB - + gamesim-sample
 0B 0 analytics.json
 417B 0 bucket-config.json
 92,88 MB 586 + dados
 92,88 MB 586 1024 fragmentos
 2B 0 full-text.json
 1.95KB 1 gsi.json
 501B 1 views.json
 64,02 MB - + amostra de viagem
 0B 0 analytics.json
 416B 0 bucket-config.json
 64,00MB 0 + dados
 64,00 MB 0 1024 fragmentos
 2B 0 full-text.json
 15.57KB 10 gsi.json
 2B 0 views.json

Observação: como pode ser visto nos registros acima, antes da etapa de mesclagem, havia quatro backups disponíveis e, após a mesclagem, há três instantâneos de backup que são chamados de PONTOS DE RESTAURAÇÃO em backup-com-periodic-merge.sh roteiro.

Isso conclui a seção de backup.

6. Restauração

Assim como em um backup, podemos restaurar os dados em um novo cluster do Couchbase com um Kubernetes Job.

Tipo: Job
apiVersion: batch/v1
metadados:
  nome: couchbase-cluster-restore
spec:
  template:
    spec:
      contêineres:
        - nome: couchbase-cluster-restore
          imagem: couchbase/server:enterprise-6.0.2
          comando: ["cbbackupmgr", "restore", "--archive", "/backups", "--repo", "couchbase", "--cluster", "couchbase://cbdemo-srv.emart.svc", "--username", "Administrator", "--password", "password"]
          volumeMounts:
            - name: "couchbase-cluster-backup-volume"
              mountPath: "/backups"
      volumes:
        - name: couchbase-cluster-backup-volume
          persistentVolumeClaim:
            claimName: backup-pvc
      restartPolicy: Never

Se preferir criar um pod de backup-restauração temporário para ver quais backups estão disponíveis ou para solucionar um problema, você pode montar o mesmo pod persistentVolumeClaim para um novo pod. Aqui está a definição do pod que pode ser armazenada em backup-pod.yaml:

apiVersion: v1
Tipo: Pod
metadados:
  nome: backup-node
spec:  Especificação # do conteúdo do pod
  contêineres:
    - nome: backup-pod
      imagem: couchbase/server:enterprise-6.5.0
      # Apenas gire e espere para sempre
      comando: [ "/bin/bash", "-c", "--" ]
      args: [ "while true; do sleep 30; done;" ]
      volumeMounts:
        - name: "couchbase-cluster-backup-volume"
          mountPath: "/backups"
  volumes:
    - name: couchbase-cluster-backup-volume
      persistentVolumeClaim:
        claimName: backup-pvc
  restartPolicy: Never

Execute o kubectl para abrir o pod temporariamente:

$ kubectl apply -f br/backup-pod.yaml -n emart
$ kubectl get pods -n emart

NOME READY STATUS RESTARTS AGE
backup-node 1/1 Em execução 0 3d1h
cbdemo-0000 1/1 Em execução 0 7d1h
cbdemo-0001 1/1 Em execução 0 7d1h
cbdemo-0002 1/1 Em execução 0 7d1h
cbdemo-0003 1/1 Em execução 0 7d1h
cbdemo-0004 1/1 Em execução 0 7d1h
couchbase-operator-7654d844cb-gn4bw 1/1 Em execução 0 7d2h
couchbase-operator-admission-7ff868f54c-5pklx 1/1 Em execução 0 7d2h

Quando o nó de backup estiver em execução, poderemos fazer login nesse pod:

$ kubectl exec -it backup-node -n emart -- /bin/bash

root@backup-node:/

E executar Lista cbbackupmgr para visualizar os backups existentes:

# cbbackupmgr list --repo couchbase --archive /backups

Tamanho Itens Nome
256.04MB - + couchbase
0B - + 2020-01-30T04_17_12.702824188Z
0B - + gamesim-sample
0B 0 analytics.json
0B 0 + dados
0B 0 Erro: não foram encontrados fragmentos de dados
0B 0 full-text.json
0B 0 gsi.json
0B 0 views.json
128.02MB - + 2020-01-30T04_18_13.021340423Z
....

E você também pode executar cbbackupmgr restore manualmente:

# cbbackupmgr restore --archive /backups --repo couchbase --cluster couchbase://cbdemo-srv.emart.svc --username Administrator --password password

Quando terminar de restaurar, basta excluir o pod:

$ kubectl delete -f backup-pod.yaml -n emart

7. Conclusão

Explicamos passo a passo como é possível configurar um cronjob de backup, que automatiza o processo de fazer o backup periódico em um intervalo predefinido. Usamos um backup-com-periodic-merge.sh que executa a) backup, b) compactação e c) mesclagem em um único script. Esse script foi então usado no periodic-backup.yaml que automatizou o processo de fazer backup no ambiente do Kubernetes. Esperamos que você use as práticas recomendadas descritas neste blog e planeje fazer backups regulares, bem como validar esses backups usando o comando restore regularmente.