This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi All, I'm looking into how we can use Lightspeed within our servers in a P2P system where load is distributed across multiple nodes in several parts of the world. We will be upgrading to SQL server 2008, but we're limited to workgroup edition due to cost. I'm looking at implementing bi-directional merge replication with no more than 2 peer nodes in a group. This is a limitation b/c we have 2 issues.
The bidirectional merge replication can't support multiple schema versions.
For this example assume we have 3 nodes, A on schema version 121, B on 120, and C on 120.
Messages from B and C can be passed to A as there is always a defined path from previous schema versions to new schema versions. However we don't want B and C to pass to A. Here is how I envision the upgrade process running.
The only way I can see getting around this is writing our own p2p replication scheme as we don't seem to be able to do this with the merge replication. Is it possible for us to have a post save event in LS, which asynchronously publishes the values to other nodes? I'd like to keep this as decoupled from LS as possible. I.E. queue up all changes and saves, then when a commit is executed successfully publish the changes. Has anyone done anything similar, and there any caveats I should be aware of before I start prototyping this?
Thanks, Todd |
|
|
Hi Todd, Couple of questions;
Jeremy |
|
|
The ultimate goal is 0% downtime, we'll have 3 systems across the world initially linked to smart DNS systems (geo dns magic), but we'll be expanding from there
Near real time is what we're aiming for. In the event a node crashes before it's data has been synced, other nodes will simply re-process the lost data from our external data sources. When a join of the group occurs in the event of a conflict the most recently created row takes precedence, and old data will be deleted and replaced by the new.
|
|
|
Understand. It does sound as though you probably do need something custom to meet the schema and latency requirements. Certainly I am not aware of any specific solutions, but there is likely something 3rd party on the market that might provide you with a solution so if you have not had a good hunt around it may well be very beneficial to do this to save yourself a lot of pain. I would also definitely investigate the Sync Framework further first to rule it out since it does provide a lot of good infrastructure and I believe it should meet the general requirements. In terms of LightSpeed, there are no hooks currently available to "get a list of the entities which are about to be committed / were committed", but I do think this is something that is going to be best covered at the database level or via a seperate process rather than in the primary applications code since you have to deal with network failures and the like and may need to start queuing changes or tracking via timestamps. Keen to hear how you progress with this however! :) |
|