Ir para o conteúdo

Configurando o Percona Backup para MongoDB em um Ambiente com Múltiplas Instâncias

Jean da Silva
Updated date:
7 min read

Originally written for Percona Blog in July, 2024 – Configuring Percona Backup for MongoDB in a Multi-Instances Environment

Configurar e gerenciar backups é uma das principais prioridades entre as muitas tarefas que lidamos diariamente em nossas instâncias de banco de dados. Nesse contexto, não é raro encontrar implementações com mais de um processo mongod rodando por nó, criando-se um ambiente de múltiplas instâncias. Embora essa abordagem seja altamente desencorajada devido ao potencial risco de comprometer a disponibilidade do seu negócio, há cenários em que tal configuração faz sentido. Se você possui uma configuração onde um host executa mais de um processo mongod e deseja saber como configurar corretamente o Percona Backup for MongoDB(PBM) nesse ambiente, este artigo o guiará por esse cenário.

Pré-requisitos

Antes de começar, este artigo pressupõe duas condições prévias:

  1. Seus processos mongod já estão configurados e em execução.
  2. Você já instalou o Percona Server for MongoDB (PSMDB) em sua máquina.
    • Caso contrário, siga as instruções de instalação na documentação oficial: PBM – Guia Rápido.

Essas pré-condições são cruciais para manter a objetividade e simplicidade do artigo.

Ambiente:

O ambiente e como você configurou seu nó com múltiplas instâncias podem variar bastante dependendo de seus objetivos. Por exemplo, você pode ter um host com dois processos mongod, enquanto um segundo host mantém mais três. Ou, se você possui um Sharded Cluster, pode distribuir suas instâncias em apenas três hosts. Para eliminar essas infinitas possibilidades, usaremos um único host que contém todo o Replica Set de três nós, conforme ilustrado no diagrama a seguir:

Seja um Replica Set com N nós ou um Sharded Cluster, isso não alterará o resultado deste artigo. Isso ocorre porque, e aqui está o primeiro conselho importante:

Introdução

Para configurar o PBM nesse cenário de ambiente com múltiplas instâncias, existem duas possibilidades:

1. Por meio de um processo em segundo plano usando nohup e &:

nohup pbm-agent --mongodb-uri=mongodb://user:password@127.0.0.1:27017/?authSource=admin&replicaset=replset > /var/log/pbm/pbm-agent.$(hostname -s).27017.log &
nohup pbm-agent --mongodb-uri=mongodb://user:password@127.0.0.1:27018/?authSource=admin&replicaset=replset > /var/log/pbm/pbm-agent.$(hostname -s).27018.log &
nohup pbm-agent --mongodb-uri=mongodb://user:password@127.0.0.1:27019/?authSource=admin&replicaset=replset > /var/log/pbm/pbm-agent.$(hostname -s).27019.log &

2. Ou utilizá-lo por meio do gerenciador de serviços – systemd:

$ sudo systemctl start pbm-agent

Embora a primeira opção pareça mais atraente devido à sua simplicidade, ela não é a melhor escolha, pois carece de controle adequado sobre o próprio processo e outros processos relacionados. O PBM precisa ter controle sobre o processo do mongod em algumas operações, como na restauração, onde o banco de dados é reiniciado várias vezes. Perder o controle de um processo no meio de uma operação, o que pode levar a resultados inconsistentes, não é o que desejamos. Nesse contexto, a abordagem recomendada é implantar arquivos de serviço individuais para o PBM e deixar o systemd gerenciá-los.

How To

1. Configurando o arquivo de serviço

Por padrão, após uma instalação limpa do PBM, o arquivo de serviço correspondente ao processo já é implantado:

systemctl status pbm-agent
 pbm-agent.service - pbm-agent
  Loaded: loaded (/usr/lib/systemd/system/pbm-agent.service; enabled; vendor preset: disabled)
  Active: inactive (dead)

