Recuperação e manutenção

Neste capítulo, você entenderá alguns métodos avançados de solução de problemas. Muitos destes procedimentos serão executados em uma instância senhasegura na camada do sistema operacional. Você pode ter acesso a todos os manuais de tecnologia explicados aqui. Mas lembre-se que a equipe de desenvolvimento do senhasegura mudou a configuração padrão de todos estes softwares para uma experiência mais segura. Não altere nenhum parâmetro por si mesmo. Ligue para nossa equipe de suporte, se necessário.

Reconciliação do cluster senhasegura

senhasegura usa o MariaDB Galera Cluster como tecnologia de cluster de alta disponibilidade de banco de dados. Esta seção explicará os cenários indisponíveis e os passos para a recuperação com segurança.

Primeiro, vamos explicar um pouco sobre como o MariaDB Galera Cluster sincroniza os dados.

Uma breve explicação sobre as diferenças entre o SST e o IST

A reconciliação de dados com a SST¹ é feita através da transferência de um conjunto de dados completo de um membro do nó para outro.

Portanto, a reconciliação de dados usando IST² é feita comparando as transações ausentes entre nós, sincronizando apenas os dados ausentes entre nós, em vez de sincronizar todo o banco de dados.

Em um cenário sob controle, é melhor usar o IST em vez do SST, para um melhor desempenho.

Reconciliação de dados dentro do senhasegura

Normalmente, em cenários de interrupção temporária da replicação de dados entre nós de cluster com configurações padrão, há uma tolerância de aproximadamente 3 horas de interrupção em que o cluster só precisa de um IST para resolver a reconciliação, ou seja, apenas enviar os dados incrementais. Neste caso, nenhuma intervenção é necessária, pois o cluster resolve o problema da reconciliação automaticamente.

Paradas mais longas geralmente requerem uma transferência de dados completa (SST).

Na maioria dos casos, o cluster senhasegura é suficientemente resiliente e inteligente para resolver a reconciliação realizando um SST automaticamente. Somente em alguns casos é necessária a intervenção da equipe de apoio para garantir a integridade dos dados, executando um SST manualmente.

Intervenção manual para realizar um SST no cluster

Primeiro passo. Verificar o status da sincronização fazer o login no banco de dados e verificar o controle das seguintes variáveis:

SHOW GLOBAL STATUS LIKE 'wsrep_connected'; 
SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status'; 
SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment'; 

Olhando para a documentação oficial do Galera Cluster:

• wsrep_connected: mostra se o nó tem conectividade de rede com qualquer outro nó;

• wsrep_cluster_status: mostra o status primário do componente de cluster em que o nó está, que você pode usar para determinar se seu cluster está experimentando uma partição;

• wsrep_local_state_comment: mostra o estado do nó em um formato legível para humanos;

Primeiros passos no nó primário (doador de dados)

1. Parar o processo MariaDB;

   sudo systemctl stop mariadb.service 

2. Desativar a replicação mudando o arquivo de configuração galera.cnf;

3. Editar o arquivo de configuração /etc/mysql/conf.d/galera.cnf;

4. Localize o parâmetro wsrep_on e mude o valor para OFF

5. Salvar o arquivo e saia do editor;

6. Elimine os antigos arquivos de controle de cluster;

7. sudo rm /var/lib/mysql/galera.cache;

8. sudo rm /var/lib/mysql/grastate.dat;

9. sudo rm /var/lib/mysql/multimaster.info;

10. Iniciar o processo MariaDB;

    sudo systemctl start mariadb.service 

Primeiros passos no nó secundário (joiner)

1. Parar o processo MariaDB;

   sudo systemctl stop mariadb.service 

2. Renomear a pasta de dados do banco de dados atual para uma finalidade de backup;

   sudo mv /var/lib/mysql /var/lib/mysql-$(date +%d%m%y%H%M) 

3. Criar uma nova pasta de dados do banco de dados;

   sudo install -d /var/lib/mysql -o mysql -g mysql 

