Falhas “Nenhum banco de dados selecionado” ou “Tabela 'DB.table' não existe” na execução do pt-upgrade onde consultas de vários bancos de dados foram coletadas com tcpdump

Question

Coletei consultas em nosso Master usando o seguinte comando tcpdump:

tcpdump -i any -s 65535 -x -n -nn -q -tttt 'port 3306' > tcpdump.tcp

As consultas são executadas entre vários bancos de dados.

Em seguida, executei esse arquivo por meio de pt-query-digest usando o seguinte comando:

pt-query-digest --output=slowlog --no-report --sample 100 --type tcpdump tcpdump.tcp > slow.log

Então executei o pt-upgrade contra dois Slaves assim:

pt-upgrade --user user --ask-pass --run-time=1h --upgrade-table percona.pt_upgrade h=10.1.1.1 h=10.1.1.2 slow.log

Mas tive várias falhas, pois não parece especificar em qual banco de dados a consulta deve ser executada.

Como usar o pt-upgrade quando as consultas são coletadas entre vários bancos de dados?AFAICT isso não está especificado na documentação em nenhum lugar.

Você deveria usar --filter com pt-query-digest apenas para gerar consultas para um banco de dados específico e depois especificar --database com pt-upgrade?Enxágue e repita por banco de dados.

Demora várias horas para analisar minha gigantesca captura tcpdump, então qualquer orientação aqui será apreciada.

Obrigado!

P.S.

Eu usei isso artigo como ponto de partida, mas está desatualizado.por exemplo.pt-query-digest não tem mais a opção --print.

Answer 1

• Ainda não funciona se você omitir --sample?

• (do manual)

Observe também que pt-query-digest pode falhar ao relatar o banco de dados para Consultas ao analisar a saída tcpdump.O banco de dados é descoberto somente nos eventos de conexão iniciais para um novo cliente ou quando é Executado.Se a saída tcpdump não contiver nenhum desses, então pt-query-digest não pode descobrir o banco de dados.

• Considere usar o log geral em vez do tcpdump?

Answer 2

Eu tenho um problema similar.Também estou faltando tabelas e declarações USE.Às vezes, a instrução USE está presente, mas com o banco de dados errado.Eu uso uma solução bastante simples.

(Prelúdio) Minha primeira edição:meu slow.log tem 60 Go de comprimento, então

1. Eu divido com split com a opção -l definida como 20 milhões (o que me dá aproximadamente 1Go por arquivo), certifique-se de não ter instruções entre os arquivos, edite-as com

   head -numberoflines ab >>aa por exemplo

2. Encontre a afirmação que é a raiz do seu problema (abra com menos você não quer ter 1Go em RAM com VI)

3. sede-o com

   sed -e '/nomedoscriptnoseuarquivoqueestánaprimeiralinha.php/,+nd'

com n o número de linhas que você precisa editar.(Do meu ponto de vista o desenvolvedor precisa colocar essas informações para fins de depuração e de qualquer maneira isso faz parte do nosso framework histórico).

4. Comunique o problema ao desenvolvedor e execute novamente o slowlog editado.

5. Repita as etapas 2 a 4 até não encontrar mais nenhum desses erros.Você pode executar sua lista de sed através deste tipo de comando

   sed -e '...' | sed -e '...' | sed - '...' > correct_aa

Questão final:descobri que as consultas com like e "%" também são um problema porque o analisador não consegue entendê-las.(Ainda procurando por uma solução).

Se isso puder ajudar, fico feliz.Não é limpo, é longo, mas me permite encontrar todas as consultas que não se enquadram em nossa estrutura, embora de alguma forma tenham chegado ao produto.E como estamos muito atrasados ​​em nossas versões do mysql, é um prazer fazê-las funcionar para mim eventualmente.;)

P.S.:Este é o meu primeiro post.

Answer 3

O que acabamos fazendo foi transferir consultas do slow.log com base no nome da tabela para arquivos de log (brutos) específicos do banco de dados.Em seguida, especificamos --type rawlog e --database com pt-upgrade.