Analisar e interpretar corretamente o registo de erros do MariaDB

Função e limites do registo de erros

O Registo de erros do MariaDB É o registo de funcionamento do processo do servidor. Regista, nomeadamente, os processos de arranque e paragem, eventos críticos do servidor, bem como indicações que possam sugerir problemas com tabelas ou com o motor de armazenamento. O registo está sempre ativo, mas o seu canal de saída pode ser configurado de diferentes formas.

Nele aparecem, por exemplo, inicializações falhadas de plugins, ficheiros ilegíveis, recusas de acesso ou mensagens relacionadas com ligações. No entanto, uma linha com „Access denied“ prova, em primeiro lugar, apenas que um início de sessão com os dados transmitidos não foi aceite. Se a responsabilidade recai sobre a palavra-passe, a associação utilizador-host, o método de autenticação ou a aplicação que efetuou a chamada, só se pode determinar a partir do contexto.

Além disso, o registo de erros não é um arquivo completo de todos os erros SQL de uma aplicação. Para isso, existe o Plugin SQL_ERROR_LOG; pode registar os erros SQL que ocorram num ficheiro próprio, incluindo os erros que um Condition Handler processa antes de chegarem ao cliente. O plugin não vem instalado por predefinição. As suas entradas podem conter informações sobre utilizadores, anfitriões, bases de dados e SQL, pelo que a proteção de acesso e a minimização de dados devem ser definidas antes da sua utilização.

Para Resolução de problemas do MySQL Por isso, a sequência temporal é mais importante do que uma linha final isolada. Comece por identificar um trecho contínuo antes e depois do evento. Se uma mensagem de erro concreta for seguida por várias entradas subsequentes e, por fim, por uma interrupção, o primeiro desvio relevante está frequentemente mais próximo da causa do que o último erro visível. A hora, o sintoma observado e as alterações simultâneas na aplicação ou no sistema também devem ser tidos em conta na avaliação.

Identificar com segurança os locais de armazenamento

Um ficheiro em falta com a extensão .err isso não significa que o MariaDB não tenha registado nada. O registo de erros pode ser gravado num ficheiro, na saída de erros padrão ou, através do Syslog, no journal do systemd; no Windows, acrescenta-se ainda o Visualizador de Eventos. A variante ativa depende das opções do servidor, da configuração do pacote e do mecanismo de arranque da instalação específica.

A opção log_error define o destino na saída baseada em ficheiros. Um nome de ficheiro relativo é interpretado em relação ao diretório de dados, enquanto um caminho absoluto permanece independente desse diretório. Se não for explicitamente definido um nome, a documentação descreve um ficheiro seguindo o padrão «nome do anfitrião mais» .err no diretório de dados. No entanto, não se deve deduzir daí um caminho fixo: verifica sempre a configuração efetivamente em vigor.

Os comandos seguintes apenas leem as opções a partir de ficheiros de opções. Por isso, constituem um bom ponto de partida para log_error, mas não refletem necessariamente a configuração completa do processo em execução. Parâmetros de arranque adicionais, bem como substituições de unidades do systemd ou substituições «drop-in», podem complementar ou alterar valores e devem ser verificados separadamente.

Na documentação atual do MariaDB, o processo do servidor denomina-se mariadbd; mysqld pode continuar a aparecer como nome de compatibilidade, dependendo da instalação. Por isso, não se deve equiparar ambas as designações sem ter em conta o contexto da versão e da instalação. Os comandos não alteram nem o serviço nem os dados.

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

De acordo com a documentação, o segundo comando está previsto a partir do MariaDB 10.11; o terceiro é relevante para instalações com a designação anterior do programa. Se não encontrares nenhuma indicação clara nos ficheiros de opções, verifica o Journal ou o Syslog, bem como os parâmetros do serviço efetivamente iniciado, em vez de criares um caminho de registo hipotético. Isto evita que o diagnóstico e a configuração em tempo de execução fiquem desfasados.

Interpretar corretamente o formato da linha e o contexto

Nos registos de erros baseados em ficheiros das versões mais recentes do MariaDB, a partir da 10.1.5, cada linha segue, em princípio, o padrão: carimbo de data/hora, ID do thread, nível e mensagem. O Carimbo de data/hora classifica o evento, o ID do thread permite associá-lo a outras entradas da mesma ligação ao servidor e o nível descreve o tipo de mensagem. Só em conjunto com estes campos é que a mensagem fornece uma base fiável para o diagnóstico.

