mysql
mysql copied to clipboard
Distinguish net read timeout from other errors
Description
In a production environment, it is sometimes necessary to distinguish between network timeouts and other network errors, and handle timeouts, such as reconnection at the business level.
I've added the ErrNetReadTimeout variable. Now it returns ErrNetReadTimeout instead of ErrInvalidConn if mc.buf.readNext
returns a timeout error in the mysqlConn.readPacket
method.
Checklist
- [x] Code compiles correctly
- [x] Created tests which fail without the change (if possible)
- [x] All tests passing
- [x] Extended the README / documentation, if necessary
- [x] Added myself / the copyright holder to the AUTHORS file
Could you list some real world examples that need distinguish net timeout?
Could you list some real world examples that need distinguish net timeout?
All network errors now are replaced with ErrInvalidConn semantically unclear
We need to go back to the configuration center to get the new IP in the case of MySQL master-replica switching or master broken. but the timeout error need to be ruled out, as it can be caused by timeouts with long SQL execution times
I agree this is a good thing to merge. Just ran into this problem myself: I had SQL code that never terminated, and I reached my query timeout limit. Scratched my head quite a bit, as the error message led me to believe that there was something wrong with the setup of my connection. If the error message had said something about a timeout, it probably would have helped.
I had SQL code that never terminated, and I reached my query timeout limit. Scratched my head quite a bit, as the error message led me to believe that there was something wrong with the setup of my connection. If the error message had said something about a timeout, it probably would have helped.
Haven't you seen the timeout in error log? This driver shows error log when timeout happened.
https://github.com/go-sql-driver/mysql/blob/4591e42e65cf483147a7c7a4f4cfeac81b21c917/packets.go#L32-L40
Generary speaking, using read timeout for query timeout is not a good idea. Driver can not stop running SQL in the server. You should use MAX_EXECUTION_TIME() instead.
https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html#optimizer-hints-execution-time
I had lots of output from the logs. I generally look at error messages returned from the code first and foremost, and only after that fall back to the logs (which was eventually made me understand the issue).
Generaly speaking, using read timeout for query timeout is not a good idea
Probably true! I was working on existing code, where I was not the original author.
Would recommend listening to the users of your library here, it seems pretty clear that returning this error is a point of confusion. With that being said, thanks for writing and maintaining a great SQL driver!