Andi Vajda wrote: > Having Chandler > re-publish all collections in the background could be close, assuming > bandwidth and load are not a constraint. Still, having backups seems a > safer route, no ?
Yes, certainly backups will be performed. Non-chandler users would be very sad indeed if all data disappeared forever. However, backups by their very nature jump back in time. You can do real-time replication of data, but if you do a rm -rf /, you'll just go ahead and delete that data on the copy too. When that happens, you can rollback (if your architecture supports it), but again, rollbacks jump back in time. The effect I'm describing I think is a unique property of having distributed data systems, in particular ones that are loosely coupled through something like an ETag. Without a great deal more overhead, we can't do a global rollback; only on either the client or server independently. How those two cycles interact and what additional support is needed to make that work well is the current discussion as I see it. I agree with the consensus that ETag-only synchronization is dangerous (and the real reason I raised the thread). As of today, without additional Chandler changes, you do NOT want me rolling back the server data (say to backups) in the unfortunate case the server was to lose data. > Now, with a service costing $, how about having a server that doesn't > ever lose any data ? with replication and whatever else is required from > a such a persistent data server to be reliable ? Since you set the bar at "bank levels" of data availability, I would approximately need more money than OSAF current entire budget. We can't have that, as I would much rather keep your lovely mug around than use up all the budget in achieving superhuman levels of server reliability. Let's do something realistic, and that's: + be able to failure of any given piece (or couple of pieces) of hardware + keep full backups as frequently as we can + make sure restoration works + just write things off for a while if a meteor hits our city and data center (though we'll work to fix that situation too) > Still, I'm wondering why data retention expectations are being set so > low. If my bank can have a server that doesn't lose my account data then > why can't we do the same ? Your bank does lose data. Their recovery procedures are designed in such a way that you don't notice. This thread is about designing just such recovery procedure. Without breaking the bank. -- Jared _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
