В настоящее время у нас есть два сервера MX в одной физической стойке, они используют одну и ту же базу данных серого списка, и, похоже, все работает хорошо. У двух MX есть разные приоритеты, и они находятся на двух разных физических серверах, поэтому мы получаем избыточность, если один из двух выходит из строя.
(К вашему сведению, база данных находится на виртуальной машине в избыточном аппаратном кластере: в то время как система db в целом является единой точкой отказа, оборудование, на котором она работает, нет, что исключает большинство возможных режимов отказа)
Мы хотели бы представить новый (или пару) MX в другом центре обработки данных, чтобы добиться полной избыточности входящих почтовых систем (наши DNS-серверы уже распределены по разным DC), но мы не можем подключить его к тот же сервер MySQL, поскольку это в первую очередь устранит избыточность.
Как правильно реализовать серые списки в такой настройке?
Могу ли я просто позволить каждой локации / группе MX иметь свою базу данных серого списка, или это вызовет какие-либо проблемы или неэффективность? Есть ли причина настраивать MX на одном сайте с одинаковым / разным приоритетом или это не имеет значения? (конечно, разные сайты всегда будут иметь разные приоритеты)
РЕДАКТИРОВАНИЕ / УТОЧНЕНИЕ: первые ответы, кажется, предлагают настроить репликацию MySQL (либо ведущую / ведомую, либо двустороннюю) или объяснить, как это сделать: был там, сделал это. Я могу организовать двустороннюю репликацию MySQL между центрами обработки данных, если мне нужно / нужно.
Мой вопрос был сосредоточен на если Мне нужно реплицировать / совместно использовать базу данных серого списка, или, если я могу обойтись без обмена знаниями между различными MX серых списков, не как для реализации общих знаний.
В худшем случае ваш основной центр обработки данных отключается после первоначальной попытки доставки, вторичный центр обработки данных берет на себя управление и в нем нет записи о первой попытке доставки. Он будет рассматривать последующую попытку доставки как первую попытку доставки и скажет серверу ретрансляции повторить попытку позже.
Поскольку время задержки часто составляет всего 5 минут, это означает, что максимально возможная задержка составляет около 10 минут. Первоначальная доставка через 0 минут, вторая доставка на другой почтовый сервер через 5 минут, а затем окончательная принятая доставка через 10 минут.
Учитывая, что возможны периоды задержки, отличные от 5 минут, наихудший случай фактически представляет собой задержку, вдвое превышающую обычную задержку доставки в случае отказа центра обработки данных.
Если это приемлемо для вас в ситуации аварийного переключения центра обработки данных, вам не нужно предоставлять общий доступ к базе данных серых списков. Если это не так, то подходящим вариантом будет репликация.
Я предполагаю, что серый список не слишком большой или активный ... почему бы не выполнить репликацию главного / подчиненного сервера в базе данных MySQL в удаленный центр обработки данных?
Я бы посоветовал вам использовать репликацию для синхронизации вашей базы данных mysql между обоими местоположениями.
В зависимости от структуры ваших баз данных существует множество возможностей, но обычно настраивается каждый кластер для создания независимых серийных ключей и их репликации друг друга. Например, в my.cnf:
auto-increment-increment = 5
auto-increment-offset = 1 ( and 2, 3, 4 , 5 on your other clusters )
В случае сбоя каждый кластер хранит локальный журнал еще не реплицированных транзакций, так что, когда другая сторона приходит, транзакции доставляются.
Изменить: Хорошо, вам нужно синхронизировать свои кластеры, иначе вы будете заносить один и тот же IP-адрес в серый список независимо от каждого из ваших кластеров, что на практике может умножить время серого списка на количество настроенных вами кластеров. Кстати, почему бы вам не установить одинаковый приоритет MX для всех записей MX?