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.

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

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.

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

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.

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

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.

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:

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):

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:

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.

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:

Execute o kubectl para abrir o pod temporariamente:

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

E executar Lista cbbackupmgr para visualizar os backups existentes:

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

Quando terminar de restaurar, basta excluir o pod:

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.