No MariaDB até à versão 10.1.4, inclusive, o formato de data e hora é mais curto e a apresentação difere do esquema mais recente. Por isso, um analisador ou uma pesquisa que espere posições fixas de campos no formato atual pode analisar incorretamente os registos mais antigos. Além disso, os scripts SST externos em ambientes Galera podem escrever linhas nas quais faltam o ID do thread e o nível. Essas linhas especiais não são, automaticamente, dados de registo danificados.

O excerto seguinte é apenas um exemplo esquemático do percurso de leitura de uma sequência de arranque mal sucedida. Não utiliza nenhuma instância real e não substitui nem a saída completa do arranque nem a verificação das opções ativas. O que é decisivo é que o desvio na configuração se situa antes da mensagem final de interrupção.

2026-09-23 08:14:02 0 [Note] Starting MariaDB
2026-09-23 08:14:02 0 [ERROR] unknown variable 'example_option=1'
2026-09-23 08:14:02 0 [ERROR] Aborting

Aqui está unknown variable O primeiro aspeto a analisar: a opção pode estar mal escrita, não estar disponível nesta versão ou estar colocada no ficheiro de configuração errado. Aborting descreve, por outro lado, o ponto final da sequência inicial. Por isso, procura retroativamente até à primeira mensagem relevante e, em seguida, regista as linhas seguintes. Desta forma, separas a causa provável, a reação do servidor e os efeitos visíveis da erros na base de dados bem separados uns dos outros.

Primeira receção sem alterações arriscadas

Antes de interpretar uma mensagem ou alterar as definições, faça uma cópia de segurança do Contexto operacional: a versão completa do MariaDB, incluindo qualquer complemento de pacote ou distribuição, sistema operativo, mecanismo de arranque, hora e sintoma visível. Um reinício, uma falha no início de sessão ou uma interrupção da replicação são eventos distintos. Sem estas informações, não é possível avaliar de forma fiável a mesma linha de registo.

Além disso, não copie apenas um único resultado, mas sim um trecho contínuo antes e depois do primeiro evento que chame a atenção. Anote quando o problema começou para os utilizadores ou aplicações e se ocorreram, em paralelo, alterações na configuração, na implementação ou na rede. Desta forma, é possível distinguir temporalmente os fatores desencadeantes, os erros subsequentes e a sequência normal de arranque ou paragem.

Os comandos seguintes limitam-se a ler informações de ficheiros de opções e não alteram nem o serviço nem os dados. São particularmente úteis para verificar uma opção definida nesses ficheiros log_error . No entanto, estes não mostram automaticamente todos os valores com os quais o serviço foi efetivamente iniciado: os parâmetros de arranque adicionais, os ficheiros de unidade do systemd e os drop-ins devem ser verificados separadamente.

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

A partir da versão 10.11 do MariaDB, o MariaDB documenta my_print_defaults --mariadbd para esta consulta. O nome mariadbd refere-se ao processo do servidor atual; mysqld em muitas instalações, mantém-se como designação antiga ou como referência de compatibilidade. Por isso, não considere ambos os nomes como indício da mesma versão concreta do servidor ou do mesmo nome de serviço.

Se o registo se encontrar no journal do systemd, delimita o intervalo de tempo com o nome da unidade verificado no sistema. Se necessário, verifique também o ficheiro da unidade e os drop-ins existentes, para garantir que não sejam ignorados parâmetros de arranque adicionais. Em seguida, complemente o excerto com o registo da aplicação referente ao mesmo período, caso o sintoma se manifeste numa aplicação.

journalctl -u <geprüfte-mariadb-unit> --since "2026-09-23 08:00" --until "2026-09-23 09:00"

Classificar os erros de nível e de arranque

As etiquetas organizam o registo de erros do MariaDB, mas não substituem a análise das causas. Uma Gravidade descreve a classificação de uma linha, não indica automaticamente a gravidade ou a urgência. Especialmente no caso de um problema de arranque, a ordem é determinante: uma mensagem de erro concreta que apareça mais cedo explica frequentemente uma mensagem posterior Aborting, enquanto as notas que precedem podem também referir-se à inicialização normal.

Se o MariaDB não arrancar, identifica primeiro a última sequência de arranque no registo e, em seguida, lê-o de trás para a frente. Procura, em particular, por unknown variable, ficheiros em falta ou ilegíveis, problemas de autorizações e erros na inicialização dos plugins. O MariaDB indica o registo de erros como fonte principal para as falhas na inicialização; no caso de uma inicialização manual, a causa pode também ser apresentada na consola.

