"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

dba.stackexchange https://dba.stackexchange.com/questions/103198

  •  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.

Était-ce utile?

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

  1. 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

  2. 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)

  3. sed avec

    sed -e '/nameofscriptiyourfileWhichIsintHefirstline.php/,+nd'

  4. 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).

    1. communiquer le problème au développeur et exécutez à nouveau votre slowlog modifié.

    2. 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

    3. 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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top