Operação e alta disponibilidade do MariaDB

Introdução

Nos dois posts anteriores, instalamos o MariaDB, aprendemos o gerenciamento do dia a dia e organizamos o acesso com segurança. Com isso, o banco está pronto para entrar em produção. Mas é justamente a partir daí que começa a parte mais longa do trabalho: manter o banco funcionando bem, semana após semana.

Em produção, as perguntas mudam. Não é mais "como eu crio um usuário?", e sim "o banco está saudável agora?", "por que esta tela ficou lenta?", "se o servidor parar hoje, quanto eu perco?" e "como eu atualizo sem derrubar a aplicação?". Este post responde a essas perguntas, em seis partes:

• Monitoramento: como saber se o MariaDB está saudável antes que alguém reclame.

• Ajustes de desempenho: as poucas configurações que realmente fazem diferença, e como medir antes e depois de mudar.

• Backups automáticos com o mariadb-backup: cópias rápidas do banco inteiro, agendadas, com retenção e teste de restore.

• Atualização de versão: como atualizar com segurança e como voltar atrás se algo der errado.

• Replicação: um segundo servidor com uma cópia do banco atualizada o tempo todo.

• Checklist de operação: a rotina resumida, para revisar o seu ambiente.

Como nos posts anteriores, os comandos foram escritos para o MariaDB 10.11 ou mais recente e funcionam no Debian, no Rocky Linux e no Oracle Linux. Quando houver diferença entre as distribuições, ela aparece indicada no texto. Para a parte de replicação, você vai precisar de dois servidores com o MariaDB instalado; duas VMs no seu laboratório são suficientes.

Monitoramento

Monitorar é saber o que está acontecendo com o banco antes que um usuário ligue reclamando. Não é preciso começar com uma ferramenta grande: o próprio MariaDB já mostra quase tudo o que importa.

Uma olhada rápida

O mariadb-admin responde em segundos se o servidor está no ar e mostra um resumo do uso:

# O servidor responde?

sudo mariadb-admin ping

# Resumo: tempo no ar, conexões, consultas lentas, consultas por segundo

sudo mariadb-admin status

Os indicadores que importam

O MariaDB guarda centenas de contadores, mas poucos contam a história principal. No prompt do MariaDB:

SHOW GLOBAL STATUS WHERE Variable_name IN (

  'Uptime',

  'Threads_connected',

  'Max_used_connections',

  'Aborted_connects',

  'Slow_queries',

  'Innodb_buffer_pool_read_requests',

  'Innodb_buffer_pool_reads'

);

Para comparar, veja também o limite de conexões configurado:

SHOW VARIABLES LIKE 'max_connections';

Como ler o resultado:

• Uptime: segundos desde o último início. Se esse número voltar a ficar pequeno sem que ninguém tenha reiniciado o serviço, o MariaDB caiu e subiu de novo; o log de erros vai mostrar o motivo.

• Threads_connected e Max_used_connections: conexões agora e o pico desde o início. Se o pico chegar perto do max_connections, a aplicação vai começar a receber erros de "Too many connections".

• Aborted_connects: tentativas de conexão que falharam. Um número que cresce rápido costuma indicar senha errada configurada em algum lugar ou alguém tentando adivinhar senhas.

• Slow_queries: consultas que passaram do tempo limite configurado. Veja o log de consultas lentas, logo abaixo.

• Innodb_buffer_pool_reads e Innodb_buffer_pool_read_requests: mostram quanto o banco precisa ler do disco. Divida o primeiro pelo segundo: o resultado deve ficar abaixo de 1%. Se ficar acima, falta memória para o banco, assunto da próxima seção.

O log de erros

É o primeiro lugar para olhar quando o serviço não sobe ou cai sozinho:

# Debian

sudo journalctl -u mariadb --no-pager -n 100

# Rocky Linux / Oracle Linux

sudo tail -n 100 /var/log/mariadb/mariadb.log