We will use the default pbm-agent.service it to create the copy.

2. Crie um arquivo de serviço modelo que pode ser usado para múltiplas instâncias:
$ sudo cp /usr/lib/systemd/system/pbm-agent.service /usr/lib/systemd/system/pbm-agent@.service

Edite o arquivo de serviço modelo para usar arquivos de ambiente e configurações específicos para cada instância:

$ vi /usr/lib/systemd/system/pbm-agent@.service
[Unit]
Description=pbm-agent para a instância MongoDB %i
After=time-sync.target network.target

[Service]
EnvironmentFile=-/etc/sysconfig/pbm-agent-%i
Type=simple
User=mongod
Group=mongod
PermissionsStartOnly=true
ExecStart=/usr/bin/pbm-agent

[Install]
WantedBy=multi-user.target

O %i no arquivo de serviço será substituído pelo número da instância que será especificado posteriormente, tornando a unidade de serviço específica para aquela instância.

3. Crie arquivos de ambiente para cada instância do PBM e implante-os no sistema

Crie arquivos de ambiente para especificar os detalhes de conexão de cada instância do PBM:

$ sudo cp /etc/sysconfig/pbm-agent /etc/sysconfig/pbm-agent-2
$ sudo cp /etc/sysconfig/pbm-agent /etc/sysconfig/pbm-agent-3

Esses agentes do PBM serão usados para as instâncias mongod-2 e mongod-3. Recarregue o daemon do systemd para reconhecer os novos arquivos de serviço:

$ sudo systemctl daemon-reload
4. Crie um usuário que o PBM utilizará para gerenciar as operações no cluster

Usando a documentação oficial como referência, crie o usuário da seguinte maneira:

Nota: Execute este passo em um nó primário de cada replica set. Em um cluster sharded, isso significa executar em cada replica set de shard e no Config Server replica set.

db.getSiblingDB("admin").createRole({
    "role": "pbmAnyAction",
    "privileges": [
        { "resource": { "anyResource": true },
          "actions": [ "anyAction" ]
        }
    ],
    "roles": []
});
db.getSiblingDB("admin").createUser({
    user: "pbmuser",
    pwd: "secretpwd",
    roles: [
        { db: "admin", role: "readWrite", collection: "" },
        { db: "admin", role: "backup" },
        { db: "admin", role: "clusterMonitor" },
        { db: "admin", role: "restore" },
        { db: "admin", role: "pbmAnyAction" }
    ]
});

Certifique-se de especificar os valores de nome de usuário e senha, além de outras opções do comando createUser, desde que as Roles acima sejam concedidas.

5. Configure a URI de conexão MongoDB para o pbm-agent

Como mencionado no início deste artigo, cada processo pbm-agent conecta-se a um mongod em uma configuração de 1 para 1, em uma conexão do tipo standalone.

PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27017/?authSource=admin&replicaSet=replset"
PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27018/?authSource=admin&replicaSet=replset"
PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27019/?authSource=admin&replicaSet=replset"

Certifique-se de:

Quando os pbm-agents forem inicializados, eles usarão seus respectivos arquivos de ambiente para conectar-se ao banco de dados.

Nota: Estamos usando uma instalação baseada no Red Hat. Para uma instalação baseada no Debian, consulte a documentação oficial para caminhos e nomes de diretórios específicos.

Antes de prosseguir, essa seria a representação atual de nossa configuração:

Seus pbm-agents estão configurados, mas ainda não estão em execução.

6. No próximo passo, configure a URI de conexão para o PBM CLI

Nesta fase, é importante destacar que o PBM é composto por dois componentes:

O cliente PBM conecta-se ao Replica Set via uma string de conexão URI do MongoDB:

$ export PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@127.0.0.1:27017,127.0.0.1:27018,127.0.0.1:27019/?authSource=admin&replicaset=replset"

