"Nessuna database selezionato" o "Tabella" db.table "non esiste" "guasti" in Pt-upgrade Esegui dove sono state raccolte query da più DBS con TCPDump

Question

Ho raccolto query sul nostro master utilizzando il seguente comando TCPDump:

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

.

Le query vengono eseguite tra più database.

Ho quindi eseguito questo file tramite PT-Query-Digest utilizzando il seguente comando:

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

.

Poi ho eseguito PT-upgrade contro due schiavi come questo:

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

.

Ma ho ottenuto un sacco di guasti poiché non sembra specificare quale database la query deve essere eseguita contro.

Come si suppone usare l'aggiornamento PT quando le query vengono raccolte tra DB multipli? Afatic questo non è specificato nella documentazione ovunque.

Dovresti usare --Filter con PT-Query-Digest per inserire le query per un particolare database e quindi specificare --dabase con Pt-upgrade? Risciacquare e ripetere per database.

Ci vogliono diverse ore per analizzare la mia gigantesca cattura TCPDump in modo che qualsiasi orientamento qui sia apprezzato.

Grazie!

P.S.

Ho usato questo Articolo come punto di partenza ma è obsoleto. per esempio. PT-Query-Digest non ha più opzione APRINT.

Answer 1

.

• Non riesce ancora a funzionare se ometti - campionare?

• (dal manuale)

.

Si noti inoltre che PT-Query-Digest potrebbe non riuscire a segnalare il database per Query quando si analizza l'uscita TCPDump.Il database è scoperto solo Negli eventi iniziali di connessione per un nuovo client o quando è eseguito.Se l'output TCPDump non contiene nessuno dei due, allora PT-Query-Digest non può scoprire il database.

.
• Considera l'utilizzo del registro generale invece di TCPDump?

Answer 2

Ho un problema simile. Ho anche tavoli mancanti e anche gli statment dell'uso mancanti. A volte la dichiarazione di uso è presente ma con il database sbagliato. Io uso un workaround abbastanza semplice.

(preludio) Il mio primo problema: il mio slow.log è 60Go lungo così

.

1. lo dividi con diviso con opzione -l impostato su 20 milioni (che mi dà circa 1 vantaggio per file) Assicurati di non avere dichiarazioni che si trovano tra i file e modificarli con

   Head -numberOflines AB >> AA ad esempio

2. Trova la dichiarazione che è la radice del tuo problema (Apri con meno Non vuoi avere 1O in RAM con VI)

3. SED con

   sed -e '/namefscriptinyourfilewhichisinthefirstline.php/ -+nd'

con n il numero di linee che devi modificare. (Dal mio punto di vista Lo sviluppatore ha bisogno di mettere le informazioni sulle informazioni per scopi di debug e fa parte del nostro quadro storico).

4. Comunica il problema allo sviluppatore ed esegui di nuovo il tuo rallentatore modificato.

5. Ripeti i passaggi da 2 a 4 fino a non trovare più errori di thesi. Puoi eseguire l'elenco di SED attraverso questo tipo di comando

   SED -E '...' | sed -e '...' | SED - '...'> CORRET_AA

Problema del fianl: ho trovato che le domande con simili e "%" sono anche un dolore perché il parser non può capirli. (Ancora alla ricerca di una soluzione).

Se questo può aiutare sono contento. Non è pulito, è lungo, ma mi permette di trovare tutte le domande che non si adattano al nostro quadro, anche se lo hanno fatto al prodotto in qualche modo. E dal momento che siamo molto tardi nelle nostre versioni Mysql, è mio piacere farli lavorare per me alla fine. ;)

P.S. : Questo è il mio primo post.

Answer 3

Cosa abbiamo finito per fare è grillare le query da query Slow.log in base al nome della tabella nei file di registro (RAW) del database.Quindi abbiamo specificato - Type Rawlog e --dabase con PT-Upgrade.