O log de consultas lentas

Quando a aplicação fica lenta, quase sempre a causa é um pequeno número de consultas. O log de consultas lentas registra todas as que passam de um tempo limite. Ative-o no arquivo de configuração:

# Debian:                      /etc/mysql/mariadb.conf.d/50-server.cnf

# Rocky Linux / Oracle Linux:  /etc/my.cnf.d/mariadb-server.cnf

[mysqld]

slow_query_log      = ON

long_query_time     = 2

slow_query_log_file = /var/log/mysql/mariadb-slow.log

# Rocky Linux / Oracle Linux: /var/log/mariadb/mariadb-slow.log

Reinicie o serviço para aplicar:

sudo systemctl restart mariadb

Com long_query_time = 2, toda consulta que levar mais de 2 segundos é registrada. Depois de um ou dois dias de uso normal, o mariadb-dumpslow agrupa as consultas parecidas e mostra as que mais pesam:

# As 10 consultas que mais tempo consumiram no total

sudo mariadb-dumpslow -s t -t 10 /var/log/mysql/mariadb-slow.log

Em algumas instalações o comando se chama mysqldumpslow. Com a lista em mãos, a conversa com quem desenvolve a aplicação fica objetiva: "estas três consultas respondem por 80% do tempo do banco".

Uma verificação automática

Para não depender de alguém lembrar de olhar, um script simples pode rodar a cada 5 minutos e registrar o resultado no log do sistema. Se você usa um SIEM ou uma ferramenta de monitoramento que coleta o log do sistema, como o Wazuh, os alertas passam a aparecer lá automaticamente.

Crie o script em /usr/local/bin/mariadb-check.sh:

#!/bin/bash

# Verificação simples de saúde do MariaDB

# Resultado gravado no log do sistema com a etiqueta mariadb-check

if ! mariadb-admin ping --silent; then

  logger -t mariadb-check -p daemon.err "MariaDB nao responde"

  exit 1

fi

CONN=$(mariadb -N -B -e "SHOW GLOBAL STATUS LIKE 'Threads_connected'" | awk '{print $2}')

MAX=$(mariadb -N -B -e "SELECT @@max_connections")

USO=$(( CONN * 100 / MAX ))

if [ "$USO" -ge 80 ]; then

  logger -t mariadb-check -p daemon.warning "Conexoes em $USO% ($CONN de $MAX)"

else

  logger -t mariadb-check -p daemon.info "OK: $CONN de $MAX conexoes"

fi

Deixe o script executável só pelo root:

sudo chmod 700 /usr/local/bin/mariadb-check.sh

Para rodar o script a cada 5 minutos, vamos usar um timer do systemd, que registra cada execução no log e é mais fácil de acompanhar do que o cron. Crie o serviço em /etc/systemd/system/mariadb-check.service:

[Unit]

Description=Verificacao de saude do MariaDB

[Service]

Type=oneshot

ExecStart=/usr/local/bin/mariadb-check.sh

E o timer em /etc/systemd/system/mariadb-check.timer:

[Unit]

Description=Verificacao do MariaDB a cada 5 minutos

[Timer]

OnBootSec=2min

OnUnitActiveSec=5min

[Install]

WantedBy=timers.target

Ative o timer e confira o resultado:

sudo systemctl daemon-reload

sudo systemctl enable --now mariadb-check.timer

# Próximas execuções

systemctl list-timers mariadb-check.timer

# Resultados registrados

journalctl -t mariadb-check --no-pager -n 20

O script roda como root e entra no MariaDB pelo unix_socket, sem senha guardada em arquivo.

Ajustes de desempenho

O MariaDB vem configurado para rodar em qualquer máquina, inclusive em servidores pequenos. Por isso, em um servidor dedicado, algumas configurações ficam bem abaixo do que o hardware permite. A boa notícia é que poucas configurações fazem quase toda a diferença.

Antes de mexer, duas regras:

• Meça antes e depois. Anote os indicadores da seção de monitoramento antes de mudar algo, para saber se a mudança ajudou.

• Mude uma coisa de cada vez. Se você mudar cinco configurações juntas e o desempenho piorar, não vai saber qual foi a culpada.

Memória para o InnoDB: innodb_buffer_pool_size

É a configuração mais importante. O InnoDB, o mecanismo de armazenamento padrão do MariaDB, guarda dados e índices nessa área de memória. Quanto mais do banco couber nela, menos o servidor precisa ler do disco. Para ver o valor atual, em MB:

SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS buffer_pool_mb;

O padrão é de apenas 128 MB. Como referência:

• Servidor dedicado ao MariaDB: de 50% a 70% da memória total.

• Servidor dividido com a aplicação (cenário 1 do post anterior): de 25% a 40%, deixando memória para o servidor web e o PHP.

• Não passe do tamanho total dos bancos: se todos os dados somam 2 GB, um buffer pool de 16 GB não traz ganho.

Para saber o tamanho dos bancos:

SELECT table_schema AS banco,

       ROUND(SUM(data_length + index_length) / 1024 / 1024) AS tamanho_mb

FROM information_schema.tables

GROUP BY table_schema;

Conexões: max_connections

O padrão é 151 conexões simultâneas. Só aumente se o Max_used_connections da seção de monitoramento chegar perto desse número. Cada conexão consome memória, e um valor alto demais pode esgotar a memória do servidor em um pico de acesso. Muitas vezes, o problema real é a aplicação, que abre conexões e não fecha.

Log de transações: innodb_log_file_size

Em bancos com muitas gravações, um log de transações maior reduz o trabalho de disco. O padrão de 96 MB é suficiente para a maioria dos casos; em bancos com escrita intensa, 512 MB ou 1 GB costumam funcionar melhor. A mudança só vale depois de reiniciar o serviço.

Juntando tudo

Exemplo para um servidor com 8 GB de memória, dedicado ao MariaDB:

# Debian:                      /etc/mysql/mariadb.conf.d/50-server.cnf

# Rocky Linux / Oracle Linux:  /etc/my.cnf.d/mariadb-server.cnf

[mysqld]

innodb_buffer_pool_size = 4G

max_connections         = 200

innodb_log_file_size    = 512M

Reinicie o serviço e confira se os novos valores foram aplicados:

sudo systemctl restart mariadb

sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections, @@innodb_log_file_size;"

Antes de reiniciar em produção, confirme que o servidor tem memória livre suficiente para o novo valor. Um buffer pool maior do que a memória disponível faz o sistema usar swap, e aí o banco fica mais lento do que antes.

Uma segunda opinião: MySQLTuner

O MySQLTuner é um script que lê os contadores do servidor e sugere ajustes. Ele não altera nada, só mostra recomendações:

# Debian

sudo apt install mysqltuner

# Rocky Linux / Oracle Linux (pacote do repositório EPEL)

sudo dnf install epel-release

sudo dnf install mysqltuner

sudo mysqltuner

Rode depois de pelo menos um dia de uso normal; logo após um reinício, os contadores ainda não refletem a realidade. Trate as sugestões como pontos a investigar, e não como ordens: aplique uma por vez e meça o resultado.

Backups automáticos com o mariadb-backup

No primeiro post da série, fizemos backups com o mariadb-dump, que gera um arquivo .sql com os comandos para recriar os dados. É um ótimo formato para bancos pequenos e para levar dados de um servidor para outro. Mas, conforme o banco cresce, o dump fica lento para gerar e, principalmente, para restaurar: um restore de horas pode ser inaceitável em produção.

O mariadb-backup faz outro tipo de backup: copia os próprios arquivos de dados, com o banco funcionando. O restore é basicamente copiar os arquivos de volta, muito mais rápido.

• mariadb-dump: backup lógico. Portável entre versões e servidores, lento para bancos grandes.