A Erro de configuração Na maioria das vezes, trata-se de uma opção desconhecida, de uma grafia incorreta ou de um valor inadequado num ficheiro importado. Verifica, então, primeiro as opções ativas e a correspondência de versões, em vez de alterar os conjuntos de dados. Por outro lado, um erro ao abrir um ficheiro de dados ou uma mensagem do InnoDB pode estar relacionado com permissões, caminhos, memória ou o estado dos dados e exige uma análise muito mais cuidadosa.

Não altere vários parâmetros ao mesmo tempo para forçar o arranque. Guarde o excerto do registo e anote qual foi a alteração que antecedeu o erro. Só quando a primeira mensagem relevante for associada a uma configuração ou recurso verificado é que se poderá planear uma correção específica e rastreável.

Avaliar do ponto de vista diagnóstico as queixas frequentes

As formulações recorrentes facilitam a pesquisa, mas raramente, por si só, permitem estabelecer um diagnóstico. Atribua cada mensagem a um intervalo de tempo, ao host ou thread afetado e ao sintoma observado. A tabela indica deliberadamente apenas os próximos passos de diagnóstico: evita que, a partir de uma referência a ligações, ficheiros ou replicação, se deduza precipitadamente que a causa se encontra no servidor da base de dados.

Em Acesso negado Em primeiro lugar, é fundamental saber para que utilizador e host do cliente o acesso foi recusado. Verifica a configuração da aplicação utilizada e o momento em que ocorreu o erro, e não apenas a palavra-passe isoladamente. A mensagem pode ser causada por dados de acesso incorretos, uma referência de host incorreta ou uma autenticação inadequada; não indica que a base de dados esteja danificada.

A Ligação interrompida pode estar relacionado com um tempo limite da aplicação, uma ligação de rede interrompida, um proxy ou uma comunicação de pacotes com erros. Compare o host do cliente e o ID do thread com o registo da aplicação. Para os contadores, utilize valores globais em vez de valores relativos à sessão; caso contrário, uma sessão recém-iniciada pode apresentar valores baixos que induzem em erro.

SHOW GLOBAL STATUS LIKE 'Aborted%';

A consulta apresenta contadores, mas não indica a causa completa nem a atribuição a um cliente específico. Por isso, avalie as alterações ao longo de um período de tempo adequado, em conjunto com excertos do registo de erros. No caso de avisos relacionados com a replicação ou com o GTID, documente também as linhas seguintes e verifique o estado da replicação através das informações de estado previstas para o efeito; a linha do registo de erros, por si só, não é suficiente para um diagnóstico completo da replicação.

Avaliar a recuperação do InnoDB sem risco para os dados

Após uma paragem não planeada, podem aparecer mensagens como „Recovering after a crash“, „Starting crash recovery“ e uma mensagem a indicar que o processo foi concluído com sucesso. Estas mensagens referem-se, inicialmente, a uma recuperação automática após uma falha durante o arranque do servidor. No contexto do registo binário ou tc.log podem ainda conter informações relativas à coordenação das transações. Por si só, estas linhas não constituem prova de tabelas danificadas ou de perda de dados.

A avaliação altera-se quando, após a recuperação, ocorre um [ERRO] se a inicialização for interrompida ou se as mensagens indicarem ficheiros ilegíveis ou danificados. Nesse caso, leia toda a sequência de inicialização por ordem cronológica e registe a versão, a hora da falha e o excerto completo. Uma referência ao «Binary Log» ou ao «tc.log», sem erros subsequentes, não constitui, por si só, um pedido de reparação.

Em caso de suspeita de um problema com os dados, não se devem efetuar eliminações de ficheiros nem outras intervenções que tenham como único objetivo forçar o arranque. Esclareça primeiro o objetivo da medida: delimitar a falha, ler de forma controlada os dados acessíveis ou restaurar uma instância produtiva. Para tal, registe separadamente o excerto do registo, as cópias de segurança existentes e o estado da instância afetada.

Se for possível uma leitura controlada, a transferência para uma instância de destino limpa deve fazer parte do planeamento, em vez de se considerar que o ambiente afetado está resolvido. Para compreender os mecanismos transacionais envolvidos, é útil consultar o artigo sobre Registos de reversão do MariaDB para administradores. Em caso de falhas repetidas ou erros de ficheiros pouco claros, é mais aconselhável recorrer a um serviço especializado de recuperação do que continuar a tentar iniciar o sistema.

Separar a replicação dos erros SQL

No registo de erros, podem aparecer threads, posições, GTIDs ou registos de retransmissão durante os processos de replicação. Essas informações fornecem, em primeiro lugar, contexto para o período em questão, mas ainda não constituem um diagnóstico completo do erro. Guarde as linhas anteriores e posteriores à entrada e verifique separadamente o estado da replicação. Não é possível determinar de forma fiável, a partir de uma linha isolada do registo, se um thread terminou normalmente ou se ocorreu uma interrupção.

Notícias sobre transações preparadas Por outro lado, após uma falha, é necessário ter um cuidado especial. Uma recuperação heurística toma uma decisão de commit ou rollback, dependendo da opção escolhida, ignorando, ao fazê-lo, as informações da coordenação da transação. Este não é um passo para a resolução geral de problemas do MySQL, mas sim um caso especial cujas consequências para as réplicas e os dados empresariais devem ser avaliadas antecipadamente.

O registo de erros regista os eventos do servidor, mas não é um registo completo de todas as instruções SQL com erros. Os registos binários servem principalmente para registar alterações e para a replicação; o seu papel é explicado no artigo sobre Os registos binários do MariaDB e a sua lógica de desempenho. O Slow Query Log ajuda no caso de consultas lentas, o General Query Log serve para uma monitorização abrangente das ligações e das consultas, e um Audit Log tem um objetivo de auditoria diferente.

Para os erros SQL que possam ocorrer, existe o ficheiro separado Plugin SQL_ERROR_LOG. Também pode registar erros que são processados por um Condition Handler e que, por isso, tecnicamente não são transmitidos ao cliente. O plugin não é instalado automaticamente; a partir do MariaDB 10.11.5, também é possível registar avisos, desde que a configuração seja adequada. As suas entradas podem conter dados de utilizador e de anfitrião, nomes de bases de dados, bem como texto SQL. Por isso, planeie direitos de acesso restritivos, a conservação e a rotação dos registos antes de ativar o registo adicional num ambiente de produção.

Operações, escalamento e próximos passos

Parar em caso de comportamentos suspeitos erros na base de dados Primeiro, um excerto contínuo do registo com carimbos de data/hora, e não apenas a última linha. Anote a versão do MariaDB, incluindo o identificador do pacote, o mecanismo de arranque, o sintoma observado e a correlação temporal com implementações, reinícios ou eventos de infraestrutura. Estes dados distinguem uma possível causa das suas consequências e permitem comparar em conjunto as indicações provenientes da aplicação, do sistema operativo e da base de dados.

Em seguida, compare as opções efetivamente carregadas com a configuração pretendida, em vez de alterar os valores predefinidos presumidos. Isto é particularmente importante, uma vez que o empacotamento, a versão do MariaDB e os nomes de compatibilidade podem afetar as opções de forma diferente. Se houver um erro de configuração, este pode ser resolvido de forma diferente de um eventual dano na memória ou no InnoDB.

Antes de reinicializações, tentativas de recuperação ou alterações de configuração, é uma medida de segurança aconselhável verificar os cópias de segurança disponíveis e a sua viabilidade. Além disso, documente a alteração planeada e um plano de contingência. Isto não substitui uma análise das causas, mas reduz o risco de que uma medida de diagnóstico oculte o estado inicial ou dificulte a recuperação.

Uma única recusa de acesso ou uma ligação interrompida pode, numa primeira fase, ser apenas observada, desde que não se repita e que a aplicação e o serviço se mantenham estáveis. Se tais eventos se tornarem frequentes, deve considerar-se o host do cliente, a aplicação, o proxy e a rede. Por outro lado, interrupções repetidas no arranque, ficheiros de dados ilegíveis, falhas na recuperação após falhas do sistema ou indícios de transações em espera constituem casos que exigem uma escalada imediata, com os dados originais guardados.

Mesmo um registo que funcione bem precisa de regras de funcionamento. Monitorize Rotação de registos e consumo de memória, uma vez que uma maior verbosidade ou registos de erros SQL adicionais podem aumentar rapidamente o tamanho dos ficheiros. Limite o acesso aos registos, pois estes contêm detalhes técnicos e, eventualmente, conteúdos confidenciais das consultas. As alterações permanentes só se justificam após a identificação de uma causa documentada, a definição de um plano de contingência e uma avaliação do impacto na proteção de dados e na capacidade.