Como é uma string de conexão de Replica Set, você deve incluir todos os nós que fazem parte dele. Isso é importante para que, caso um nó fique indisponível, o cliente PBM possa detectar e redirecionar automaticamente a conexão para outro nó disponível.

7. Configurando o local de armazenamento do backup

Antes de iniciar o PBM pela primeira vez, é necessário configurar o local de armazenamento. Como o nome sugere, este será o local onde o PBM armazenará seus backups. Os tipos de armazenamento suportados atualmente são:

Ao configurar o local de armazenamento, é crucial que todos os processos mongod possam se conectar ao mesmo endpoint de armazenamento. Nesta demonstração, isso é mais simples porque todo o cluster está hospedado em um único servidor. No entanto, se seus nós estiverem distribuídos em diferentes hosts, eles deverão ter acesso ao armazenamento igualmente, seja via NFS ou armazenamento compatível com S3. Passos para configurar:

1. Crie um arquivo de configuração (por exemplo, pbm_config.yaml) em um caminho acessível pelo PBM:

$ sudo touch /etc/pbm_config.yaml
$ sudo chown mongod. /etc/pbm_config.yaml

2. Especifique as informações de armazenamento no arquivo:

Neste exemplo, simularemos um ponto de montagem NFS, utilizando o tipo de armazenamento baseado em sistema de arquivos. Para mais informações sobre as configurações de armazenamento suportadas, consulte a documentação oficial.

storage:
  type: filesystem
  filesystem:
    path: /data/local_backups

3. Carregue o arquivo no PBM por meio do comando do cliente PBM:

$ pbm config --file /etc/pbm_config.yaml

Saída de exemplo:

pitr:
  enabled: false
  oplogSpanMin: 0
storage:
  type: filesystem
  filesystem:
    path: /data/local_backups

Esse é o resultado final após configurar o cliente PBM.

8. Vamos iniciar os pbm-agents:
$ sudo systemctl start pbm-agent
$ sudo systemctl start pbm-agent@2
$ sudo systemctl start pbm-agent@3

Para monitorar os logs dos serviços, você pode usar o journalctl e passar o identificador de cada serviço:

$ sudo journalctl -u pbm-agent -a -f
$ sudo journalctl -u pbm-agent@2 -a -f
$ sudo journalctl -u pbm-agent@3 -a -f

Você também pode verificar os logs por meio do comando do cliente PBM:

$ pbm logs
$ pbm logs --help ## para mais detalhes

Se tudo ocorrer sem problemas, você verá o PBM reconhecendo o Cluster com sucesso e pronto para operar:

# pbm status
Cluster:
========
replset:
  - replset/127.0.0.1:27018 [S]: pbm-agent v2.5.0 OK
  - replset/127.0.0.1:27017 [P]: pbm-agent v2.5.0 OK
  - replset/127.0.0.1:27019 [S]: pbm-agent v2.5.0 OK
 
PITR incremental backup:
========================
Status [OFF]
 
Currently running:
==================
(none)
 
Backups:
========
FS  /data/local_backups
  (none)

Parabéns, você configurou o PBM em um ambiente com múltiplas instâncias. O diagrama final da nossa configuração seria o seguinte:

O PBM e seus componentes foram implantados com sucesso, conectados e totalmente funcionais com o cluster PSMDB.

Conclusão

Implantar o Percona Backup for MongoDB (PBM) em um ambiente com múltiplas instâncias exige mais etapas e cuidados do que uma instalação regular. No entanto, o artigo acima fornece todos os passos necessários, observações e comandos para garantir uma instalação tranquila e o funcionamento ideal da ferramenta. Se você tiver dúvidas ou encontrar problemas, sinta-se à vontade para compartilhá-los na seção de comentários.   Até mais!

Anterior
Benchmarking MongoDB do 3.6 ao 8.0 - Parte 1
Próximo
MongoDB log e a mensagem - "RSM Not Processing Response”