WAMP, localhost, Mediawiki: Cannot access the database

From MXnet
Revision as of 23:59, 1 December 2015 by Laura (talk | contribs) (Error Messages)
Jump to: navigation, search

This is just a draft. There is more to the story than this. I'm still googling and tweaking. Stay tuned for more morbid details on The Bug that Ate a Week of My Life!

Mediawiki on localhost

Since 2:42 PM on 14 March 2009, I have run a private wiki for myself on a WAMP stack--6.5 years and counting.

I have migrated the wiki from one desktop to another and installed it on two different laptops.

I have never had everything work perfectly right out of the box, but I have never been frustrated for too long. People have solved all of the basic problems more than once, and it has been just a matter of googling around long enough to debug the setup.

All that has changed.

I've found a bug that has defeated me.

Mediawiki 1.26, WAMPserver 2.5, and WAMPserver 3

Error Messages

Shorter version

Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Cannot access the database)

With debugging and backtracking enabled

Cannot access the database: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ())


#0 C:\wamp\www\mediawiki\includes\db\LoadBalancer.php(842): DatabaseBase->reportConnectionError('Unknown error (...')
#1 C:\wamp\www\mediawiki\includes\db\LoadBalancer.php(537): LoadBalancer->reportConnectionError()
#2 C:\wamp\www\mediawiki\includes\GlobalFunctions.php(3631): LoadBalancer->getConnection(-1, Array, false)
#3 C:\wamp\www\mediawiki\includes\User.php(1208): wfGetDB(-1)
#4 C:\wamp\www\mediawiki\includes\User.php(397): User->loadFromDatabase(0)
#5 C:\wamp\www\mediawiki\includes\User.php(362): User->loadFromId(0)
#6 C:\wamp\www\mediawiki\includes\User.php(2459): User->load()
#7 C:\wamp\www\mediawiki\includes\User.php(1167): User->getToken(false)
#8 C:\wamp\www\mediawiki\includes\User.php(365): User->loadFromSession()
#9 C:\wamp\www\mediawiki\includes\User.php(2029): User->load()
#10 C:\wamp\www\mediawiki\includes\User.php(3204): User->getId()
#11 C:\wamp\www\mediawiki\includes\MediaWiki.php(627): User->isLoggedIn()
#12 C:\wamp\www\mediawiki\includes\MediaWiki.php(476): MediaWiki->main()
#13 C:\wamp\www\mediawiki\index.php(51): MediaWiki->run()
#14 {main}
reportConnectionError "Unknown error"

How it looks when MySQL is totally disabled

Warning: mysqli::mysqli(): (HY000/2002): No connection could be made because the target machine actively refused it. in C:\wamp\www\mediawiki\LocalSettings.php on line 152

Connection failed: No connection could be made because the target machine actively refused it.

Not a code or configuration problem

Except for a few times when I shot myself in the foot while debugging, the proof that the PHP code base and my configuration are correct is that I can immediately obtain the page I want by reloading the page.

It is only on the first call after a long time (five minutes? ten?) of not accessing the wiki that the problem occurs.





Malware Bytes



Ugly Workaround

Because the connection ALWAYS worked on the very next try after a failure, I thought that perhaps I could arrange a sacrificial connection to feed the ravenous Connection Monster; while it was chomping on the carcass, the real Mediawiki connection might sneak by unnoticed.

So I put this in my LocalSettings.php:

$servername = "";
$username = "dbuser";
$password = "dbuserpassword";

// Create connection
$conn = new mysqli($servername, $username, $password);

// Check connection
if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
#echo "Connected successfully";
#die("test finished");

This idiotic connection hasn't ever failed yet.

And the wiki page hasn't yet failed to connect afterward, either.

Pasta faggiole!

I hate it.

But not as much as I hate seeing the "connection failed" page.

Not yet.


  • [MediaWiki-commits [Gerrit] Add support for connect_timeout - change (mediawiki...PoolCounter)]
The intriguing line: we implement here what we already do for mysql connections: if we set a connection timeout to a very small value (in the order of magnitude of twice the RTT to the poolcounter server) and retry twice, we can have very fast failures in case one server goes down, and the failover to the other active servers would happen almost harmlessly.
I'm convinced this is a clue, but I haven't waded into the code to see what I might be able to play with.
David Random's essay on this page is superb. It didn't fix what ailed me, but it made me feel that I was understanding the problem better.
Contains an excellent set of links to various tips and tricks, as well as making some fresh suggestions.