Posted by lwalley on October 24, 2009 at 4:41am
Okay, so I have a question. Based on your experiences, what are the best approaches for handling multi-site management? Off the top of my head some options are:
- Independent databases with manual multi-site management of domains or subdomains through directory structure of sites folder.
- Independent databases with single domain but with subdomains automatically matched to databases i.e. does not require individual directory in sites folder for each subdomain.
- Shared database with Domain Access, with or without table prefixing.
- Shared database with Organic Groups and Subdomain.
What experiences do you have with any of these options, or are you using a different solution? What scalability concerns if any do you have with the shared database approach? What are the problems of not sharing databases, e.g. user access, content sharing? I'm particularly interested in Domain Access versus Organic Groups, any thoughts?
Comments
Multisite Directory and User Base
From my experience the multisite directory structure is defined in Drupal under sites/all directory and the subdomains for the multisite has separate and independent directories.
If the main domain is mainsite.com and subdomains are sub1.mainsite.com, sub2.mainsite.com and sub3.mainsite.com. The directory structure would look like the following:
/mainsite.com/sites/all/sub1.mainsite.com
/mainsite.com/sites/all/sub2.mainsite.com
/mainsite.com/sites/all/sub3.mainsite.com
The main site and the sub domains can be installed and run in single or multiple databases. In single database installation it is possible to maintain independence between the sites by prefixing tables to set a side tables for specific site.
If the sites has a common user base or share same modules then single database installation may be preferred.
Single database makes maintenance and upgrade relatively easier. Multiple database is better for scalability.
Single database installation can increase the number of tables of the database. Since a typically Drupal installation has few hundreds of tables, that wont be much of a problem. It can also create confusion of content display if same prefix are shared by modules that create or display content.
Wildcard DNS and auto matching subdomains to database names
Thanks wisdom. With regards to subdomains (or rather is the correct term 'host name'?) I wanted to mention an automated mechanism that the LifeDesks team are using that uses a combination of wildcard DNS and code that uses the subdomain (host name) to return the correct database connection, i.e. subdomain (host name) = database name. This means that only one folder (in addition to 'all' and 'default') is required in the sites folder i.e.:
sites/default
sites/all
sites/example.com
Then whatever subdomain (host name) is requested e.g. sub1.example.com maps to databases name sub1. This avoids the need to manually maintain the sites folder, or automatically create directories or symlinks as is done with projects such as Network Manager.
Could you explain a little more your last comment "It can also create confusion of content display if same prefix are shared by modules that create or display content."? Would you recommend prefixing content tables or using single content tables? Have you investigated or reached any of the database limits for example for number of tables in a single database, or number of records in a single table?
"It can also create confusion
"It can also create confusion of content display if same prefix are shared by modules that create or display content."
Say the view module and another content generating module (page, feed, etc.) is installed with same table prefix for each site. It is possible unless careful filtering is set site1/content?id=3 to be displayed in other sites in page or block view.
"Have you investigated or reached any of the database limits for example for number of tables in a single database, or number of records in a single table?"
Though I never reached a fraction of that, in the order of hundreds of thousands ( even few millions) of tables and records are acceptable theoretically. The most determining factor is the nature of a database query and the size of the data to be imported and exported.
Solutions which automate multisite installation and allow central interface management I have not explored them well. At the time when I set up few of them about a couple of years back there was no any mature and stable solution but there was some promising beginnings. Those may have reached to fruit at this time and worth further research.
I have try with Domain Access module
I have been trying Domain Access module (http://drupal.org/project/domain) for a couple or year, in a intranet web site (cuban health ministry).
It have been working quite good. In the module settings i define sites 1, site 2, site...., until site 22.
This module share the same tables for multiples sites and domains.
It allow define several option for each sites (like it was complete different sites) like Site frontpage, Site mission, Primary and secondary links menu, Site offline message, Theme, and others options.
I used Domain Prefix module (a Domain Access submodule) to create new url_alias tables for each domain, to allow duplicate url in different domains, for example http://site1/contact, http://site2/contact, http://site3/contact. because using only one url_alias table it´s impossible.
I found the module quite useful to have multiples sites with only one installation. I try the others possibilities even y try the virtual site module (http://drupal.org/project/virtual_site) and subdomain module (http://drupal.org/project/subdomain), but i found the Domain Access module more robust and easy to maintain.
Excuse my English please
neopulse thanks for your
neopulse thanks for your insights into using the Domain Access module, it is good to know that you have experience of this working well. The idea of being able to have completely independent user interfaces for each 'site' whilst being able to share content tables is interesting to me.
Presumably nodes are associated with a site? Are you able to associate a single node with two different sites, for example: http://site1/node/1 and http://site2/node/1? Do you use Views (http://drupal.org/project/views) module? Are you able to create a view on site 1 that includes nodes that would link to site2?
For example, say you had two research groups:
http://researchgroup1
http://researchgroup2
They both use the Biblio module and produce bibliographic nodes. Each research group has their own 'Biblio section, showing only biblio nodes created by that group:
http://researchgroup1/biblio which includes biblio nodes http://researchgroup1/node/1 and http://researchgroup1/node/2
http://researchgroup2/bilbio which includes biblio nodes http://researchgroup2/node/3 and http://researchgroup2/node/4
Could you then have a third site that showed all biblio nodes from every group?
http://allresearchgroups/biblio which includes biblio nodes:
http://allresearchgroups/node/1 with link to http://researchgroup1/node/1
http://allresearchgroups/node/2 with link to http://researchgroup1/node/2
http://allresearchgroups/node/3 with link to http://researchgroup2/node/3
http://allresearchgroups/node/4 with link to http://researchgroup2/node/4