Does the 'ignore_slave_server' work with this module?

the db_ignore_slave() does not work with AutoSlave, as AutoSlave takes care of this on a per-table basis.

To control the "assumed maximum replication lag", use the autoslave options in settings.php. It sounds like you may also want to enable the "global replication lag" option, which will force the use of the master db for concurrent users for the affected tables.

Example:

<?php
$databases['default']['default'] = array(
  'driver' => 'autoslave',
  'master' => 'mymasterdb',
  'slave' => 'myslavedb',
  'replication lag' => 30 // defaults to 2 seconds if not set. Standard Drupal's db_ignore_slave() defaults to 300 seconds (5 mins.)
  'global replication lag' => TRUE // defaults to false.
);
?>

Elaboration of "db_ignore_slave() does not work with AutoSlave": It has no effect :-)

Hi

Did this answer your question?

Ok. Let me know if you have other questions.

Hi

No problem. Do you have any insight to why these tables need to be "always master" on your setup? Then I will document it on the project page, perhaps even add them to the default settings.

Thanks

Hi szantog

Not sure how notification works when status is fixed, so I'm changing the status just in case :-)

The next page request load the data from slave, which is not in sync yet - and these not proper data go into memcache.

The replication lag mitigation feature should prevent exactly this.

How does your $databases['default']['default'] look? Did you try enabling the 'global replication lag'?

I may have a vague suspicion towards an isolation level issue, assuming your using MySQL innoDB. I'll investigate this further.

Oh, btw, are you also using the lock.inc or memcache-lock.inc bundled with autoslave?

Hi szantog

I actually found something that could be the culprit also when using "global replication lag".

In the latest dev version, I've tried to address these issues, which resulted in these fixes:
* AutoSlave now using a non-transactional connection for "global replication lag" including possibility for a better isolation level.
* Enable "global replication lag" by default

Try installing the dev version and add the new "init_commands" to the autoslaver driver declaration:

<?php
$databases['default']['default'] = array(
  'driver' => 'autoslave',
  'master' => 'mymasterdb',
  'slave' => 'myslavedb',
  'replication lag' => 30, // defaults to 2 seconds if not set. Standard Drupal's db_ignore_slave() defaults to 300 seconds (5 mins.)
  'init_commands' => array('autoslave' => "SET SESSION tx_isolation='READ-COMMITTED'")
);
?>

Let me know how/if it works.

Hi szantog

I think I finally figured out what's wrong. And I can't believe I didn't realize it before. Every query runs through autoslave, making autoslave able to detect which tables are being queried... except when using join() on a db_select(). Unfortunately, these a VERY common :-)

I'm currently thinking about how to hook into this. My initial thoughts are overriding the SelectQuery all together, or perhaps adding a tag or an extender to the query, thereby being able to alter it.

The latter seems easier to implement, though I'm not sure I can easily change the connection on an already instantiated SelectQuery object.

This problem seems to be what is interfering with the EntityCache ... and god knows what else.

There's a new dev version ready, where I've tried to address the issue with dirty tables not being recognized properly. Could you try it out?

Note, you'll have to copy the autoslave folder to /includes/database/ again, as it contains a new file.

Regarding EntityCache, I've discovered that this will only work properly when using the database as a cache backend. The reason is that, e.g. node save clears the cache inside a transaction.

I've been looking some more into this. Regarding the error with the entity_extract_ids(), I think I've traced it to the inherint problem with transactions and non-db cache backends.

I've created a cache wrapper in autoslave, which should make cache queries transaction safe.

$conf['cache_backends'] = array(
  'sites/all/modules/memcache/memcache.inc',
  'sites/all/modules/autoslave/autoslave.cache.inc',
);

$conf['cache_default_class'] = 'AutoslaveCache';
$conf['autoslave_cache_default_class'] = 'MemCacheDrupal';

Another way to solve it, could be just to use the database as a cache backend.

This is partly theoretical, as I have been unable to reproduce your exact problem (not knowing precisely what modules you're using and how they are configured). However, it does suit the case, since modules like file_entity do perform cache operations during node_save(), which is wrapped in a transaction.

With the cache wrapper, the core-patch I mentioned earlier in our chat should be unnecessary.

I've generalized the consistent cache wrapper: http://drupal.org/sandbox/gielfeldt/1946668

Let's just close it. I've set it to fixed, since the original issue with the site actually crashing has been solved.