"Database connection failed" no Moodle: quem cuida do seu conhece a diferença?

Caso real de produção, contado sem identificar o cliente. Um Moodle num alojamento compartilhado (LiteSpeed + MariaDB) exibia "Error: Database connection failed" de forma intermitente, com poucos usuários, e às vezes até para a conta de admin. O detalhe que enlouquece: o erro nunca ficava registrado em log nenhum. Aparecia, sumia, voltava. Nada para segurar.

Esse caso vale menos pela falha em si e mais pela pergunta que ele deixa: quem cuida do seu Moodle sabe distinguir essas coisas? Porque a primeira resposta que o cliente recebeu foi a errada.

A resposta de template (e por que é um sinal de alerta)

O suporte do host olhou o sintoma, disse que o "limite de conexões estava sendo atingido" e culpou o código, "conexões que não fecham". Até aí, poderia ser. O problema foi o conselho: recomendaram usar mysql_close(), uma função removida do PHP desde a versão 7, e mandaram um guia de "WordPress Database Optimization" para um site que é Moodle, rodando em PHP 8.3. Ou seja: resposta de template, colada sem olhar o caso. Quando o diagnóstico não bate nem com a linguagem nem com o sistema que você usa, ele não é um diagnóstico. É um copo de água morna.

O diagnóstico de verdade: descartar com prova, não com achismo

O caminho certo foi eliminar suspeitos com evidência, um a um: o charset estava correto (o banco em utf8mb4 gravou e leu "çãõ" idêntico), não havia estouro de memória, as conexões persistentes estavam desligadas, o tamanho do banco não era o problema, e não era "culpa do usuário". Todos descartados por teste, não por opinião.

A virada veio de uma sonda simples e decisiva: abrimos a conexão ao banco por linha de comando, 30 vezes em 90 segundos, e obtivemos 30 sucessos, no exato momento em que a web falhava. Conclusão inescapável: o MariaDB não estava caído. O banco estava vivo e respondendo. A falha estava só na rota web, e só sob concorrência. Isso muda tudo, porque aponta para onde ninguém tinha olhado.

A causa raiz: uma única página derrubava o Moodle sozinha

O culpado era uma página pública de catálogo. Ela pintava a imagem de cada curso como fundo de carga imediata. Uma única visita a essa página disparava cerca de 78 pedidos de pluginfile.php em paralelo. E aqui está a peça que só quem conhece o Moodle enxerga: cada pedido de pluginfile.php abre uma conexão ao banco (para verificar permissões do arquivo). Resultado: 78 conexões simultâneas contra um limite de 75 (max_user_connections).

Traduzindo: um único visitante, ou um bot, ou o Google passando, estourava o limite de conexões sozinho. Isso explicava cada detalhe que parecia contraditório: falhar com poucos usuários, falhar até para o admin, ser intermitente e nunca aparecer nos logs. Não era uso excessivo. Não era banco corrompido. Era uma página mal desenhada contra um teto de conexões, num nó compartilhado já apertado (64 cores com carga de 45 a 55 e cerca de 8000 processos).

A correção: o que estava no nosso controle

Não dava para esperar o host subir o limite. A solução saiu do nosso lado:

• Lazy-load das imagens (carregar só as visíveis, o resto conforme a rolagem): o pico de 78 pedidos simultâneos caiu para cerca de 8.
• Cache da página pesada, para não recalcular tudo a cada acesso.
• Bloqueio de bots agressivos que varriam a página inteira de uma vez.
• Debug de performance desligado depois do diagnóstico.

As conexões voltaram a caber com folga enorme, e o "Database connection failed" desapareceu, sem depender do host e sem trocar de plataforma.

A diferença que decide quem você contrata

Esse é o ponto do caso, e a pergunta que todo gestor deveria fazer: quem cuida do seu Moodle sabe que pluginfile.php abre uma conexão por arquivo? Sabe distinguir uma falha de conexão de um erro de dados? Sabe provar que o banco está vivo enquanto a web cai? O suporte genérico respondeu com uma função morta e um guia de outro sistema. Quem conhece Moodle de verdade lê o mesmo sintoma e enxerga a causa. A diferença entre um e outro é a diferença entre semanas de erro intermitente e uma tarde de trabalho.

Ter alguém com experiência comprovada cuidando da sua plataforma não é luxo, é o que separa o "achamos que é o código" do conserto. Sobre o custo de um fornecedor que não domina o assunto, veja o custo do suporte que some; e sobre lentidão em geral, por que o Moodle fica lento.