|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #60663 stats on failed queries
Submitted: 2012-01-05 11:32 UTC Modified: 2013-02-18 00:35 UTC
From: sathia dot musso at gmail dot com Assigned:
Status: No Feedback Package: mysqlnd_ms (PECL)
PHP Version: 5.3.8 OS: debian 6.0.1
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
31 + 8 = ?
Subscribe to this entry?

 [2012-01-05 11:32 UTC] sathia dot musso at gmail dot com
It would be great if the extension would allow to understand easily which server 
is behaving badly. 
Suppose there are 4 slaves and one master, a simple select is constantly failing 
on one server for whatever reason. 
It would be great to be able to address the server which is having troubles either 
via callback or global statistics.

do you think it's something that could be added some day?


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-05 12:12 UTC]

Currently, we see this in the responsibility of the application developer. Fail over is intentionally very basic and basically left to the user, unless you configure automatic fail over (not recommended). Today, using defaults, a user has to take care of fail over (query fails, user shall handle standard error codes returned from API call used to execute query and decide if he wants to re-run query to trigger selection of another node). Today, the user is asked to maintain additional statistics like a list of failed nodes (hint: mysqlnd_ms_get_last_used()) himself.

The reason we do it this way is that fool-proof transparent fail over is close to impossible to realize. Thus, its an extra step to enable automatic fail over and automatic fail over is not recommended. Given that one has to do error handling anyway, why not collect whatever stats you want in your error handling code...

I hear you that this approach is not very comfortable. I fully agree that we should have some mechanism to read out which nodes have failed. I think, it is even desired to have the plugin maintain an optional black list of failed nodes. Nodes on the list shall be skipped for a user defined duration, for example, skip for the rest of the web request or skip for n seconds, whatever. Then, it would be nice if one could define a criteria for what makes a failed node for black listing. For example, if node returns error code X on connect or error code Y on query execution, put it on the black list.

So, yes, some day we want to improve it. Its not that much of a big deal to implement. Thing is, we would like to hear more from the users what exactly they need before we hack something. You made a great first feature request, maybe you have even some thoughts on how to embed it into a somewhat more complete solution for the fail over problem?
 [2012-01-05 12:12 UTC]
-Status: Open +Status: Feedback
 [2013-02-18 00:35 UTC] pecl-dev at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Wed Aug 10 14:05:44 2022 UTC