3

I'm investigating how to create a scalable drupal system where nodes can be shared across different sites. In order to support future growth, it is likely we will need to "plug in" more servers/sites into the network.

I was thinking that this would be best achieved with a central site for storing the master records, users, and permissions, and then the slave sites would hold copies of these where relevant. Not all sites will need all the nodes, only those that are linked.

Alternatively, the central site could store which site has the master record. That might make it easier to grow. Thinking of node id's, the end solution needs to cater for the fact that these numbers could easily hit the millions.

It may be a crazy idea and maybe Drupal is not the right platform for this too.

Any ideas?

UPDATE: The concept is similar to that of sharding and map reduce (my basic understanding that it), yet my biggest concern are the node id's. If the system hits the number of users/groups/nodes we are looking at, we could hit the nid int limit and experience performance issues well before that point too. So a distributed model seems to be the best direction.

4

Normally with drupal you would not have several databases each with their own fragment of the database, and combined you have a whole site.

With drupal 7, drupal now supports database masters and slaves from within the application. What this means now is say you need 3 database servers to support your sites non-functional requirements (availability, performance etc), you can now add:

<?php
$databases['default']['default'] = array(
  'driver' => 'mysql',
  'database' => 'drupaldb1',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver1',
);
$databases['default']['slave'][] = array(
  'driver' => 'mysql',
  'database' => 'drupaldb2',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver2',
);
$databases['default']['slave'][] = array(
  'driver' => 'mysql',
  'database' => 'drupaldb3',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver3',
);
?>

This definition provides a single "default" server and two "slave" servers. Note that the "slave" key is an array. If any target is defined as an array of connection information, one of the defined servers will be selected at random for that target for each page request. That is, on one page request all slave queries will be sent to dbserver2 while on the next they may all be sent to dbserver3.

The above is straight from the docs ;)

I would recommend the above approach as this is a supported configuration, if you decide to create your own custom drupal schema or load splitting algorithm - you now have to support it.

With drupal 6 - you are pretty much forced to use pressflow. Pressflow is a performance based fork from the drupal code base that tries to keep 100% API compatibility with drupal. Lullabot wrote an awesome article on database replication with pressflow 6.

It turns out lullabot released their views 3 slave query module on github as well, fork away!

|improve this answer|||||
  • thanks for this post. It is certainly VERY useful. I'll have a look at pressflow. – lordg Mar 12 '11 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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