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
rcpitt@??? 604-644-9265
http://richard.pacdat.net www.pacdat.net
PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73
