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