Привет :-)
Я снова нахожусь на охоте за новыми знаниями, я являюсь администратором баз данных на полставки в рамках моей текущей работы, и меня особенно интересует любая документация или чтение, пуленепробиваемый топологии репликации с несколькими мастерами - есть ли у кого-нибудь указатели?
В прошлых ролях я реализовал и поддерживал такие топологии, но всегда есть «ловушки» (auto_increment_increment, auto_increment_offset - два большой те), которые вы замечаете только в последнюю минуту и которые имеют серьезный потенциал испортить вам день.
При большой рабочей нагрузке InnoDB, каковы большие проблемы с репликацией с несколькими мастерами и как вы, как опытный администратор баз данных, решаете их? Как эта картина изменится, если вы храните вещи с помощью MyISAM или других механизмов хранения, теперь они удобны и легко подключаются, возможно, у кого-то есть опыт работы с Infobright или другим хранилищем данных?
Особое внимание следует уделять методам восстановления любого предлагаемого решения. Как администратор баз данных эффективно выполняет резервное копирование этой топологии и насколько прост процесс восстановления? Достаточно ли он пуленепробиваемый, чтобы вы могли вставить балансировщик нагрузки с поддержкой TCP (хеширование исходного IP-адреса или подобное) впереди и иметь нуль время простоя (или чертовски близко к ...) в случае, если мастер MySQL выйдет из строя?
Я прочитал и настоятельно рекомендую High Performance MySQL от Baron Schwartz, однако, что мне действительно нужно, это пара действительно качественных веб-сайтов со всеми затронутыми пунктами и ссылками на более подробные материалы для чтения по мере необходимости. У кого есть такая под рукой? :)
Бонусный домовой указывает на любое решение, которое может иметь «пулы» подчиненных серверов для нечетного приложения, которое имеет особенно трудоемкую рабочую нагрузку на чтение.
Большое спасибо.
Репликация мастер-мастер является асинхронной, поэтому она обязательно сломается, если вы будете писать сразу на оба сервера.
Даже если автоинкременты работают, любой другой уникальный индекс и многие другие ситуации могут сломать его - он слишком хрупкий для использования.
Но можно использовать мастер-мастер как ЧАСТЬ решения высокой доступности, вам просто нужно убедиться, что приложения когда-либо записывают только одну из пары и в «чистой» ситуации аварийного переключения, например После сбоя администратора он ждет, пока подчиненное устройство не догонит его, прежде чем переключиться.
На практике это не очень сложно, но немного неудобно.
Другой ваш основной вариант - использовать DRBD, который также несложно настроить, но в этом случае 2-я машина даже не может использоваться в качестве реплики для чтения - она просто находится там как горячий резерв. DRBD синхронно реплицирует базовое хранилище, поэтому все безопасно записывается на обе машины.
Есть некоторые приложения, специально разработанные для того, чтобы справляться с проблемами с несколькими мастерами - их нужно разрабатывать ОЧЕНЬ тщательно с учетом конкретной ситуации - в этом случае все в порядке. Однако вы не можете использовать приложения, не предназначенные для этого.
автоинкремент - не единственная и не главная проблема.
Очевидно, вы пробовали круговую репликацию, учитывая ваши комментарии об автоинкременте. Это был бы мой предпочтительный вариант; вам просто нужно не забыть правильно настроить MySQL.
Вы могли посмотреть на Sequioa, который работает, сидя перед вашим кластером mysql и занимается выполнением вашего SQL на каждом сервере в случае записи и балансировкой нагрузки в случае чтения. Он имеет ряд других функций, например, возможность использования различных серверных модулей базы данных. Это непросто, с операциями, требующими нескольких шагов, но вы просите его решить сложную проблему, поэтому неудивительно, что решения тоже не простые.