Hi,
I must say that Klas's approach seems to be the best to me. MySQL
already has
very acceptable support for replication and it would be foolish to rely on a
script based solution that will never work half as well. PostgreSQL also has
one or two replication implementations/projects if I am not mistaken. From
the DBmail point of view, the only thing that changes is that we use one
connection for READ operations and another for WRITE operations, this could
be implemented for each db backend if necessary..
Only queries that succeed on the master server are ran on the slave. If
a
query that succeeded on the master fail on the slave, replication will be
halted until the problem is manually resolved I think.
Cedric
Le 6 Décembre 2002 04:31, Roel Rozendaal - IC&S a écrit :
> Hi Klas,
>
> we are currently looking out for some kind of replication - your way of
> doing it is interesting. However I would prefer a system where the
> replication is completely transparent for dbmail mainly because of
> postgresql/other database support: one of the main objectives of dbmail
> is complete freedom for database choice as fas as dbmail is concerned.
> Implementing this patch would break the symmetry giving extra
> functionality only available with mysql.
> Furthermore could you be more specific on your plan of recovery if one
> of the machines crashes? Seems to me that you would have to rebuild
> your dbmail system setting it up for 1 database.
>
> Our plan for the moment is to have two databases: one used in
> production and the other as hot spare. When the live machine is used,
> the succesfull update/insert/delete queries are performed at the hot
> spare as well (by means of some script running in the background). At
> failure, all there is to do is change dbmail.conf and send a SIGHUP to
> the daemons. This system has one major drawback: if the
> update/insert/delete query fails on the hot spare but already has
> succeeded on the production machine. We haven't figured this out
> completely but then again: if the query fails probably something's
> really wrong with the hot spare. What do you folks think about it?
>
>
> Klas Handel heeft op vrijdag, 6 dec 2002 om 00:55 (Europe/Amsterdam)
>
> het volgende geschreven:
> > Hi,
> >
> > We're using dbmail together with MySQL. Since our database is quite
> > large and we have a lot of users we want to spread our load a little
> > bit. We have setup our database in replication (master/slave) mode.
> > Then what we want to do is force all read (select) activities to
> > our slave (slaves) and all write (delete, update and insert) to our
> > master database.
> > I've created a patch which does this (only MySQL). What you need to do
> > is #define the READ_DATABASE parameter in "db.h". Then there are some
> > addition parameters to be set in "dbmail.conf" (read_db, read_user
> > etc.).
> > If READ_DATABASE isn't defined dbmail should work as normal, i.e use
> > only one database.
> >
> > I did create a patch earlier and sent it to the list, but it's not in
> > the
> > new release so it's probably nothing that people are interested in?
> > Still we are using it so I send it again...
> >
> > (The patch version is the cvs from 2002-12-05)
> >
> > Have a nice day!
> > /Klas
> > [EMAIL PROTECTED]
> >
> > <db_replicate.patch>
>
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