• mariadb-backup: backup físico. Rápido para gerar e restaurar, mas restaurado na mesma versão do MariaDB.

Os dois se completam. Uma rotina comum é o mariadb-backup todos os dias e o mariadb-dump uma vez por semana.

Instalar

# Debian

sudo apt install mariadb-backup

# Rocky Linux / Oracle Linux

sudo dnf install mariadb-backup

Fazer e preparar um backup

O backup tem duas etapas. A primeira copia os arquivos; a segunda, o prepare, deixa a cópia consistente e pronta para uso:

sudo mkdir -p /var/backups/mariadb

sudo chmod 700 /var/backups/mariadb

sudo mariadb-backup --backup  --target-dir=/var/backups/mariadb/full-teste

sudo mariadb-backup --prepare --target-dir=/var/backups/mariadb/full-teste

Ao final de cada etapa, a última linha deve ser completed OK!.

Restaurar

O restore precisa do serviço parado e da pasta de dados vazia. Em vez de apagar a pasta atual, renomeie-a: se algo der errado, ela continua lá.

sudo systemctl stop mariadb

sudo mv /var/lib/mysql /var/lib/mysql.antigo

sudo mkdir /var/lib/mysql

sudo mariadb-backup --copy-back --target-dir=/var/backups/mariadb/full-teste

sudo chown -R mysql:mysql /var/lib/mysql

# Rocky Linux / Oracle Linux: restaurar o contexto do SELinux

sudo restorecon -Rv /var/lib/mysql

sudo systemctl start mariadb

Depois de conferir que tudo está certo, apague a pasta /var/lib/mysql.antigo.

Automatizar com retenção

O script abaixo faz o backup, prepara a cópia, apaga os backups com mais de 7 dias e registra o resultado no log do sistema. Crie-o em /usr/local/bin/mariadb-backup-diario.sh:

#!/bin/bash

# Backup diário do MariaDB com mariadb-backup e retenção de 7 dias

set -euo pipefail

DESTINO=/var/backups/mariadb

PASTA="$DESTINO/full-$(date +%F_%H%M)"

LOG="$DESTINO/backup.log"

trap 'logger -t mariadb-backup -p daemon.err "Backup FALHOU: $PASTA"' ERR

mariadb-backup --backup  --target-dir="$PASTA" >> "$LOG" 2>&1

mariadb-backup --prepare --target-dir="$PASTA" >> "$LOG" 2>&1

# Apaga backups com mais de 7 dias

find "$DESTINO" -maxdepth 1 -type d -name 'full-*' -mtime +7 -exec rm -rf {} +

logger -t mariadb-backup "Backup concluido: $PASTA"

Deixe o script executável só pelo root:

sudo chmod 700 /usr/local/bin/mariadb-backup-diario.sh

O serviço, em /etc/systemd/system/mariadb-backup-diario.service:

[Unit]

Description=Backup diario do MariaDB

[Service]

Type=oneshot

ExecStart=/usr/local/bin/mariadb-backup-diario.sh

E o timer, em /etc/systemd/system/mariadb-backup-diario.timer, para rodar todos os dias às 2h30:

[Unit]

Description=Backup diario do MariaDB as 2h30

[Timer]

OnCalendar=*-*-* 02:30:00

Persistent=true

[Install]

WantedBy=timers.target

O Persistent=true faz o backup rodar assim que o servidor ligar, caso ele estivesse desligado no horário programado. Ative e teste uma execução manual:

sudo systemctl daemon-reload

sudo systemctl enable --now mariadb-backup-diario.timer

# Rodar agora, para testar

sudo systemctl start mariadb-backup-diario.service

journalctl -t mariadb-backup --no-pager -n 5

Dois cuidados que fazem diferença

• Uma cópia fora do servidor. Se o disco do servidor falhar, os backups guardados nele vão junto. Copie a pasta para um NAS ou outro servidor, por exemplo com rsync, logo depois do backup.

