oh. I’ve removed tcpdump already as it occupied too much space(
But I’ve check diff of code briefly and seems there were no changes for these section (mentioned errors detection ones).
And also - these are not errors in code but detected errors during queries processing (as far as I understand)
So just trying to find explanation of what was detected in my case
I’ve updated toolkit to percona-toolkit-3.0.2-1.el7.x86_64.rpm
Here is fresh grep about reasons from error report and tcpdump screenshot - [URL]http://joxi.ru/Dr8y9ERc4Y8qxm[/URL]
(can’t provide you with raw dump as it could contain customer’s private data).
Still top reasons are
reason_for_failure => ‘no server OK to previous command’,
state => ‘awaiting_reply’,
and
reason_for_failure => ‘got server response before full buffer’,
and some other
So once again my questions:
what could be a reason for
reason_for_failure => ‘no server OK to previous command’,
state => ‘awaiting_reply’,
2.what could be a reason for
reason_for_failure => ‘got server response before full buffer’,
3.what could be a reason for
reason_for_failure => ‘client cmd not packet 0’,
4.what could be a reason for non-empty
server_retransmissions => [
1999078553,
1999078553
],
I suppose if such a common errors can be described somewhere in guides, this will be very useful.
Finally, can these issues be connected to network issues and how can I investigate/fix ?
Those messages come from MySQLProtocolParser.
I see errors in the screenshot: some packets were lost (Previous segment not captured) and that could be the source of the problem.
If there are missing packets, ProtocolParser cannot do a correct analysis.