? Editing: Post:21.body Save Delete Cancel
Content changed Sign & Publish new content

Блог Balancer'а

Yet another Balancer's blog

Follow in NewsfeedFollowing

Latest comments:

Add new post

Title

21 hours ago · 2 min read ·
3 comments
Body
Read more

Not found

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

on Jan 27, 2017 · 2 min read

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

Раньше я думал много о полной копии (например, 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-репликацию. Вот это было бы отлично. Но это ещё предстоит делать :)

7 Comments:

user_name1 day ago
Reply
Body
dmion Feb 15, 2017
Reply

voland: а эта штуковина может PostgreSQL?

Ей все равно. Она уровнем ниже работает, как дисковый драйвер. А в связке с Xen, или в дистре SCI - это пара серверов виртуальных машин, под каждую виртуалку выделяется диск на одном узле и на другом и они всегда в синке.
Запускается виртуалка на одном, и, если на нем что-то сломалось - просто запускается на другом. Эффект - как будто сервер упал и его перезагрузили: диск, даже удаленный находится в полностью консистентном состоянии.

Если диски потеряли синк, то после того, как они его восстановят, будет передача только накопленной разности, потому что там внутри битовая карта измененных блоков записывается.

volandon Feb 15, 2017
Reply

dmi:

DRBD. Синхронная репликация. Любая БД ее нормально переносит и не разваливается. Плюс бит-карта для нагона. Работает как часы - мы на этой штуке https://sci.skycover.ru/projects/sci-cd/ не только MySQL, но и Оракл гоняем :) Но в пределах ДЦ или серверной.

а эта штуковина может PostgreSQL?

dmion Feb 15, 2017
Reply

Если случай совсем общий, но гвоздями прибита реляционка, то репликация БД, плюс готовность к перенакату дампа. Чудес-то не бывает.

С синком файлов - вешай демона на событие записи в fs, который будет журналировать изменение файлов и второго, который будет по этому журналу по возможности синкать.
Возможно даже чегоньть такое уже есть без рукоделия, но я не интересовался плотно.
Ночью профилатический проход либо rsync либо Unison.

Ну а про мастер-мастер - забыть, это все томление духа :) Там где от него реально что-то зависит, уже можно нормальные деньги вложить в нормальные технологии и не городить костыли.

А если брать совсем-совсем общий случай, то надо признать суровую действительность:
моно-сайты не распределяются.
Самый дешевый по трудозатратам способ поднять их надежность - это реплицируемый сторадж. Вариантов масса, начиная от канонического Амазона, продолжая аппаратными полками с репликацией и заканчивая Xen+DRBD (ссылка н готовый дистр ниже).

Либо отбрасывать исторически сложившийся код и сразу строить по принципам распределенной архитектуры.
Тогда это, опять же, или Амазон, который дает и надежный сторадж и неубиваемую СУБД и шины данных и чего хочешь. Или это микросервисы, которые можно консолидировать из виртуалок с разных частей света и которые умирая не останавливают всю систему, и любые прочие костыли, но предусмотренные изначальным техническим дизайном.

PS.

только там серваки надо брать железные и в одном ДЦ, типа хецнера
Вот. А речь идёт не только о свободной георепликации но и о выпадении узлов на произвольное время с последующим нагоном разницы. А приличные распределённые ФС очень плохо переносят даже георепликацию, не говоря уже о рассинхронизации :)

DRBD. Синхронная репликация. Любая БД ее нормально переносит и не разваливается. Плюс бит-карта для нагона. Работает как часы - мы на этой штуке https://sci.skycover.ru/projects/sci-cd/ не только MySQL, но и Оракл гоняем :) Но в пределах ДЦ или серверной.

balancer73on Feb 14, 2017
Reply

dmi: Вроде как в посте про частный случай речь идет, а сейчас универсальное решение обсуждать начали.

Общая задача на примере частного случая :) И, да, если частный случай рассматривать, то Postgres сразу отпадает, т.к. legacy-части системы к MySQL прибиты гвоздями :) Да и новые части, что с PDO, во многом требуют значительного перепахивания.

dmion Feb 14, 2017
Reply

Тогда опиши подробнее задачу.
Вроде как в посте про частный случай речь идет, а сейчас универсальное решение обсуждать начали.

balancer73on Feb 14, 2017
Reply

dmi: Так а чем не устраивает постгресовая репликация?

  • Postgres поддерживается существенно меньшим числом движков, чем MySQL
  • Postgres, насколько я в курсе, в плане сложных репликаций по-прежнему хуже MySQL
  • Postrges (как и MySQL) — пример классического централизованного сервиса для синхронизации которого с репликами требуется активное взаимодействие обеих сторон.

А остальное рсинком.

Он тут вообще плох. По той же причине централизованного взаимодействия.

только там серваки надо брать железные и в одном ДЦ, типа хецнера

Вот. А речь идёт не только о свободной георепликации но и о выпадении узлов на произвольное время с последующим нагоном разницы. А приличные распределённые ФС очень плохо переносят даже георепликацию, не говоря уже о рассинхронизации :)

dmion Feb 14, 2017
Reply

Так а чем не устраивает постгресовая репликация?
А остальное рсинком.
Решает 98% проблем.

Остальные 2% готовности решает Xen+DRBD, только там серваки надо брать железные и в одном ДЦ, типа хецнера. Но это и для задач более других.

This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More