Репликация MySQL - размышления
Добавлено: 08 дек 2011, 17:10
1. Вынос базы на DRBD-раздел реплицируемый между машинами. Как показали эксперименты данный вид синхронизации не выдерживает потока 40000 символов в запросе при размере баз более 3 Гб. Т.е. если ваш MySQL-сервер используется только для обслуживания сайта а-ля "Привет всем, меня звать Даррел Великолепный Вася Пупкин, зацените мой крутейший сайт (на DLE, WP или Joomla)", то DRBD с этим справится на "ура", только вот смысл реплицировать базы на заведомо разгруженой машине?
2. Вынос баз на общий сетевой диск с использованием gfs2/ocfs2. Лично мной не опробован, но по словам людей пробовавших GFS2 сильно проседает от использования совместно с БД, ocfs2 в этом отношении конечно получше, но в обоих случаях имеется один нюанс - failover=0!!! Т.е. база одна, а работают с ней 2 сервера! Малейший косячок и Bye Bye DB!
3. Активно проталкиваемое Oracle и сообществом разработчиков решение mysql-cluster. На проверку оказавшееся всего лишь еще одним хранилищем называющимся NDBCluster и кучей утилиток напяленных на обычный сервер MySQL. Гарантируемая разработчиками 100-я целостность данных оказалась реальной при обьеме баз не более 2 Гб. Дальше - лаги, потеря данных! + ко всему использование данного хранилища делает невозможным использование других хранилищ - тех же MyISAM, InnoDB, Aria, XtraDB...
4 Нативная репликация. Данный тип репликации самый простой из всех изложенных и самый наверное надежный. Однако даже это не лишает его огромного багажа недостатков. Реализуется данный вид репликации засчет обмена бинарными логам между узлами. Первый же недостаток - бинарные логи очень много весят, а удалять их крайне не рекомендуется. Разберемся же для начала с вопросом - что такое бинарный лог? Бинарный лог это файл содержащий всею историю модифицирующих запросов в БД (INSERT, UPDATE, DELETE, TRUNCATE, DROP и т.д.). При обмене логами с мастер-узлом подчиненный узел считывая файл лога выполняет те же команды что и мастер, в итоге мы имеем идентичность БД на обоих (или больше) узлах. Репликация может быть как горизонтальной (master/slave, master/multislave) так и мультимастерной (master/master). Т.е. в первом случае обмен данными будет происходить только в одном направлении - изменения сделаные мастер-узлом будут применены на подчиненных узлах, но изменения внесенные на подчиненных серверах никак не отразятся на мастер-узле. В случае использования мультимастер репликации используется более усложненная конструкция - изменения сделаные на любом из узлов тут же отразятся на остальных узлах. Но не стоит радоваться - ничего хорошего это не сулит, ибо несколько мастеров могут захотеть одновременно записать в одну и ту же ячейку разные значения, и запишут, а как узнать кто из них не соврал? Можно конечно обыграть и этот момент, но опять же придется лепить костыли... А это не есть хорошо...
Подводя итог можно с уверенностью сказать что ни одна из методик реплицирования муськи не оправдывает надежд возлагаемых на нее... Так что использование репликации - дело используемое на свой страх и риск!