Active
Project:
Provision CiviCRM
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
18 Mar 2011 at 14:12 UTC
Updated:
5 May 2013 at 19:06 UTC
Jump to comment: Most recent file
It has been requested a few times whether CiviCRM with Aegir can run into a separate database, as is recommended by the CivICRM documentation.
"Using a separate database is generally preferred - as it makes backups and upgrades easier. [...] Note that if you plan to use the Drupal Views module to display CiviCRM data within your Drupal pages, and if you are going to use separate databases for Drupal and CiviCRM, you need to ensure that your Drupal database user has SELECT permissions for your CiviCRM database." (http://wiki.civicrm.org/confluence/display/CRMDOC33/Drupal+Installation+...)
Separating the database may also allow better performance by putting the two databases on different MySQL servers (but might be useful only for very big sites -- since you usually want a master/secondary SQL server for backups, so having two master servers means you will need a total of 4 databases, that's a lot of servers to maintain).
So, in short, for most people, the advantage of separating the databases is to make backups and upgrades easier. In Aegir, however, this is not necessarely the case, since every time you will upgrade either Drupal or CiviCRM, you will want to migrate the site from one platform to another, and Aegir will backup your whole site anyway. If either the Drupal or CiviCRM upgrade fails, it will rollback all tables.
On the other hand, having things in separate databases requires more code and will cause new bugs. It will also make support more complicated. I would therefore wait until someone steps up to help implement and support it (or contract us for a specific project), since personally this is not my biggest priority, my sites would not use it and it would be less tested.
Right now, the priorities I have most frequent requests for are (and most of these are critical for a 1.0 stable release to make this module really usable): better cron support (wrap in drush), sort out a few bugs still in the path changes after an upgrade, upgrade support (should be simple, already in drush), automate more path configurations (custom css directory, custom php, etc.).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | civicrm_2dbs.png | 13.84 KB | ergonlogic |
Comments
Comment #1
ergonlogicThis is blocking broader adoption of Aegir among some CiviCRM implementors. Among other reasons are having separate backup schedules, and the ability to run the CiviCRM db on a different server. I'd like to look into it here at the post-CiviCon2013 sprint.
I still agree that having the two systems running off the same db is much simpler, so I'm planning on adding a switch to allow us to choose.
Comment #2
ergonlogicIn discussing this with @bgm, we agreed that the following would be necessary (but possibly not sufficient):
Comment #3
ergonlogicFor anyone interested, I'll be working on this in the '2dbs' branch of my provision_civicrm sandbox
Comment #4
ergonlogicWe'll need a hosting_civicrm module for the front-end setting(s). I'll merge hosting_civicrm_cron into that, and maybe add things like flushing civicrm caches, if that isn't handled by something else already.
Comment #5
ergonlogicI merged hosting_civicrm_cron into hosting_civicrm. I had been working on a feature branch to support per-site cron settings, so I merged that along the way.
Here's a screenshot of the UI I've implemented:
It allows targeting an arbitrary db server for the civicrm database, along with installing in the same db as the Drupal site. The choice is then reflected on the site node and edit pages similarly to the db_server.
I'm now working on saving the civicrm_db_server to the site context, which looks like it'll require implementing a 'service'. Also, this technique developed by @sfyn will probably be the way to save settings into the drush.php: http://community.aegirproject.org/content/contrib/passing-values-site-dr....
Talking with @agh1 and @totten, we discussed that restoring backups may cause contacts/accounts/uids to get out of sync. We figure the best solution for the time-being would be to join across the relevant tables in a post_ hook, and flag a warning if either side is NULL.
Comment #6
ergonlogicI've implemented a service in order to be able to save data to the site context, but I had to go back to Aegir 1.x to get it working. The technique is discussed in #1111254: Document the Hostmaster API, and I got it working by adapting aegir_http_basic. A fork of that project purports to work on Aegir 6.x-2.x, so I'll see if I can use that to get our code working too.
Unfortunately, defining a new service in Aegir 1.x requires that your Drush extension be installed within the Provision directory itself (e.g., /var/aegir/.drush/provision/provision_civicrm), which is pretty ugly, and not where 'drush dl provision_civicrm' will put the extension by default. Apparently that has been fixed in 2.x, and is one of my motivating factors for prioritizing this.
Anyway, we now have a property to test against before deviating from our current practice. I'll probably work on that in parallel to experimenting with the move to 2.x.
Comment #7
ergonlogicNotable architecture re-factoring related to this and other (Aegir 2.x, &c.) work: http://drupal.org/node/1982616#comment-7379364