Segundo passo no nó primário (doador de dados)

1. Parar o processo MariaDB;

   sudo systemctl stop mariadb.service 

2. Habilitar a replicação:

3. Editar o arquivo de configuração /etc/mysql/conf.d/galera.cnf;

4. Localize o parâmetro wsrep_on e mude seu valor para ON

5. Salvar o arquivo e sair do editor;

6. Em outro terminal, mantenha sua atenção nos logs do banco de dados:

   sudo tailf /var/log/mysql/mysql-error.log 

7. Recriar o cluster;

   sudo galera_new_cluster 

8. Aguardar a inicialização completa;

Segundo passo no nó secundário (joiner)

1. Confirmar se a replicação está habilitada no arquivo de configuração galera.cnf;

2. Editar o arquivo de configuração /etc/mysql/conf.d/galera.cnf;

3. Editar o arquivo de configuração /etc/mysql/conf.d/galera.cnf

4. Salvar o arquivo e sair do editor;

5. Em outro terminal, mantenha sua atenção nos logs do banco de dados:

   sudo tailf /var/log/mysql/mysql-error.log 

6. Iniciar o processo MariaDB;

   sudo systemctl start mariadb.service 

7. Verificar se o número de membros do cluster está correto no log de banco de dados (por exemplo: se houver 2 membros, a mensagem members = 2/2(joined/total) deve ser impressa);

8. Verifique se a confirmação da sincronização aparece

   WSREP: Member 0.0 (vsrv-senhasegura-cert05) synced with group.

Status de aplicação e serviços

Todos os serviços utilizados pela plataforma senhasegura podem ser gerenciados pela linha de comando orbit. Esta poderosa ferramenta tem seu próprio manual. Confira todos os comandos disponíveis para uma melhor experiência de administração do senhasegura .

Por enquanto, explicaremos as sequências de comandos mais comuns para reiniciar seus serviços básicos.

Reiniciando a instância principal

Uma instância primária é uma instância que centraliza a execução de todos os serviços. E também usada como membro primário do esquema de cluster.

Você pode verificar como a instância é configurada usando o comando orbit status.

Para mudar uma instância para o uso primário e ativá-la, use a seguinte sequência de comandos para garantir um uso correto:

1. sudo orbit application stop;

2. sudo orbit application master;

3. sudo orbit application start;

4. sudo orbit proxy fajita restart;

5. sudo orbit proxy rdpgate restart;

O orbit application stop e o orbit application start também reiniciarão os serviços básicos de servidor web NGINX e PHP-FPM.

Reinicialização dos serviços Linux

Todos os serviços podem ser reiniciados usando a interface de comando orbit.

Use o comando sudo orbit service para reiniciar um serviço linux.

Preste muita atenção ao status dos seguintes serviços. Você pode reiniciá-lo por si mesmo se uma parada inesperada do serviço acontecer.

• nginx: Serviço de servidor Web. Se for reiniciado, reinicie também o serviço php-fpm;

• php-fpm: Serviço PHP Wrapper;

• mariadb: Serviço de banco de dados;

• docker: Serviço de isolamento de proxy;

• wazuh-manager: Serviço HIDS;

IP bloqueado por HIDS

Se um IP foi bloqueado pelo HIDS, você pode desbloquear o IP usando o comando orbit firewall.

1. sudo orbit firewall –show

2. sudo orbit firewall unblock –host=[blocked IP]

Reiniciando o ambiente de cluster

Em um ambiente de cluster você deve reiniciar ou encerrar as instâncias na ordem correta para evitar problemas.

Use o sudo orbit shutdown em membros do cluster, uma instância de cada vez, esperando o encerramento completo para iniciar o processo em outro membro.

Fazendo isso, os membros disponíveis do grupo entenderão que os membros estão caindo. Mantenha o nó primário para ser o último a ser fechado.

---

1. State Snapshot Transfer↩
2. Incremental State Transfer↩