The point of this "Standby" module - the solution I think people are after - is the ability to update code and files of an existing site without taking the site off-line - permitting WSoD on a live server, allowing for crudely implemented updates, and providing a deployment process for new modules.
Was playing with the Deployment 7.x-2.x-dev module for deploying content - perhaps not entirely relevant - but in regards to some thoughts others seem to have had (see initial paragraph under: http://drupal.org/node/205366 titled "Enhance settings.php to allow dual write") and a deeper level of Drupal I'm perhaps not familiar with yet but assuming is there.
Someone with better knowledge of everything could correct me where I'm making incorrect assumptions... but the conditions I assume this Standby module caters under, are as follows:
1) A single Drupal installation.
2) Two databases in sync with the active Drupal installation. Either the single Drupal installation writes to two databases identically, or the same result is achieved using MySQL replication. Ideally the site is in control of all this - ideally. Again though, I have no idea what I'm REALLY talking about here, so avoid joining my thoughts to bonobo monkeys, all you MySQL geeks out there~!!
3) Two file directories in sync with the single Drupal installation - the synchronization not ever-present necessarily - but synced when required to - that is, when a specific "standby" state is toggled (see below).
4) A "standby" state (of the site) during which:
- The active Drupal installation writes to the existing / same FILE directory but to ONLY ONE of the two DATABASES. The synchronous pair of databases at this point become dyssynchronous - not the same. And we rely on the next point to bring them back in sync.
- All database and file activity is tracked, stored, and able to be replicated later during this "standby" state. To bring the databases and file directories back in sync later. These operations monitored from source to destination; filtered when recorded, according to what tables / directories were "affected", perhaps with varying levels of treatment depending on how data or structure has changed. Recording conducted continually whilst in the "standby" state and the site LIVE. Having collected its own data this module could provide warnings and time limits on how long a site should remain in "standby", for review before putting the site again for a period of time into "standby" mode.
Hopefully this is a possibility. Could be a major performance trade-off, or some way to maintain a two-way deployment process as I initially thought. An early version of this idea was returned with the suggestion to post it under the Services or Deployment queue. In any case, it stands on a wealth of background efforts surrounding what I'm suggesting be solved, but I know the most staggering conundrums can sometimes have simple solutions overlooked. Here's hoping for your discussion.
Comments
simpler option
Integrating two databases, one with new nodes, and another where update.php has run, seems fearfully complicated.
What about a modified maintenance mode: instead of taking your site offline, urls still show up, but changes are not allowed. Perhaps there could even be a user-role where you would set very limited permissions, and everyone who isn't an admin would have only those permissions when in standby mode.
My intuition is that it won't be easy to make a standby mode that works more easily than setting up a staging-to-live deployment... especially once you're playing with mirroring databases anyway. But maybe for simpler brochure and blog sites you could improve the maintenance mode just enough and it would be useful.