Реплицирование и зеркалирование классических систем

 
+
-
edit
 

Balancer

администратор
★★★★★
Не то, чтобы это P2P. И даже не Infonesy. Но всё равно где-то в этот форум...

Для повышения отказоустойчивости и сохранности данных как форумов Авиабазы, так и прочих проектов (включая, кстати, и АвиаПорт) в очередной раз прихожу к мысли, что нужно иметь вторичные резервные полностью рабочие копии сайтов. Речь не о бэкапах, а именно о полной системе, готовой к работе в любой момент.

Раньше я думал много о полной копии (например, rsync для полностью автономного LXC-контейнера), но с этим вариантом всё так и не срослось. Он плохо работает, когда объём БД измеряется десятками гигабайт, а объём файлов — сотнями.

Сложно также поддерживать живую консистентность БД. Да, в том же MySQL отлично работает master-master репликация баз и я даже этим активно пользовался, но... Как только начинаются проблемы с репликацией, потом замучаешься это всё восстанавливать. Время от времени дело доходит до очередного mysqdump/mysql, что выливается, порой, в часы восстановления... Печально. Ещё хуже дело обстоит с разнородными БД на одном сервере.

Проще с файлами. Их можно гонять с машины на машину по rsync. Можно синхронизировать изменения через lsync или btsync/syncthing. Есть небольшие задержки, но чаще это не критично. Проблема тут в том, что p2p-синхронизация тяжело работает на сотнях гигабайт. А централизованная требует каждый раз ручного конфигурирования и жёстко привязывается к структуре проектов.

Интересно тут попробовать IPFS, но руки пока не дошли до массовой практики. Хотя у IPFS есть серьёзный недостаток — невозможность работать с её файлами локально. Они хранятся в собственном формате. В качестве же бонуса — прозрачная работа при смене реплики или при удалённом добавлении файла на другом сервере. Локально он будет гарантированно доступен при обращении, хотя и с задержкой.

С базами же данных я до конца вопрос не решил. Хочу попробовать идею, реализованную в Infonesy. При появлении новых данных или обновлении старых на одном сервере, он сбрасывает JSON-объект в файл в каталог синхронизации. Реплицирующие машины забирают файл и загружают в свои БД. Автоматически решается вопрос структуры сети, так как работа идёт через честный p2p. Проблема конфликта идентификаторов (которой нет в Infonesy — там другой принцип) не возникает при использовании mysql autoincrement offset, как при master-master. Практику тормозит мелочь — надо дорабатывать свои сайтовые движки. Но тут относительно просто — BORS© имеет централизованную точку сохранения объектов, туда и можно встраиваться.

Т.е. система вырисовывается такая. Например, при появлении ответа на форуме, файлы/аттачи сразу кидаются в IPFS. Объекты постинга, обновлённого топика, форума и всего, что обновилось, кидаются в виде JSON в btsync. На удалённом сервере демон, следящий за btsync-каталогом видит прибытие JSON. Считывает данные и грузит их в БД. Файлы, на которые может ссылаться запись, уже сразу доступны в IPFS. Тонкое место тут только в ссылочной целостности базы. Скажем, в случае нового топика постинг может прийти раньше топика. И тогда в БД не получится topic_id сделать внешним ключём для поста... Придётся не пользоваться ссылочной целостностью :-/

Ну и ещё один момент — развёртывание проектов. Недавно переносил АвиаТоп (для разгрузки, а то он процентов 15 нагрузки давал :D) с сервера Авиабазы на отдельный сервер в DigitalOcean. Теперь думаю переносить на другой сервер, у Scaleway. Постое копирование — это лишняя работа. А я очень ленив :) Поэтому уже при недавнем переносе я постарался максимально пакетизировать проект. Чтобы можно было развернуть по простому composer require .... Но БД пока переносится ещё вручную. Надо и этот вопрос тоже решить. Миграции и утягивание данных по запросу через p2p-репликацию. Вот это было бы отлично. Но это ещё предстоит делать :)
 44

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru