On Thu, 2007-02-15 at 17:17 +0000, Mike Cardwell wrote: > * on the Thu, Feb 15, 2007 at 08:57:02AM -0800, Richard Pitt wrote: > > > I can think of a couple of reasons to do this - and lots not to: > > > > for: scalable central store that multiple machines can address with > > better?(different) locking than NFS provides > > for: different security model from disk store > > For: replication - "instant" "backups" > The problem with doing backups of mail in transit is the problem of sending duplicate messages if the backup has to be restored. If you require 100% reliability of the in-transit mail store then use something like RAID-10 and keep a hot system ready to move all the drives to at once.
> > against: performance - today's disk systems are essentially hierarchical > > file systems anyway - especially like Reiser. SQL generally requires far > > more resources for similar performance - especially with "blobs" of any > > size. RAM for SQL server takes away from RAM for disk caching. > > Yeah. Don't forget the db doesn't need to be on the same box as the mail > server though. > That is a given. The point is that mail in transit that ends up on the disk should only be there for a short period of time - and moving all such mail to a central store of any kind only adds one thing to the system of benefit as far as I can see - that of removing the original system's potential out-bound failure (IP blocking for instance) by allowing several other machines to attempt to deliver the messages. I'm doing this with one customer because they run up against max-per-day-per-IP limits by some of the larger ISPs and constantly changing the outbound IP of a single box is inelegant. > > against: most messages don't hit the data store anyway if the system is > > working the way it is supposed to > > against: central database can't be replicated (potential for multiple > > deliveries of single message) so scalability is limited and means a > > single point of failure > > Not sure what you mean here. I know it could scale well with MySQL5. > Especially with the recent clustering capability, and multi master > techniques. I'm assuming other db's will have their methods too... > You're right - if the database looks like a single instance, regardless of the number of machines involved in serving it, then this is not a problem - where the problem comes in is with older methods of syncing where it is fact replication between two or more distinct servers. It is then possible that both servers could end up delivering their local copy of a message if locking failed. > > There are likely others > > There's not a lot of point storing your mail in a database if there > isn't a pop/imap server that can access it. > You are confusing Exim with a facility like Courier-IMAP. EXIM is not used to handle recipient's mail past the delivery point - it hands that off to another process. If you mean that EXIM should be able to directly store mail into something like Courier's message store, then that is a different problem. > Someone recently mentioned the possibility of abstracting the storage > out so multiple types of backend could be implemented. That's one > of the best ideas I've heard in a while. This is the land of transports - where Exim hands off to other programs for actual delivery. Works for me. > > Mike > -- - Richard C. Pitt Pacific Data Capture [EMAIL PROTECTED] 604-644-9265 http://richard.pacdat.net www.pacdat.net PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