• Teste o restore. Uma vez por mês, restaure o backup mais recente em uma VM de teste e confira se a aplicação abre com aqueles dados. Um backup que nunca foi restaurado é só uma suposição.

Atualização de versão

O MariaDB tem dois tipos de atualização, e eles pedem cuidados bem diferentes.

• Atualização menor, por exemplo de 10.11.8 para 10.11.11: traz correções de falhas e de segurança, sem mudar o comportamento do banco. Deve ser feita com frequência.

• Atualização principal, por exemplo de 10.11 para 11.8: traz recursos novos e pode mudar comportamentos e configurações. Precisa de planejamento e teste.

Atualização menor

Ela chega pelos pacotes normais da distribuição. Mesmo sendo simples, siga sempre a mesma ordem:

# 1) Backup antes de tudo (seção anterior)

sudo systemctl start mariadb-backup-diario.service

# 2) Atualizar os pacotes

# Debian

sudo apt update

sudo apt install --only-upgrade 'mariadb-*'

# Rocky Linux / Oracle Linux

sudo dnf upgrade 'mariadb*'

# 3) Conferir se o serviço voltou e a versão nova

sudo systemctl status mariadb --no-pager

mariadb --version

Por fim, rode o mariadb-upgrade, que ajusta as tabelas internas do MariaDB para a versão nova. Em algumas instalações o pacote já faz isso sozinho; nesse caso, o comando só avisa que não há nada a fazer:

sudo mariadb-upgrade

Confira o log de erros logo depois. Se a aplicação tiver uma tela de status ou um teste simples, use-o para confirmar que tudo voltou.

Atualização principal

As distribuições mantêm a mesma versão principal durante todo o ciclo de vida delas. Para subir de versão principal, há dois caminhos:

• Repositório oficial do MariaDB: troca os pacotes da distribuição pelos pacotes do próprio MariaDB, na versão escolhida. Atualiza o servidor existente.

• Servidor novo: instale a versão nova em outro servidor (ou em uma VM nova), leve os dados com o mariadb-dump do primeiro post e, depois de testar, aponte a aplicação para ele. É o caminho mais seguro, porque o servidor antigo continua intacto até o fim.

Em qualquer um dos caminhos:

• Leia as notas de versão da versão de destino, especialmente as mudanças de configuração e as opções removidas.

• Suba uma versão principal de cada vez, como a documentação do MariaDB recomenda, ou use o caminho do servidor novo com dump.

• Teste antes em uma cópia do ambiente: restaure o backup de produção em uma VM, atualize e rode a aplicação contra ela.

• Combine uma janela de manutenção com quem usa a aplicação.

Como voltar atrás

O MariaDB não permite voltar para uma versão anterior com os mesmos arquivos de dados. Depois que a versão nova abriu os arquivos, a volta é feita restaurando o backup feito antes da atualização, com os pacotes da versão antiga. Por isso, antes de uma atualização principal:

• Faça um backup com o mariadb-backup e um com o mariadb-dump, e confirme que os dois terminaram sem erro.

• Se o servidor for uma VM, tire também um snapshot. Voltar o snapshot é o caminho mais rápido se algo der errado, mas apague-o depois que a atualização estiver confirmada: snapshots antigos ocupam espaço e deixam a VM mais lenta.

• Anote a versão atual (mariadb --version) e os passos da volta no seu controle de mudanças, antes de começar.

Replicação

Na replicação, um segundo servidor, a réplica, recebe continuamente todas as alterações feitas no servidor principal, o primário. A réplica fica com uma cópia do banco atualizada, normalmente com atraso de poucos segundos.

Para que serve:

• Recuperação rápida: se o primário parar, a réplica já tem os dados e pode assumir em minutos.

• Relatórios sem pesar a produção: consultas pesadas rodam na réplica, longe da aplicação.

