I'm wondering if anyone knows of a good way to track down queries causing max_allowed_packet errors.
Even if you turn on general query logging the query isn't logged as the connections aborted before it gets that far.
I'm trying to give something to the development team to help track this down. All I know is a general application account that causes it periodically. It's not like clockwork so it seems to be because of some kind of user generated interaction (versus a cronjob for example).
I had thought about bumping the limit on the master with out adjusting the value on the slave to let replication break but this is coming from a read only account, meaning it has to be a select of some kind.
The current value is set to 8M and there's not an expected use case dev would expect to generate much so just upping the limit to sweep it under the rug isn't really addressing the problem. I'd like involved parties to know what exactly is causing it so an informed decision can be made on whether bumping the limit is the right course of action (versus fixing some bug that shouldn't be generating queries that large).
I'm trying to get buy in to get app changes to either inspect query size before lobbing it over the fence, or at least catch those specific exceptions in a manner that provides sufficient information to find out what's generating it. They have other priorities so it would be nice if I could just say "this is exactly it"
Edit: Turning on general query logging with an upped max allowed size to let the selects goes through is prohibitive since the pattern is not predictable and just 'letting it run for a couple days' isn't possible with the space available.