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:
- Seus processos
mongodjá estão configurados e em execução. - 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:
- Red Hat Linux 8
- Percona Server for MongoDB (PSMDB): 7.0.11-6
- Percona Backup for MongoDB (PBM): 2.5.0
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:
- Você deve configurar o
pbm-agentem todos os nósmongodque armazenam dados no seu cluster.- Isso inclui os nós do Replica Set que atualmente são PRIMARY ou SECONDARIES, bem como os nós do Config Server no caso de um Sharded Cluster.
- Como não possuem o conjunto de dados, não é necessário configurar o
pbm-agentem arbiters oumongoSes.
- A configuração do
pbm-agente domongodfuncionará em uma relação de 1 para 1.- Para cada instância do
mongod, você deve implantar e configurar umpbm-agentcorrespondente.
- Para cada instância do
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 &:
|
1 2 3 |
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:
|
1 |
$ 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:
|
1 2 3 4 |
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:
|
1 |
$ 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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$ 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:
|
1 2 |
$ 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:
|
1 |
$ 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.
- Crie uma função que permita qualquer ação em qualquer recurso:
|
1 2 3 4 5 6 7 8 9 |
db.getSiblingDB("admin").createRole({ "role": "pbmAnyAction", "privileges": [ { "resource": { "anyResource": true }, "actions": [ "anyAction" ] } ], "roles": [] }); |
- Crie o usuário e atribua a função criada:
|
1 2 3 4 5 6 7 8 9 10 11 |
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.
- Primeiro, vamos editar e configurar o arquivo
/etc/sysconfig/pbm-agent:
|
1 |
PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27017/?authSource=admin&replicaSet=replset" |
- Agora, vamos editar e configurar o arquivo
/etc/sysconfig/pbm-agent2:
|
1 |
PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27018/?authSource=admin&replicaSet=replset" |
- Por fim, edite e configure o arquivo
/etc/sysconfig/pbm-agent3:
|
1 |
PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@localhost:27019/?authSource=admin&replicaSet=replset" |
Certifique-se de:
- Usar o usuário criado para o PBM, neste caso,
pbmuser:secretpwd. - Configurar a porta correta para o banco de dados.
- Configurar o nome correto do Replica Set, neste caso,
""replset¨.
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:
pbm-agent: O processo PBM propriamente dito, que já configuramos.pbm-cli: O cliente PBM, uma ferramenta de linha de comando que instrui os pbm-agents a realizar operações como backup, restauração, status, etc.
O cliente PBM conecta-se ao Replica Set via uma string de conexão URI do MongoDB:
|
1 |
$ export PBM_MONGODB_URI="mongodb://pbmuser:[email protected]: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:
- Armazenamento compatível com S3.
- Tipo de armazenamento baseado em sistema de arquivos.
- Armazenamento Microsoft Azure Blob.
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:
|
1 2 |
$ 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.
|
1 2 3 4 |
storage: type: filesystem filesystem: path: /data/local_backups |
3. Carregue o arquivo no PBM por meio do comando do cliente PBM:
|
1 |
$ pbm config --file /etc/pbm_config.yaml |
Saída de exemplo:
|
1 2 3 4 5 6 7 |
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:
|
1 2 3 |
$ 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:
|
1 2 3 |
$ 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:
|
1 2 |
$ 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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# 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!
