[daisy] Daisy multi-server replication using export/import?

[Bruno Dumon]

On Wed, 2007-06-13 at 12:02 -0400, Mindaugas Idzelis wrote:
> In an effort to increase availability of the Daisy server what is the best 
> way to implement fail-over? We would want to have at least 2 servers that 
> can be switched to and from quickly in case one goes down. 
> 
> At first, we were going to use our daily backups of our production server 
> and restore them to the failover server. This would work, but our backups 
> are not performed every day since they take too long (although, we may 
> start doing this since Daisy 2.0 backups lock the repository for far 
> shorter a time than in 1.5) Plus, the synchronization story is not good 
> since backups are full-replace instead of incremental. The fail-over 
> repository would have to be "read-only."
> 
> In reading more about Daisy 2.0, I discovered the import/export feature. 
> It seems that the "import tool is smart enough to not update documents if 
> there are no changes, so that no unnecessary update events are caused." 
> This seems like it would be a good way to set up some replication between 
> servers. Every night, we could "export" a copy of the production 
> repository to failover server. If the production server ever goes down, 
> users could then use the fail-over. 
> 
> My questions are  - what happens when changes colide? For example, lets 
> say that a user makes a change to a document on the production database 
> and then it goes down. The user then logs in to the failover server, sees 
> that their document is out-of-date (since this would only be synced 
> nightly) and (perhaps foolishly) makes changes to the same document. When 
> the production server comes back up, we want to sync all the changes that 
> were done to the failover server back to production. I assume that we 
> could just export the documents from the failover to production, and only 
> the changed documents will be updated. I assume that if a new document 
> were added to the fail-over server, it would transfer to production just 
> fine. Also seems like documents that were updated on the fail-over server 
> but not in production would transfer fine too. But the question is, what 
> happens to the document that was changed on both servers?
> 
> If anyone has any advice or if there are any better ideas for replication 
> out there please let me know. 
> 

Hi,

I don't think there's a real good solution for this sort of replication
or fail-over right now.

For the colide problem: from the point of view of the import/export
tools there is never such a problem. The import tool simply updates the
documents in the repository to match the content of the export.

Import/export can be useful for some sorts of replication, but for
fail-over like replication there's multiple problems that come to mind:

 - the two servers would need to have different namespaces, which is
technically not a problem but might look strange to users

 - the import tool uses the normal Daisy APIs to update/create
documents, causing fields like last-modified and -modifier to be set to
the time and user doing the import. Version numbers would obviously also
be different. JMS events are also generated, hence causing notification
mails to be sent (though this can now be configured to be discarded when
the updates are caused by a specific user). For all of these, solutions
are imaginable (e.g. make a distinction between user-oriented
last-modified and real last-modified, have a distinction between
original and replication JMS events, ...)

 - the import/export tools are mainly document-oriented, and won't e.g.
replicate the users.

These are just some things that come to mind, so up to you to decide if
these limitations are a problem.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org