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
