from my last post “continuous data availability”, most ppl sent email expressing these confusing over “how the hell it actually works and differs from traditional methods” 🙂
For the working part we are publishing technical papers (on website) and for the rest –
Let me know, if anyone needs more information (and sorry for a re-post).
Latest posts by Jaspreet (see all)
- India’s Hottest Startups - September 7, 2008
- The case of SonimTech – And lessons we can learn - August 23, 2008
- The Druvaa Story – III - July 14, 2008
Hmm – cool! pardon my ignorance, it has been a while since I’ve been on this side of things.
I mentioned data merge because merge replication is one of the big winners for cross-continent use of data (not backup).
Memory leaks wise: You can inject runnable code anywhere now if you corrupt the stack – and the idea of CS and DS are history now (on Windows). Of course you’re right the code itself won’t be corrupted – it’s mapped in a separate untouchable area. Not that this is malicious but you have to test really hard for it. In any case it probably won’t apply since you don’t go in-proc.
will look forward to see a trial or such. All the best!
Hi Deepak,
thanx for the comments. It seems Data merge is specific to applications, we don’t (possibly can’t handle it).
Hmm, we are smarter than that. Filesystem hooks can’t capture raw writes from databases. We have a ultra small and portable “kernel” driver sitting on each host, which traps “all” I/O for configured volumes.
Reliablity: We give back ack to writing application only when its replicated/cached at caching server. So, that applications future decisions based on success and failure don’t suffer. And we maintain a (patent pending) write ordering to maintain strict ordering among writes.
Writes on caching server are serialized into a log(again patent pending), and hence much more faster than clients. Reducing latency and performance impact.
BTW, memory leaks are on stack or Data segment and don’t hamper anything in code segment. So, whats mapped in your memory is virtually unmodifiable by normal means.
regards
js
Hey Jaspreet: Thanks for that – darn fast change! Data merge replication means changes on both ends are merged. There’s “SyncToy” from Microsoft that can merge replicate directories.
I think I see what you’re talking about now; it looks like you replace or hook the filesystem API (or device) with your own and queue write operations into your destination (local or remote). Very cool concept (if I’m right).
You have to be ULTRA reliable. Lose one write somewhere and the entire data integrity is gone. I’m also assuming the Dhruvaa client is not a DLL or such which needs to be loaded in the client space (which means that it is in the app’s memory space and therefore can be corrupted by a memory leak or such)
But if you have a downloadable trial or such, I would love to give this a shot.
HI,
thanx for the comments. .. i have updated the ppt to incorporate the comments. Some fools like me just don’t learn 😉
Just to answer your questions here –
And 2). Each of the druvaa replicator components can work off-line (using some proprietary bit-maps to record whats changing) and can re-sync later.
Ans 3) Sorry don’t know what data “merge” means, but theoretically we can work with all applications (which include database). Tests to certify the same are being done at your end.
Ans 4) eeks, i must have been horribly bad in my ppt not to explain such differences. Hope the new (modified) ppt answers these questions.
regards
jaspreet
Perhaps this is just me but :
1) Font size. Okay this is way too small mate. I know diagrams are nice, but I can barely read them on the slideshare.
2) You introduce one more point of failure (local replicator) – does that not impact cost for the store-forward, and also net uptime rates when the local replicator fails (for instance)? How much is the impact?
3) Do you do data merge replication (databases across continents for instance)? What databases?
4) If you’re doing file replication across networks – how different is this from an rsync intermediary (i.e. set up rsync on a local machine, and then rsync from there to the remote location). The latter is free/open-source/reliable.