Settings

This section contains a list of all the options possible to configure AutoSlave with.

The most bare-bone AutoSlave configuration will assume default values for all options:

Options

• master
• slave
• tables
• watchdog on shutdown
• global replication lag
• replication lag
• invalidation path
• use autoclave schema
• affected tables backend
• bypass page cache
• preconnect
• flag all tables
• resync on cache miss

master

Type: array, Default: array('master')


This controls which "targets" should be used as masters. Targets will be tried one at a time, providing a failover effect. To use the slave targets in the event that the master fails use (assuming the 'slave' is set to 'autoslave'):


'master' => array('master', 'autoslave')

slave

Type: array, Default: array('autoslave')


This controls which "targets" should be used as slaves. Targets will be tried one at a time, providing a failover effect. To use the master targets in the event that the slave fails use (assuming the 'master' is set to 'master'):


'slave' => array('autoslave', 'master')

tables

Type: array, Default: array('sessions', 'semaphore', 'watchdog')


There are some tables where it does not make sense to track them and switch between them, because they are inherently write-heavy. This option controls which tables will always go to the master. For example to add the "users" table to the default list of tables:


'tables' => array('sessions', 'semaphore', 'watchdog', 'users')

watchdog on shutdown

Type: boolean, Default: FALSE


If using the dblog, strange recursive things can happen if an error occurs during connection to the master, since the dblog obviously needs the master to log its message. To avoid this, AutoSlave disables the hook_watchdog() during shutdown when this setting is FALSE. If you're using a non db based watchdog module, you should enable this setting.


'watchdog on shutdown' => TRUE

global replication lag

Type: boolean, Default: TRUE


When a table is written to, AutoSlave keeps track of this and instructs future requests to access the master db for this table until the data has been replicated. This controls whether or not that happens for all concurrent requests, or just the user (session) who triggered the write.


'global replication lag' => FALSE

replication lag

Type: integer, Default: 2


When AutoSlave keeps track of the tables written to, it uses an expiration mechanism to ensure that data has been written to the slaves. This setting controls the expiration of how long (in seconds) you believe the replication will take in general. When using the "db.accurate" backend for affected tables (see option 'affected tables backend'), this setting should suffice with the default value.


'replication lag' => 20

invalidation path

Type: string, Default: NONE


When a connection is down, AutoSlave does not remember this across requests unless this setting is used. By using this setting, AutoSlave creates a file (use a common storage if multiple webservers are present) to flag the connection as down. This prevents AutoSlave from unnecessarily trying to connect to this connection again. The AutoSlave module contains a cron job that checks invalidated connections, and re-enables them if they're working again.


'invalidation path' => 'sites/default/files'

use autoclave schema

Type: boolean, Default: TRUE


When using certain schema operations (like tableExists), AutoSlave will ask the slave server, if the table is considered slave-safe. To make AutoSlave always ask the master server, set this to FALSE.


'use autoclave schema' => FALSE

affected tables backend

Type: string, Default: autoslave.affected_tables.db-accurate.inc


Determines which backend should be used for storing information about which tables are slave safe at any given time. The default backend will always connect to the master and compare the data to determine if the slave is in sync. The following backends are available bundled with AutoSlave:

• autoslave.affected_tables.db-accurate.inc (uses data comparision of master/slave + minor expiration)
• autoslave.affected_tables.db.inc (uses expiration)
• autoslave.affected_tables.memcache.inc (uses expiration)
• autoslave.affected_tables.mongo.inc (uses expiration)

The "db-accurate" is the default, as this is the most robust solution (read: protects best against race-conditions). However, it may be desirable to use e.g. mongodb or memcache as the backend, since this will make AutoSlave only connect to the master database, if there's a need to. The mongo/memcache backends are relatively safe except in cases where the replication "clogs up"


'affected tables backend' => 'autoslave.affected_tables.mongo.inc'

bypass page cache

Type: integer, Default: 0


When using page cache (either Drupals built-in or Varnish or similar), it may be desirable to let traffic through to the webserver, in order for users to see content which they recently updated themselves. By default, AutoSlave does this for the amount of time specified in the session variable 'ignore_slave_server', which automatically computed. The 'bypass page cache' setting can override/complement this.


'bypass page cache' => 60

preconnect

Type: boolean, Default: FALSE


By using this setting, AutoSlave will connect to both master and slave connection as soon the AutoSlave connection is opened. This will cause AutoSlave always to open a connection to both the master and the slave. This setting is an attempt to prepare for a robust nested autoslave config (which is still not working properly), but besides that, the use case for this setting is probably nil.


'preconnect' => TRUE

flag all tables

Type: boolean, Default: FALSE


When an update/insert or similar write query is issued, only the first table in the query is considered to be the table actually written to. If you have modules that use database specific queries which are capable of e.g. updating to tables in one query, you will need to enable this setting.


'flag all tables' => TRUE

resync on cache miss

Type: boolean, Default: TRUE


At the beginning of a request, the backend for affected tables determines which tables are slave-safe, and uses this info throughout the request. However, since a request can take quite some time, there are the possibilites of race-conditions especially during scenarios when cleaning cache. To mitigate this, AutoSlave resyncs the affected tables if it encounters a cache miss (requires the use of the AutoSlave cache wrapper). The theory is, that while this will cause more queries to actually be performed against both the master and the slave (unless using memcache or mongodb affected tables backend), it will only do so during cold cache scenarios, which hopefully should make up very little of Drupals actual runtime.


'resync on cache miss' => FALSE

Connection specific options

These settings are per database connection and not for the autoslave connection.

• readonly
• weight

readonly

Type: boolean, Default: FALSE


If using slaves as a failover for master, AutoSlave needs to know that it is a readonly connection, so that the system may be put into readonly mode. You should always add the readonly option to your slave connections and also always be sure to use a readonly user for that connection to prevent corruption of slave data.


'readonly' => TRUE

weight

Type: integer, Default: 100


If using db's of different capacity, it may be a good idea to configure the weight accordingly, so that the db's of lesser capacity are not chosen as often as the ones of greater capacity.
Formula: weight / sum of weights * 100 = probability of selection in percent.


'weight' => 50