Thomas, > It should look like this (planned setup): > | Filter F1 | <=> | F1DB1 | => | F1DB2 | > | Filter F2 | <=> | F2DB1 | => | F2DB2 | > > Instead of (current setup): > | Filter F1 | <=> | | => | DB2 | > | DB 1 | > | Filter F2 | <=> | | => | DB3 | > > (DB3 is/was there to allow us to create a snapshot and add another DB > server once needed without the need to take one of the two primary DB > servers down) > > So why split DB? I would loose the benefit of a centralized DB wouldn't > I? Some reasons making me think that it could be a good idea are: [...] > What I'm concerned about: > - Penpals. Not using them right now, so no experience on my side. But > I want to use them in the near future - so what impact would such a > setup have?
Penpals could live in a split db setup (a planned setup), although if some mail would flow out through F1 and a reply would come back through F2 these messages would not be matched and will have no penpals benefit (which is no worse than not having penpals at all). If you could partition your users/subdomains so that each filter would handle both the outbound and the inbound mail for a user, this would solve the problem. This could be made possible while still maintaining a uniform e-mail address appearance to the world. For received mail a front-end MX could map an external recipient's address to something like [EMAIL PROTECTED] and send it through a filter at hostX. For outgoing mail / mail submission some mechanism would need to route each user's submitted mail through his associated hostX filter. Such approach would allow full partitioning of users across independent mail paths, including having their mailboxes each on his associated system. Bounce killer feature is also using a pen pals feature (I'm often using a term 'pen pals' interchangably with 'SQL logging', as pen pals is just a simple additional query layered on top of SQL logging). Unlike plain pen pals, the bounce killer relies on the fact that it can reliably find in a database a Message-ID found attached to a bounce-to-be-saved. If a record can not be found, a bounce is killed (even if it were a valid bounce to our previous outbound mail). So for a 'bounce killer' feature the SQL database must provide the records sought - which means that either users need to be fully partitioned (inbound and their outbound traffic) as described above, or that you centralized current setup is needed (or amavisd bounce killer feature needs to be disabled and some other mechanism used instead). > - MySQL (5.1) or PostgreSQL (8.3)? Hehe... Let me know your opinion ;-) MySQL (InnoDB) performs better than PostgreSQL 8.x for SpamAssassin's Bayes database. PostgreSQL performs much better that MySQL 5.x for amavisd SQL logging purges (on a classical non-partitioned setup) without keeping a database locked for long times, which is why I switched our amavisd database to PostgreSQL two years ago (there were no talk about database partitioning back then), but kept Bayes on MySQL. The AWL database is not problematic, it behaves well on either server. For Bayes db you could live with separate databases - each filtering system could use and maintain its own Bayes db, with no syncing or replication between them (except for occasional backups). It may be somewhat less effective and false positives should be fed to each database, but should not be too bad. > - Is there some better way to achieve a VERY scalable setup I didn't > think about? For some ideas (User clusters) see http://www.danga.com/ and their Usenix paper http://danga.com/words/2007_06_usenix/usenix.pdf Mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
