"Aucune base de données sélectionnée" ou "table 'db.table" n'existe pas "échecs dans PT-Upgrade exécuté où les requêtes de plusieurs DB ont été collectées avec TCPDump
-
26-09-2020 - |
Question
J'ai collecté des requêtes sur notre maître en utilisant la commande TCPDummp suivante:
tcpdump -i any -s 65535 -x -n -nn -q -tttt 'port 3306' > tcpdump.tcp
Les requêtes sont exécutées parmi plusieurs bases de données.
J'ai ensuite dirigé ce fichier via PT-Query-Digest à l'aide de la commande suivante:
pt-query-digest --output=slowlog --no-report --sample 100 --type tcpdump tcpdump.tcp > slow.log
Puis j'ai couru pt-mise à niveau contre deux esclaves comme celui-ci:
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
Mais j'ai eu un tas d'échecs puisqu'il ne semble pas spécifier quelle base de données la requête doit être exécutée contre.
Comment est-il censé utiliser PT-Mettre à niveau lorsque les requêtes sont collectées parmi plusieurs DBS? AFAICT Ceci n'est pas spécifié dans la documentation nulle part.
Êtes-vous censé utiliser --Filter avec PT-Query-Digest pour simplement produire des requêtes pour une base de données particulière, puis spécifier --Database avec PT-Upgrade? Rincer et répéter par base de données.
Il faut plusieurs heures pour analyser ma capture gigantesque tcpdump afin que toute directive soit appréciée ici.
merci!
P.s.
J'ai utilisé cette Article comme point de départ, mais il est obsolète. par exemple. PT-Query-Digest n'a plus d'option --Print.
La solution
-
ne manque-t-il toujours pas de fonctionner si vous omettez - échantillon?
-
(du manuel)
Notez également que PT-Query-Digest peut ne pas indiquer la base de données pour requêtes lors de l'analyse de la sortie TCPDump.La base de données est découverte seulement dans les événements de connexion initiaux pour un nouveau client ou quand est réalisé.Si la sortie TCPDummp ne contient aucun de ces aucun de ces éléments, alors PT-Query-Digest ne peut pas découvrir la base de données.
- envisagez d'utiliser le journal général au lieu de TCPDump?
Autres conseils
J'ai un problème similaire. J'ai des tables manquantes et des stations d'utilisation manquantes aussi. Parfois, la déclaration d'utilisation est présente mais avec la mauvaise base de données. J'utilise une solution de contournement assez simple.
(prélude) Mon premier numéro: mon loged.log est 60Go long donc
-
Je le divisions avec une option avec option -L défini sur 20 millions (qui me donne environ 1Go par fichier) Assurez-vous de ne pas avoir de déclarations entre fichiers les éditer avec
tête -Numberoflines AB >> AA Par exemple
-
Recherchez la déclaration qui est la racine de votre problème (ouvert avec moins que vous ne souhaitez pas avoir 1Go en RAM avec VI)
-
sed avec
sed -e '/nameofscriptiyourfileWhichIsintHefirstline.php/,+nd'
-
communiquer le problème au développeur et exécutez à nouveau votre slowlog modifié.
-
Répétez les étapes 2 à 4 jusqu'à ce que vous ne trouviez plus aucune erreur. Vous pouvez vous exécuter la liste de SED à travers ce type de commande
sed -e '...' | Sed -e '...' | Sed - '...'> Corrective_aa
avec n le nombre de lignes dont vous avez besoin pour modifier. (De mon point de vue, le développeur doit mettre ces informations à des fins de débogage et elle fait partie de notre cadre historique de toute façon).
problème de fianl: j'ai constaté que les requêtes avec comme et "%" sont une douleur aussi bien parce que l'analyseur ne peut pas les comprendre. (Toujours à la recherche d'une solution).
Si cela peut aider, je suis content. Ce n'est pas propre, c'est long, mais cela me permet de trouver toutes les questions qui ne correspondent pas à notre framework bien qu'elles le rendaient à la prod d'une manière ou d'une autre. Et puisque nous sommes très tard dans nos versions MySQL, il me fait plaisir de les amener à travailler pour moi éventuellement. ;)
P.s. : Ceci est mon premier message posté.
Qu'est-ce que nous avons fini par faire est de grepter des requêtes de la Slow.Log basée sur le nom de la table dans des fichiers journaux spécifiques à la base de données (RAW).Ensuite, nous avons spécifié --Type Rawlog et --Database avec PT-Upgrade.