У меня есть одна центральная база данных со всеми данными в MySQL 5.1-lastest-stable. Я хочу объединить несколько клиентов в отношения мастер-мастер.
Вопрос
Как мне настроить звездообразную топологию с 1 центральным сервером посередине с несколькими клиентскими базами данных, чтобы изменения в одном клиенте распространялись первый на центральный сервер, а оттуда во все остальные клиентские базы данных?
Информация о базе данных
Я использую inno-db для всех таблиц и включил двоичный журнал.
Помимо этого, я научился делать мастер-мастер между базами данных.
Все таблицы имеют первичный ключ первичного целочисленного автоинкремента. Если смещение и начало автоинкрементов настроены на разные клиентские базы данных, никогда не возникает конфликтов первичных ключей.
Почему я хочу это
У меня есть клиентское программное обеспечение (не веб-сайт или php), которое подключается к локальной базе данных MySQL на ноутбуке, это необходимо для синхронизации с центральной базой данных, чтобы все люди, использующие программу на своем ноутбуке, видели все другие изменения, которые делают другие люди. .
Я не хочу напрямую подключаться к центральной базе данных, потому что если интернет-соединение между ноутбуком и центральной базой данных разрывается, мое приложение умирает.
В этой настройке приложение продолжает работать, но ноутбук не получает обновлений от других людей, пока не будет восстановлено соединение с центральной базой данных.
Существует конкретная причина, по которой то, что вы предложили, невозможно достичь с помощью MyISAM и InnoDB.
Звездная топология гарантирует, что Хозяин является центром вселенной, а не раб. Репликация MySQL не предназначена для одновременного чтения подчиненного устройства с нескольких мастеров. Он может читать только с одного мастера за раз. В ИЗМЕНИТЬ МАСТЕРА НА команда подключает подчиненное устройство к одному и только одному мастеру.
По книге Понимание внутреннего устройства MySQL, стр. 219 абзац 2 в подзаголовке «Мульти-Мастер» говорит следующее:
MySQL Replication изначально не создавался с учетом поддержки нескольких мастеров. Подчиненное устройство изначально способно воспроизводить только одного ведущего. Можно создать довольно простой патч, позволяющий одному ведомому устройству собирать обновления от нескольких мастеров без разрешения конфликтов. Это было сделано одно время, но по ряду причин не попало в главную ветвь дерева исходных текстов. В какой-то момент планировался более сложный патч, позволяющий разрешить некоторые конфликты, но по ряду причин не попал в разработку. Это может быть реализовано в будущем.
Книга Высокая производительность MySQL: оптимизация, резервное копирование, репликация и многое другое есть поле вверху страницы 364 (Глава 8: Топологии репликации) с заголовком «MySQL не поддерживает репликацию с несколькими мастерами». В рамке есть следующие абзацы:
Мы используем термин многомастерная репликация очень конкретно, чтобы описать подчиненное устройство с более чем одним мастером. Независимо от того, что вам, возможно, сказали, MySQL (в отличие от некоторых других серверов баз данных) в настоящее время не поддерживает конфигурацию, показанную на рис. 8-6. Тем не мение, мы покажем вам некоторые способы эмуляции многомастерной репликации позже в этой главе.
К сожалению, многие люди используют этот термин случайно, чтобы описать любую установку, в которой есть более одного мастера во всей топологии, например топология «дерево», которую мы покажем позже в этой главе. Другие люди используют его для описания того, что мы называем мастером-мастером. репликация, при которой серверы одновременно являются ведущими и ведомыми.
Эти терминологические проблемы вызывают много недоразумений и даже споров, поэтому мы считаем, что с именами лучше соблюдать осторожность. Только представьте, насколько сложно будет общаться, если MySQL добавит поддержку подчиненного устройства с двумя мастерами! Какой термин вы будете использовать для описания этого, если вы не зарезервировали для этой цели «многомастерную репликацию»?
Хотя методы эмуляции, перечисленные на страницах 373-375 в подзаголовке «Эмуляция многомастерной репликации», теоретически возможны (с использованием механизма хранения BLACKHOLE) и были успешно реализованы другими для эмуляции только двух мастеров, они все равно никогда не смогут поддерживать вашу конкретную предложенную топологию .
Я обратился этот вопрос перед. Фактически, ответ, который я там дал, всегда успешно выполняется. Вот почему страховые агенты могут принести ноутбук в дом и собрать страховые данные о человеке, подающем заявление на страхование. В конце концов, продавец подключался к центральному компьютеру, чтобы загрузить новое клиентское приложение. В свою очередь, центральный компьютер может загружать самую свежую информацию актуария, чтобы пропорционально оценить, сколько полис будет стоить заявителю. Он работает в той же самой предпосылке для подключения ноутбука к центральному компьютеру, по одному ноутбуку за раз.
Это невозможно, Mysql поддерживает только круговую репликацию с несколькими мастерами.
Эта статья очень хорошо описывает эту репликацию.
ВАЖНОЕ ОБНОВЛЕНИЕ Я исправился. Хотя теоретически все, что я здесь сказал, является правильным и достоверным, MySQL на самом деле не поддерживает репликацию с несколькими мастерами по причинам, которых я не знаю. Однако другие серверы баз данных поддерживают такую топологию, поэтому, если требуется настоящая звездообразная топология «главный-главный», также потребуется переключение на другой сервер.
Я не согласен с @lg, думаю, это возможно. (Заранее извините, что в этом «ответе» нет конкретики, у меня нет базы данных MySQL передо мной и я никогда не делал этого раньше, но здесь больше, чем уместилось бы в комментарии.)
В MySQL репликации master-master оба сервера берут на себя роль как master, так и slave; аналогично, в циклическом повторении главный-главный и т. д. все серверы снова являются и главными, и подчиненными.
С другой стороны, MySQL полностью способен реплицировать один главный сервер на несколько подчиненных - у нас был этот (главный для 3 подчиненных), настроенный на моей предыдущей работе.
Поскольку мы знаем, что ведущее устройство также может быть ведомым, и мы знаем, что ведущее устройство может иметь несколько ведомых устройств, и мы знаем (по способу работы круговой репликации), что реплицированные операторы могут быть помещены в binlog (для следующего ведомого устройства) ) и что сервер может идентифицировать свои собственные операторы в бинарном журнале на своем собственном главном устройстве (это то, что удерживает «первый» сервер в сценарии циклической репликации от повторной репликации собственных операторов и поддержания их работы в бесконечном цикле), это кажется вполне разумным что вы можете настроить один мастер, обслуживающий несколько подчиненных, который сам является подчиненным для нескольких мастеров (что, опять же, я знаю, возможно, потому что MySQL поддерживает репликацию с несколькими мастерами с целью единого резервного копирования в реальном времени для нескольких серверов ).
Теперь я признаю, что не могу предложить подробностей о том, как это настроить, и я с готовностью признаю, что вы вряд ли получите большую (если таковая будет) поддержку в этой очень неортодоксальной настройке, но вот несколько советов для начала:
Это должно быть легко проверить - вы говорите, что у вас уже есть два настроенных в отношениях мастер-мастер, поэтому теперь настройте третьего в отношениях мастер-мастер с тем из них, которое вы хотите быть центральным «центром», затем посмотрите, работает ли репликация так, как вы хотите (хотя помните шаг 1 - типичный мастер-мастер, я считаю, не помещает реплицированные операторы в binlog).