I am using Autoslave (https://drupal.org/project/autoslave) project for implementing mysql high performance and failover. I have successfully setup the mysql master/slave replication at the server and it is working perfectly. With the following settings taken from Autoslave documentation (https://drupal.org/node/1952990) for Master/Slave, I am trying to implement the following use cases:

  1. If Master is up and slave is down, master should entertain all the traffic (working fine)
  2. If Master is down and slave is up, slave should entertain all traffic in readonly mode (NOT WORKING).

With 2, what happens is as soon as the master db is down, the requests to slave also stops. The following are the contents of autoslave-invalidation-default.inc file after i take master db down:

$databases["default"]["slave"][0]["status"] = FALSE;
$databases["default"]["master"][0]["status"] = FALSE;

Its showing that both servers are down, where as slave is up and running. I tried with manually changing this file and changing slave status to TRUE, and the traffic is then successfully routed to slave.

Following are the relative contents of my settings.php file:

$databases['default']['master'] = array (
  'database' => 'dbname',
  'username' => 'username',
  'password' => 'password',
  'host' => 'master.ip',
  'port' => '',
  'driver' => 'mysql',
  'prefix' => '',

$databases['default']['slave'][] = array (
  'database' => 'database',
  'username' => 'username',
  'password' => 'password',
  'host' => 'slave.ip',
  'port' => '',
  'driver' => 'mysql',
  'prefix' => '',
  'readonly' => TRUE

$databases['default']['default'] = array (
  'driver' => 'autoslave',
  'master' => array('master', 'slave'),
  'slave' => array('slave', 'master'),
  'invalidation path' => 'sites/default/files',
  'flag all tables' => TRUE

Following is the error shown:

The website encountered an unexpected error. Please try again later.

Error message

The system is currently in read-only mode. Any changes you make will not be saved!
Warning: mt_rand(): max(0) is smaller than min(1) in DatabaseConnection_autoslave->rand_weighted() (line 1233 of /includes/database/autoslave/database.inc).
Warning: mt_rand(): max(0) is smaller than min(1) in DatabaseConnection_autoslave->rand_weighted() (line 1233 of /includes/database/autoslave/database.inc).
Exception: No master connection has been chosen in DatabaseConnection_autoslave->determineMasterTarget() (line 703 of /includes/database/autoslave/database.inc).

Kindly guide me of the any solutions/suggestions and/or possible reasons why is point 2 not working, where it's suppose to.


  • AutoSlave will only send the query to slave when "The query is not a write query (and not a select query with locking)". With that in mind, what are you expecting to happen when Drupal issues a write query when the master is down, considering your slave is read-only? And, more importantly I guess, how are you expecting it to happen?
    – Clive
    Commented Oct 4, 2013 at 14:57
  • Thanks for the reply. I get what you are saying. I just thought that if it is allowing read-only, it might have had logic of ignoring write queries altogether. But, it seems that its not the case. But that aside, the problem is that my test scenario is only doing read operations. Also, if I explicitly change the FALSE state of slave to TRUE, it starts to work just fine with sending all the requests to slave only. I wonder why that is the case. Why is it not automatically setting slave to TRUE, when clearly its not down.
    – KEINS
    Commented Oct 5, 2013 at 18:02

2 Answers 2


For read-only mode to work properly you must apply the patch from https://drupal.org/node/1889328 (currently committed to 8.x but not backported yet).

The patch https://drupal.org/files/1889328-1-query-options_1.patch will work for 7.x, though it has not yet been cleaned up according to review comments.

I'm not sure I've mentioned this in the documentation, but you must ensure that you use a read-only user for the slave connection when utilising the read-only functionality. Otherwise you may end up writing to the slave-db which could cause inconsistencies and consequently the replication to fail.

The mt_rand() is possibly due to the result of no connections being available (both servers have status = FALSE in the invalidation file). Servers are only re-validated during cron. If you take down the slave to test that scenario, and then spin up the slave again and take down the master without running cron in between, you may end up with the kind of invalidation file you posted.

  • Thanks for the detailed reply. I will try out the patch today and post if it worked or not. About mt_rand(). yes you are right, I debugged the code and there were no connections returned by the pool. My test scenario was build with keeping the cron in mind. With clean install, I simply tried with first taking master down, and the result was a FALSE status for both connections.
    – KEINS
    Commented Oct 7, 2013 at 6:28
  • The patch did not worked. I checked and I already had it when I was setting Autoslave for the first time.
    – KEINS
    Commented Oct 8, 2013 at 5:37
  • Ok. There might be a bug in the file invalidation then. Could you post the issue on drupal.org for better tracking? drupal.org/project/issues/…
    – Thomas
    Commented Oct 16, 2013 at 9:35
  • Bug logged at drupal.org/node/2116321
    – KEINS
    Commented Oct 20, 2013 at 19:07

Personally, I wouldn't be using a Drupal module to engage this purely because this should be offloaded into a system process away from your application.

If possible, try to setup MySQL replication instead and have that sitting within a failover safe architecture. You and your application's users will thank you. :)

  • 1
    Are you sure it really answers OP question and shouldn't rather be a comment?
    – Mołot
    Commented Jan 8, 2014 at 11:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.