This patch to Drupal core solves the problem of a multisite setup using db_previx where the variables table is NOT shared.

I have a multisite setup with many shared tables, and some site specific tables. Everything is shared except for system, blocks, variable, users_roles, permission, role, cache, cache_page, and cache_content. The problem I've encountered is that while the variable table is not shared, there are some things like the cron_semaphore that should be shared.

This is a generic solution that allows defining which variables are shared. So similar to how you define which tables to use in $db_prefix, you can now create a multisite_variable array in your settings.php. For example:

  $multisite_variable = array('cron_semaphore' => 1, 'cron_last' => 1);

This solution has the advantage over hard coding core variables, that if your site uses a contrib module that needs to share a variable, you don't need to modify core or the contrib module. Alll you need to do is add the variable to the multisite_variable array in settings.php.

This patch is for 5.x. I'll upgrade it to 6.x and 7.x if there's positive feedback. But since I need it for a 5.x site, that's what I'm starting with. If this gets traction, we'll also need to create the multisite_variable table in a hook_update_N handler. In my install, I just manually created it.

CREATE TABLE multisite_variable (name varchar(48) NOT NULL default '', value longtext NOT NULL, PRIMARY KEY (name));
CommentFileSizeAuthor
#2 295378.patch4.29 KBdouggreen
multisite.patch2.45 KBdouggreen

Comments

douggreen’s picture

douggreen commented

In 5.x, node_cron_last, node_cron_last_nid should also go into multisite_variable:

$multisite_variable = array('cron_semaphore' => 1, 'cron_last' => 1, 'node_cron_last' => 1, 'node_cron_last_nid' => 1);
douggreen’s picture

douggreen commented
Version: 5.9 » 7.x-dev
Status: Needs work » Needs review
StatusFileSize
new 295378.patch4.29 KB

I think that this is needed functionality, with little impact on core, so I've upgraded it to 7.x.

The precedence for this in core, is $db_url in settings.php, which has been around since Aug 2003, commit 1183.

moshe weitzman’s picture

moshe weitzman commented

Not sure this is worth the complexity. When I need to do this, I add a line at bottom of each settings.php which includes a small custom php file called ../settings_globals.php. I just override what needs to be overridden for all the multisites there. hope that makes sense.

douggreen’s picture

douggreen commented

@Moshe, I don't want to override the setting for each site. I don't understand your solution or you don't understand my use-case.

Say you have 3 sites that share common user information, but a different a different theme and many different settings, such as site name.

Site 1:

 $db_prefix = '';

Site 2:

$db_prefix = array(
  'default' => '',
  'system' => 'site2_',
  'blocks' => 'site2_',
  'variable' => 'site2_',
  'cache' => 'site2_',
  'cache_page' => 'site2_',
  'cache_content' => 'site2_',
  'cache_views' => 'site2_',
  'users_roles' => 'site2_',
  'permission' => 'site2_',
  'role' => 'site2_',
);
$multisite_variable = array('cron_last' => 1, 'cron_semaphore' => 1);

Site 3:

$db_prefix = array(
  'default' => '',
  'system' => 'site3_',
  'blocks' => 'site3_',
  'variable' => 'site3_',
  'cache' => 'site3_',
  'cache_page' => 'site3_',
  'cache_content' => 'site3_',
  'cache_views' => 'site3_',
  'users_roles' => 'site3_',
  'permission' => 'site3_',
  'role' => 'site3_',
);
$multisite_variable = array('cron_last' => 1, 'cron_semaphore' => 1);

In my example above, the variable table is either "variable", "site2_variable", or "site3_variable". When Site 1 starts cron, it sets the variable in "variable" table. When Site 2 starts cron, it checks the semaphore in "site2_variable." However, since Site 1 locked it in another table, it doesn't block. So in essence, the semaphore lock is per site and not per database. I think that this is broken. Especially since this setup shares the {node} and {search} tables.

This patch makes it so that you can split the variable table. While I think the only problem in core is with the cron_semaphore, I do imagine that there are other cases in contrib, which is how I came to this generic solution in the settings.php.

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs review » Needs work

The last submitted patch failed testing.

Jooblay.net’s picture

Jooblay.net commented

What is the status of this ticket:) Can we close this...

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.