That is entirely dependant upon how you do your backups and why you need to do them.
If you don't need to worry about restoring individual messages or mailboxes for users, then your focus for backups most likely switches to being able to handle hardware failures. In that case, you have multiple replicas of your data, and whatever you're using for storage handles the failure between nodes, and knows where to redirect requests for data that was on a dead node. In terms of point-in-time backups/snapshots of data, I don't see any reason why a combination of some sort of snapshot technology (which is most likely what you should be using as part of your database backups to ensure near-continuous/consistent backups) couldn't trigger a snapshot across different set of machines. The changes I'm going to propose won't affect anyone who wants to continue to store their mail bodies/parts in the database. In fact, that would stay at the default. For those of us who need to scale big on commodity hardware, they will give us another option. Regards, Chris Boulton Lead Engineer BigCommerce / Interspire Email: [email protected] Phone: +61 2 8003 4113 Web: http://www.bigcommerce.com Web: http://www.interspire.com On Mon, May 9, 2011 at 9:55 AM, Reindl Harald <[email protected]>wrote: > > > Am 09.05.2011 01:38, schrieb Chris Boulton: > > Speaking from a purely "part"/blob view, there are better solutions than > a database for storing such information. > > An RDBMS is great for 95% of what DBMail does, but mail parts could be > stored better. Doing so allows you to scale > > different parts of your system - I can guarantee that it's going to be > more difficult to scale databases with > > massive blobs as opposed to just simple sets of relational data. > > and how will you do replication/backups consistent if you have half of the > data > in some "nosql"? one point to scale the system is to have fallbacks for > readonly > data needed for the MTA, making backups of a temporary stopped salve > without > interrupt the main services and THIS is the real strength of dbmail > > > _______________________________________________ > DBmail mailing list > [email protected] > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > >
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
