Qual é o esquema de greylist ideal com múltiplos MX em locais diferentes?

Question

Atualmente, temos dois servidores MX no mesmo rack físico, eles compartilham o mesmo banco de dados greylist e tudo parece funcionar bem. Os dois MX têm prioridades diferentes e estão em dois servidores físicos diferentes, por isso obtemos redundância se um dos dois falhar.

(FYI, o banco de dados está em uma máquina virtual em um cluster de hardware redundante: enquanto o sistema db como um todo é um ponto único de falha, o hardware em que ele é executado não elimina a maioria dos possíveis modos de falha) / p>

Gostaríamos de apresentar um novo (ou um par de) MX em um datacenter diferente, para obter redundância total dos sistemas de email de entrada (nossos servidores DNS já estão distribuídos por diferentes DCs), mas não podemos nos conectar para o mesmo servidor MySQL desde que iria derrotar a redundância em primeiro lugar.

Qual é a maneira correta de implementar greylisting em tal configuração?

Posso apenas permitir que cada local / grupo MX tenha seu próprio db de greylist, ou será que isso representa algum problema ou ineficiência? Existe alguma razão para configurar os MXes no mesmo site com a mesma / diferente prioridade ou isso não importa? (claro que sites diferentes sempre terão prioridades diferentes)

EDIT / CLARIFICATION: as primeiras respostas parecem sugerir a configuração da replicação do MySQL (master / slave ou bidirecional) ou explicar como fazer isso: estar lá, fazer isso. Eu posso colocar uma duplicação bidirecional do MySQL entre data centers se eu precisar / quiser.

Minha pergunta foi focada em se eu preciso replicar / compartilhar o db greylist ou se eu posso fazer sem conhecimento compartilhado entre os diferentes MXes greylisting, não como implementar conhecimento compartilhado.

    

Answer 1

Na pior das hipóteses, se o data center principal ficar off-line após uma tentativa de entrega inicial, o data center secundário assumirá o controle e não terá registro da primeira tentativa de entrega. Ele tratará a tentativa de entrega de acompanhamento como a tentativa inicial de entrega e informará ao servidor de retransmissão para tentar novamente mais tarde.

Como o tempo de atraso geralmente é de apenas 5 minutos, isso significa que o maior atraso possível é de aproximadamente 10 minutos. Entrega inicial em 0 minutos, segunda entrega em um servidor de correio diferente em 5 minutos e, em seguida, a entrega final aceita em 10 minutos.

Dado que períodos de atraso diferentes de 5 minutos são possíveis, o pior caso é na verdade um atraso de dobro de qualquer atraso de entrega normal no caso de falha de um centro de dados.

Se isso for aceitável para você em uma situação de failover do data center, não será necessário compartilhar seu banco de dados cinza. Se não for, a replicação seria o caminho a seguir.

    

Answer 2

Eu estou supondo que a greylist não é ridiculamente grande ou ativa ... por que não a replicação master / slave no banco de dados MySQL para o datacenter remoto?

    

Answer 3

Eu sugiro que você use replicação para sincronizar seu banco de dados mysql entre os dois locais.

Dependendo da estrutura de seus bancos de dados, existem muitas possibilidades, mas uma configuração comum é configurar cada cluster para gerar chaves seriais independentes e fazê-las replicar umas às outras. Por exemplo, em my.cnf:

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

Em caso de travamento, cada cluster mantém um log das transações ainda não replicadas localmente, de modo que, quando o outro lado for exibido, as transações sejam entregues.

Editar: Ok, você precisa sincronizar seus clusters, senão você irá greylist o mesmo endereço IP independentemente em cada um dos seus clusters, o que pode, na prática, multiplicar o greylist time pelo número de clusters que você configurou. A propósito, por que você não define a mesma prioridade de MX para todas as suas entradas MX?