Staging to Live Setup with MidCOM

1. Requirements
2. Setting up the live database
3. Enabling replication
4. Advanced topics
1. Many to many replication
2. Cross-site collaboration

Requirements

• Working Midgard site that will be assumed as the staging database
• MidCOM 2.8 from packages
• Midgard 1.8.6 or newer

• Working MidCOM cron setup, sample crontab lines:

  #MidCOM Cron runs
  */2  *    * * *   root  /usr/local/bin/midcom_services_cron.sh
  30 *    * * *   root    /usr/local/bin/midcom_services_cron.sh hour
  15 5    * * *   root    /usr/local/bin/midcom_services_cron.sh day
  

Setting up the live database

A 1:1 copy of the staging database will be used as base for the live one. This means that you should ensure you have a version of the site that is ready to go live when you set this up (or do it early in the construction).

• Create on the staging database host records for the live hosts as well (usually port number is used to distinguish between the two)
• Use datagard to create a fresh database midgardlive
• Copy the database: mysqldump -uroot -p<yourpass> --opt midgard | mysql -uroot -p<yourpass> midgardlive
• Copy BLOBs: cp -aux /var/lib/midgard/blobs/midgard/* /var/lib/midgard/blobs/midgardlive/
• Set up Apache virtualhosts for live hosts (remember to change the database in MidgardDatabase directive)
• Ensure the two virtualhosts use separate log files and Midgard pagecache directories (obviously less necessary if replicating between separate servers)

Enabling replication

• Create replication queue directory /var/spool/midgard/replicator_queue/sitegroupname and give Apache ownership of the directory

• Enable staging2live user interface in MidCOM

  $GLOBALS['midcom_config_local']['metadata_approval'] = true;
  $GLOBALS['midcom_config_local']['metadata_scheduling'] = true;
  

• Create staging2live subscription in Website - Midgard Administration UI - Manage Replication using the HTTP transport

  • Input the URL of your live site, http://www.example.net/midcom-exec-midcom.helper.replicator/import_post.php and SG admin username and password to the subscription
• Test the setup by first approving your root topic, and then editing and approving an article directly under it
  • If something doesn't work, check the Replication information view of that particular object

Advanced topics

Many to many replication

The new system supports this kind of scenarios as well, however be wary of replication loops. They are not necessarily caught by the framework correctly ever, and right now the loop prevention logic is trivial at best.

Cross-site collaboration

By replicating a single wiki topic tree (for instance) two sites can share content and by using a dedicated non-admin account for replication they can do this even if they do not trust each other ultimately since replication imports are MidCOM ACL aware.

Do see the point above about replication loops though.