What's the ideal greylist scheme with multiple MX in different locations?

Question

We currently have two MX servers in the same physical rack, they are sharing the same greylist database, and everything seems to work well. The two MX have different priorities and they are on two different physical servers, so we get redundancy if one of the two fails.

(FYI, the database is on a virtual machine on a redundant hardware cluster: while the db system as a whole is a Single Point of Failure, the hardware it runs on is not, eliminating most of the possible failure modes)

We'd like to introduce a new (or a pair of) MX in a different datacenter, to achieve full redundancy of the incoming mail systems (our DNS servers are already distributed over different DCs), but we can't connect it to the very same MySQL server since that would defeat the redundancy in the first place.

What is the correct way to implement greylisting in such a setup?

Can I just let every location / MX group have its own greylist db, or will that pose any problem or inefficiency? Is there any reason to configure MXes in the same site with the same/different priority or that doesn't matter? (of course different sites will always have different priorities)

EDIT / CLARIFICATION: first replies seems to suggest to setup MySQL replication (either master/slave or two way) or explain how to do that: been there, done that. I can put up a two way MySQL replication between data centers if I need/want to.

My question was focused on if I need to replicate / share the greylist db or if I can do without shared knowledge between the different greylisting MXes, not how to implement shared knowledge.

Answer 1

The worst-case scenario is if your primary data centre goes offline after an initial delivery attempt, the secondary data centre takes over and it has no record of the first delivery attempt. It will treat the follow up delivery attempt as the initial delivery attempt and will tell the relaying server to try again later.

Since the delay time is often only 5 minutes, this means that the greatest possible delay is about 10 minutes. Initial delivery at 0 minutes, second delivery to a different mail server at 5 minutes and then the final accepted delivery at 10 minutes.

Given that delay periods other than 5 minutes are possible, the worst case is actually a delay of double of whatever the normal delivery delay is in the case when a data centre fails.

If this is acceptable to you in a data centre failover situation then you won't need to share your greylisting database. If it isn't, then replication would be the way to go.

Answer 2

I'm guessing the greylist isn't ludicrously large or active... why not master/slave replication on the MySQL database to the remote datacenter?

Answer 3

I would suggest you use replication to synchronise your mysql database between both location.

Depending on the structure of your databases there are many possibilities, but a common setting is to configure each cluster to generate independent serial keys and make them replicate each other. For example in my.cnf:

auto-increment-increment = 5
auto-increment-offset = 1  ( and 2, 3, 4 , 5 on your other clusters )

In case of crash each cluster keeps a log of the not-yet-replicated-transactions locally so that when the other side comes up the transactions are delivered.

Edit: Ok, you need to synchronise your clusters else you will greylist the same ip address independantly on each of your clusters, which might in practice multiply the greylist time by the number of clusters you setup. By the way, why don't you set the same MX priority to all your MX entries?