An interesting front end is SQL Relay, http://firstworks.com/
My thinking on the database redundancy issue is a compromise with the
full-failover and the write-master+read-slaves ideas; There's a main
server with read/write (the master) and a slave with read only. The
primary and secondary MX idea is a very good one, and when the primary
goes down, the secondary will receive the mail but not be allowed to
insert it. Incoming messages will queue up between postfix and dbmail
(must be tuned not to attempt immediate retries, though) and once the
master is alive, will be delivered. In the mean time, everyone can still
read their mail from the slave (but no flagging, deleting or moving).
Aaron
On Thu, 27 Mar 2003, Roel Rozendaal - IC&S wrote:
> Hi lou,
>
> The problem here is that the database consistency is not guaranteed -
> the databases are not synchronized so behaviour seems pretty undefined
> when for example the imap daemon connects to another database in the
> mid of a session. The unique-id's and message_idnr's are no longer
> unique nor will the message_idnr guarantee the correct order of
> delivery; some messages/folders will suddenly be no longer available
> when a system fails and some others again will no longer be available
> as the first system is up again.
>
> We are still looking for some good replication funcionality but it
> seems that the logics for such failover system should be a database
> issue and not a dbmail one - the ultimate system would allow dbmail to
> connect to some front-end (preferrably local so network failure is
> shielded from dbmail) SQL interface which would implement all the
> failover functionality we desire: different groups of replicating
> clusters spread out over the world :)
>
> regards roel
>
>
> lou heeft op woensdag, 26 maa 2003 om 20:57 (Europe/Amsterdam) het
> volgende geschreven:
>
> > Ello group{s},
> >
> > some time ago i mentioned something about having a fallback database in
> > case the first one doesnt respond. I found it really usefull in the
> > following scenario.
> > I have domain.com and two MX records for it mx1.domain.com(5) and
> > mx2.domain.com(10),
> > and i`m using dbmail, let say the db on mx1 is gone, what happens, mx2
> > wont help me, but
> > with this patch if dbmail service on mx1 cant connect to it`s primary
> > db it`ll to the
> > secondary at mx2, where db1 and db2 are quite aware with it`s data in
> > sense of
> > replication.
> >
> > kinda
> > if(conn1 == fails){ tellus; conn2; if(conn2 == fails) { tellus; return
> > _err; } }
> > of course with each connect N it`ll try to connect to db1 before
> > falling back to db2;
> >
> > ligthly tested with pgsql/mysql agains dbmail-1.1(from
> > http://www.dbmai.org), it`s quite
> > simple, though i cant say how it`ll work on your mailservers.
> >
> >
> > let me know if i did something wrong. sometime (when i find it) i`ll
> > try to change the
> > stuff to use more than 2 dbs and not to be so static. Hope Eelco, Roel
> > would be keen on
> > impl something like this permanently?
> > (patch attached)
> >
> >
> > cheers
> > -lou
> >
> > --
> >
> > Lou Kamenov AEYE R&D [EMAIL PROTECTED]
> > FreeBSD BGUG http://www.freebsd-bg.org [EMAIL PROTECTED]
> > Secureroot UK http://secureroot.org.uk [EMAIL PROTECTED]
> > Key Fingerprint - 936F F64A AD50 2D27 07E7 6629 F493 95AE A297 084A
> > One advantage of talking to yourself is that you know at least
> > somebody's listening. - Franklin P. Jones
> > <dbmail-fallback.patch.gz>
>
> _________________________
> R.A. Rozendaal
> ICT Manager
> IC&S
> T: +31 30 2322878
> F: +31 30 2322305
> www.ic-s.nl
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