• Backups sem tocar no primário: o mariadb-backup pode rodar na réplica.

E o que ela não é: a réplica não substitui o backup. Um DROP TABLE feito por engano no primário é replicado em segundos, e a tabela some dos dois servidores. Só o backup permite voltar ao estado anterior.

Nos exemplos, os endereços são estes:

Primário:  192.168.10.10

Réplica:   192.168.10.11

1) Configurar o primário

O primário precisa de um identificador único e do log binário, onde ficam registradas as alterações que a réplica vai ler:

# Debian:                      /etc/mysql/mariadb.conf.d/50-server.cnf

# Rocky Linux / Oracle Linux:  /etc/my.cnf.d/mariadb-server.cnf

[mysqld]

server_id     = 1

log_bin       = mariadb-bin

binlog_format = ROW

O primário também precisa aceitar conexões da réplica pela rede. Se ele ainda escuta só em 127.0.0.1, ajuste o bind-address como mostrado no cenário 2 do post anterior. Reinicie o serviço:

sudo systemctl restart mariadb

Crie um usuário só para a replicação, aceito apenas a partir do IP da réplica:

CREATE USER 'replicacao'@'192.168.10.11' IDENTIFIED BY 'senha_gerada';

GRANT REPLICATION SLAVE ON *.* TO 'replicacao'@'192.168.10.11';

Libere o firewall do primário para o IP da réplica, com a mesma regra do cenário 2 do post anterior, trocando o IP por 192.168.10.11.

2) Configurar a réplica

Na réplica, o identificador precisa ser diferente, e o banco fica somente leitura para evitar que alguém grave nela por engano:

# Debian:                      /etc/mysql/mariadb.conf.d/50-server.cnf

# Rocky Linux / Oracle Linux:  /etc/my.cnf.d/mariadb-server.cnf

[mysqld]

server_id = 2

read_only = ON

3) Levar a cópia inicial dos dados

A réplica precisa começar com os mesmos dados do primário. O jeito mais rápido é o mariadb-backup. No primário:

sudo mariadb-backup --backup  --target-dir=/var/backups/mariadb/replica

sudo mariadb-backup --prepare --target-dir=/var/backups/mariadb/replica

# Copiar para a réplica

sudo rsync -a /var/backups/mariadb/replica/ usuario@192.168.10.11:/tmp/replica/

Na réplica, restaure a cópia como na seção de backups:

sudo systemctl stop mariadb

sudo mv /var/lib/mysql /var/lib/mysql.antigo

sudo mkdir /var/lib/mysql

sudo mariadb-backup --copy-back --target-dir=/tmp/replica

sudo chown -R mysql:mysql /var/lib/mysql

# Rocky Linux / Oracle Linux

sudo restorecon -Rv /var/lib/mysql

sudo systemctl start mariadb

4) Ligar a replicação

A cópia sabe exatamente em que ponto do log binário ela foi feita. Essa posição fica no arquivo xtrabackup_binlog_info (nas versões mais novas, mariadb_backup_binlog_info), dentro da pasta do backup:

cat /tmp/replica/xtrabackup_binlog_info

# Exemplo de saída: mariadb-bin.000003  1856  0-1-1234

O último valor (0-1-1234 no exemplo) é a posição GTID. No prompt do MariaDB da réplica, use esse valor para ligar a replicação:

SET GLOBAL gtid_slave_pos = '0-1-1234';

CHANGE MASTER TO

  MASTER_HOST     = '192.168.10.10',

  MASTER_USER     = 'replicacao',

  MASTER_PASSWORD = 'senha_gerada',

  MASTER_USE_GTID = slave_pos;

START REPLICA;

5) Conferir

Ainda na réplica:

SHOW REPLICA STATUS\G

Três linhas contam se está tudo certo:

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Seconds_Behind_Master: 0

