First, a thank you all for the suggestions relating to SQL. It seems SQL support is better than I expected and I will give it a try.
Alex Woick wrote: > Don't overrate Bayes. The system has been running without Bayes for roughly 3 years (with incremental Spamassassin updates), and with good results until now. However that system without the Bayes check handled the recent increase in spam volumes with less success than other systems that do have Bayes checks enabled. > Don't focus solely on a bullet-proof highly > available clustered or replicated database. If the Bayes database is > gone, only one check is gone! All the others are still there. That's a very good suggestion, since it seems like a bit of an overkill to have additional database server machines for this simple task. Is it even necessary to have a consistent shared storage amongst "equal" MXes or would it be sufficient to let them run independently? > For Bayes, use a central SQL database on one server that is used by all > your MTA's, and keep it simple. Make a disaster recovery concept for the > database machine and for the rebuild of an empty SA Bayes database. This > could be very fast. Don't backup the Bayes token data. You wrote that I don't worry too much about disaster recovery, more about avoiding a single point of failure, ie if one or two machine go/es up in smoke or is/are taken offline for maintenance the remaining machines should continue just as before. -- Matthias
smime.p7s
Description: S/MIME Cryptographic Signature
