Comments 15
Всё время мучал вопрос, ответ на который Вы дали только в самом конце :)
«переключение на резервную ноду» -> " Просто в таблице maps меняется значение в поле storage1"
Как то много баз у Вас. Но на это можно взглянуть и со стороны отказоустойчивости. Быть может правильнее было б 2е ноды, с резервированием под Postgresql отдать? Так кончено дороже наверное, но архитектурно, как по мне правильнее. Но могу ошибаться. А вообще если настроить реплики и между Вашми 4мя Postgresql, то так и без 2х дополнительных нод выйдет наддёжнее. К примеру на SMTP, Postgresql друг друга подхватывают, и на Storage так же. Ну это как вариант, что первое в голову пришло, или я не внимательно прочёл, и у Вас так и есть?
Что касается продолжения статьи, то разумеется пишите. Любопытно.
«переключение на резервную ноду» -> " Просто в таблице maps меняется значение в поле storage1"
Как то много баз у Вас. Но на это можно взглянуть и со стороны отказоустойчивости. Быть может правильнее было б 2е ноды, с резервированием под Postgresql отдать? Так кончено дороже наверное, но архитектурно, как по мне правильнее. Но могу ошибаться. А вообще если настроить реплики и между Вашми 4мя Postgresql, то так и без 2х дополнительных нод выйдет наддёжнее. К примеру на SMTP, Postgresql друг друга подхватывают, и на Storage так же. Ну это как вариант, что первое в голову пришло, или я не внимательно прочёл, и у Вас так и есть?
Что касается продолжения статьи, то разумеется пишите. Любопытно.
Бд на SMTP нодах нужны для того чтобы определить «свои» домены и отсеивать письма на несуществующие ящики. Можно конечно было бы подключаться к БД стораджей и от туда брать нужную информацию, но я подумал, что будет в случае если оба стораджа будут не доступны? в моем случае вся входящая почта будет скапливаться на SMTP нодах. Решил что так нормально. Синхронизации БД нет. Для себя решил что это излишнее, тк все манипуляции с добавлением, удалением, модификацией ящиков и доменов осуществляется с сервиса управления, который непосредственно подключается ко всем БД и модифицирует каждую из них. Мне показалось это достаточно.
С dsync такие же проблемы возникли после 2.2.16 версии.
Используем его только в качестве hot backup, вторая нода не принимает юзеров. После 2.2.16 начались дубли писем. Опытным путем выяснили, что происходит это, когда на клиенте настроены фильтра, переносящие письма из Инбокса в другие папки. Если они успевают отработать достаточно быстро, то возникают дубли при репликации.
Решили это отключением синхронизации со вторичной ноды на первичную (ранее было active-active).
Полного решения проблемы не нашли :(
Про дедупликацию очень интересно, пишите.
Используем его только в качестве hot backup, вторая нода не принимает юзеров. После 2.2.16 начались дубли писем. Опытным путем выяснили, что происходит это, когда на клиенте настроены фильтра, переносящие письма из Инбокса в другие папки. Если они успевают отработать достаточно быстро, то возникают дубли при репликации.
Решили это отключением синхронизации со вторичной ноды на первичную (ранее было active-active).
Полного решения проблемы не нашли :(
Про дедупликацию очень интересно, пишите.
Интерес есть, да ещё какой!
Именно сейчас, готовимся к подобному действу.
Пишите продолжение! Мы обойдем ваши грабли и будем искать только свои))
Именно сейчас, готовимся к подобному действу.
Пишите продолжение! Мы обойдем ваши грабли и будем искать только свои))
Вместо
dsync— lsyncd не пробовали для синхронизации стораджей?
Интересная штука, не знал о таком, нужно попробовать! Спасибо за наводку
посмотрите еще на
http://isync.sourceforge.net
На 1ТБ писем rsync будет работать минут 15, проверено.
Так же просьба уточнить насчет pop3, он корректно отрабатывает у клиентов при переключении на резервный сервер?
pop3 клиентов ничтожное количество. А что с ними может быть не так? они же не держат сессию, подключаются периодически, забирают что есть и отключаются. Но могу специально попробовать, скажите только что воспроизводить, переключение в момент закачки клиентом большого письма?
Пришлось однажды восстановить почту dovecot 1.2 из бекапа. Бекап делался rsync и восстанавливался тоже через rsync. После восстановления клиенты, которые настроены на pop3, заново приняли все письма (стоял срок хранения писем на сервере 30 дней). То есть интересна ситуация: клиент1 получал почту с сервера1, потом сервер1 отключили и клиент1 стал получать почту с сервера2.
Чтобы полностью забить канал между нодами в 100мб/с приходится запускать rsync в несколько потоков. Вообще к нему вопросов никаких нет, отрабатывает всегда четко! Единственный минус, о чем писал в заметке, это окно между выполнениями.
Я сейчас что-то подобное реализуются, только PROXY у меня совмещен с web клиентом, и данные по пользователям беру из базы web клиента, это требует первого входа на новый адрес через web, но это и так требуется, что бы пользователь сменил одноразовый пароль и получить повареную книгу компании. Ваша схема интересная, спасибо, с удовольствием почитаю продолжения.
Sign up to leave a comment.
Почтовый кластер своими руками