Re: [exim] dbm to MySQL migration

Hi

I should point out that I'm allergic to using a database server hooked
into a live mail server, however ...


Sometime around Thu, 31 Aug 2006 22:58:04 +0800, it may be that W B
Hacker wrote:
> You will, however, also find my name on other posts saying we *use*
> SQL DB-driven Exim, but do NOT recommend it to others.
>
> Also - depending on an RDBMS engine means one more thing that can go
> wrong, so overall the DB-driven system is more resource-intensive,
> and somewhat slower and less robust than flat files or a BDB, GDB,
> CDB environment.

Of course if you were to use an RDBMS engine as a back end, and Perl
(or your scripting language of choice) generating the CDB files then
you don't loose in having something else to go wrong. Providing of
course your script checks that things haven't blown up!

You do lose the facility of being able to change the Exim data live,
but that (as discussed previously) isn't vital in many/most cases.

> Extensive testing is a must, and best done on an R&D box.

True enough!

Rolling your own solution based around a script does have an advantage
here in that you can migrate slowly ... some data being pulled from SQL
tables into CDB files, and other data being generated from text files.
Heck! When migrating from BDB to CDB files I even setup two routers so
that it would fallback to the BDB files if the CDB files were broken.

Rolling your own script to do this is tons of work of course, but it
may be safer and is more fun (I do have an unusual sense of fun).

As an illustration of how a script can work, I've essentially used much
the same script for years to scrape mail addresses from a collection of
Mercury servers, added scraping from an LDAP directory, generated BDB
files initially and now generate CDB files.

--
Mike Meredith, Senior Informatics Officer
University of Portsmouth: Hostmaster, Postmaster and Security
'The only politician I respect is Caligula.'