Re: [exim] dbm to MySQL migration

Mike Meredith wrote:

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

ACK. Safest viewpoint. They can break.

We also run ONLY via sockets though, never TCP, so that pushes us the other way,

>
> 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!

PostgreSQL can 'trigger' on a change beng committed, output in the right format
directly to the proper storage location from an SQL stored procedure.

No need to deal with perl sin-tax.

If I have to do externals, I'd go ahead and use embedded 'C' binaries.
(though I do compile mine with Forth as well...)

>
> 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.

Live enough. The next child process spawned will get the most recent update.

>
>
>>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.

Ah! Another 'belt and braces' guy!

>
> 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.
>

ACK. Dunno if any of us have mentioned it, but having the RDBMS does bring along
a massive collection of manipulation, verification, and statistical tools.

Bill