Se alguma das duas primeiras estiver como No, as linhas Last_IO_Error e Last_SQL_Error mostram o motivo; quase sempre é firewall, senha ou a posição GTID. Para um teste final, crie algo no primário e veja aparecer na réplica:

-- No primário

CREATE DATABASE teste_replicacao;

-- Na réplica, alguns segundos depois

SHOW DATABASES LIKE 'teste_replicacao';

-- No primário, para limpar

DROP DATABASE teste_replicacao;

Depois que a replicação estiver funcionando, apague as cópias usadas para criá-la (/var/backups/mariadb/replica no primário e /tmp/replica na réplica): elas contêm todos os dados do banco.

Se o primário parar

Promover a réplica é uma decisão manual, e deve estar descrita no seu plano de contingência. O roteiro básico, na réplica:

STOP REPLICA;

SET GLOBAL read_only = OFF;

Depois, aponte a aplicação para o IP da réplica e remova o read_only = ON do arquivo de configuração dela, para que a mudança continue valendo após um reinício. Quando o servidor antigo voltar, ele não deve receber gravações: reconstrua-o como nova réplica, com o mesmo processo desta seção.

Inclua a replicação na verificação automática da seção de monitoramento: se Slave_IO_Running ou Slave_SQL_Running não estiverem como Yes, ou se o Seconds_Behind_Master passar de alguns minutos, a réplica deixou de ser uma cópia confiável.

Checklist de operação

Use esta lista para revisar a rotina do seu servidor. Cada item corresponde a uma seção deste post.

Monitoramento

• A verificação automática roda a cada 5 minutos, e os alertas chegam a alguém (log central, SIEM ou e-mail).

• O log de consultas lentas está ativo, e as consultas mais pesadas são revisadas com a equipe da aplicação.

• O pico de conexões (Max_used_connections) fica com folga em relação ao max_connections.

Desempenho

• O innodb_buffer_pool_size foi ajustado para a memória do servidor e para o tamanho dos bancos.

• Cada mudança de configuração foi feita uma de cada vez, com medição antes e depois, e registrada no controle de mudanças.

Backups

• O mariadb-backup roda todos os dias pelo timer, com retenção definida.

• O mariadb-dump semanal continua rodando, para ter também uma cópia portável.

• Existe uma cópia dos backups fora do servidor.

• O restore é testado todo mês em uma VM de teste.

Atualizações

• As atualizações menores são aplicadas com frequência, sempre depois de um backup.

• As atualizações principais são testadas antes em uma cópia do ambiente, com o plano de volta escrito.

Replicação

• A réplica mostra Slave_IO_Running e Slave_SQL_Running como Yes, com atraso baixo.

• A verificação automática também confere a réplica.

• O procedimento para promover a réplica está escrito no plano de contingência e já foi ensaiado no laboratório.

Para fechar

Com este post, a série cobre o ciclo completo do MariaDB: instalar e gerenciar no primeiro post, abrir o acesso com segurança no segundo e, agora, manter o banco saudável, rápido, com backups confiáveis e uma cópia pronta para assumir. Nenhuma dessas partes é complicada sozinha; o que faz diferença em produção é transformar cada uma em rotina.

Se você seguiu os três posts no seu laboratório, já tem um ambiente que se parece muito com o de uma empresa. Use-o para ensaiar o que dá medo de fazer pela primeira vez em produção: um restore completo, uma atualização principal e a promoção da réplica.

Para saber mais

• Gerenciamento básico do MariaDB (primeiro post desta série)

• Segurança e acesso ao MariaDB (segundo post desta série)

• Backup e restore com mariadb-backup (documentação do MariaDB)

• Configurar a replicação (documentação do MariaDB)

• Atualizar o MariaDB (documentação do MariaDB)

Trilha de MariaDB

Esta série tem três posts. Se você está começando, siga na ordem:

1. Gerenciamento básico do MariaDB

2. Segurança e acesso ao MariaDB

3. Operação e alta disponibilidade do MariaDB (você está aqui)