Russian Version

Summary.

In the third part we discussed methods of application debugging in cases when query plays secondary role in the problem.

I'd like to bring your attention we only discussed most frequent cases while MySQL server has a lot of parameters which of them can affect application. Analyze parameters which you use. One of the methods is run problematic query using MySQL server running with option --no-defaults and examine if results are different for MySQL server run with parameter which you use. If results are different analyze why parameter affects it and solve the problem.

Method #24: check problematic queries using MySQL server running with option --no-defaults and compare result.

Below I place list of methods which we studied in this part.

Method #15: check value of max_allowed_packet and size of data and SQL queries if MySQL server returns syntax error for correct query.

Method #16: check value of wait_timeout and other timeouts if you get error "MySQL server has gone away"

Method #17: check value of connect_timeout in case of error "Lost connection to MySQL server at 'reading authorization packet'"

Method #18: always use error log

Mehtod #19: use general query log if error log does not contain enough information about server crash.

Method #20: always check if you have enough RAM for allocated buffers.

Method #21: set realistic value of max_connections based on your operating system resources.

Method #22: use monitoring tools of your operating system to find which application use enourmous amount of resources which lead to crashes of MySQL server.

Mehtod #23: Use option log_warnings=2 to examine if you have rejected connections.

Method #24: check problematic queries using MySQL server running with option --no-defaults and compare result.

Back Content Forward



Author 2010 Sveta Smirnova
COPYRIGHT © 2010 S.Smirnova and S. Lasunov
sveta_at_js-client_dot_com