Вопрос: Как я могу централизовать данные MySQL между 3 или более географически отдельными серверами?


Чтобы объяснить предысторию вопроса:

У нас есть домашнее PHP-приложение (для запуска онлайн-курсов изучения языка), работающее на сервере Linux и использующее MySQL на локальном хосте для сохранения пользовательских данных (например, результаты проведенных тестов, отметки о выполненной работе, время, проведенное на разных страницах в курсы и т. д.).

Поскольку у нас есть студенты из разных географических мест, в настоящее время у нас есть 3 виртуальных сервера, расположенных поблизости от этих мест (Испания, Великобритания и Гонконг), и пользователи добавляются на ближайший к ним сервер (они получают доступ через разные URL-адреса, например europe.domain.com , uk.domain.com и asia.domain.com). Это работает, но является административным кошмаром, поскольку мы должны помнить, на каком сервере находится определенный пользователь, и пользователи могут подключаться только к одному серверу. Мы хотели бы как-то централизовать информацию, чтобы все пользователи были видны на любом из серверов, и пользователи могли подключиться к любому из трех серверов.

Вопрос в том, какой метод мы должны использовать для его реализации. Должна быть проблема, с которой столкнулись многие люди, но я не нашел ничего убедительного после честного поиска в Google. Наиболее близкими, которые я видел к решениям, являются:

  • что-то вроде репликации master-master, но я прочитал столько сообщений, что это не очень хорошая идея, так как такие вещи, как поля auto_increment, могут сломаться.

  • круговая репликация, это звучало идеально, но процитировать из высокопроизводительной MySQL O'Reilly: «В общем, кольца хрупки и лучше избегают»,

Мы не против переписывания кода в приложении, чтобы он работал с любым решением, но я не уверен, что репликация - правильная вещь для использования.

Благодаря,

Энди

Постскриптум Я должен добавить, что мы экспериментировали с записью в центральную базу данных, а затем с помощью чтения из локальной базы данных, но время ответа между различными серверами для записи было довольно плохим, и также важно, чтобы письменные данные были доступны сразу для чтения, поэтому, если репликация тоже это может привести к возврату устаревших данных.

Редактировать: Я подумывал о написании собственного рудиментарного сценария репликации, который бы включал в себя что-то вроде того, как каждый пользователь дал идентификатор сервера, чтобы сказать, что является его «домашним сервером», например. пользователи в Азии будут отмечены как имеющие сервер Гонконга в качестве своего собственного сервера. Тогда скрипты репликации (которые будут PHP-скриптом, установленным для работы как задание cron достаточно часто, например каждые 15 минут или около того), будут запускаться независимо на каждом из серверов в системе. Они будут проходить через базу данных и распространять любую информацию о пользователях с «домашним сервером», установленным на сервере, на котором скрипт работает со всеми другими базами данных в системе. Им также потребуется сосать новую информацию, которая была добавлена ​​в любую из других баз данных в системе, где флаг «домашний сервер» является сервером, на котором выполняется скрипт. Мне нужно будет разобраться в деталях и построить логику для решения конфликтов, но я думаю, что это будет возможно, однако я хотел бы убедиться, что нет верный решение для этого уже там, поскольку кажется, что это должна быть проблема, с которой многие сталкиваются.


6
2017-09-14 21:51


Источник


Несколько вопросов: вам нужно писать в базу данных со всех сайтов? Или достаточно реплики только для чтения? Будет ли реплики только для чтения достаточной для 90% случаев? Если вам нужно писать в базы данных, какая задержка приемлема? - Stefan Lasiewski
База данных должна быть записана со всех сайтов, хотя большинство случаев будет осуществляться только с одного сайта. Например, если студент подключается к серверу в Азии, они должны иметь возможность читать и писать в базу данных Азии без каких-либо задержек. Тем не менее, они могут путешествовать из Азии в Европу, и когда за границей, если они подключаются к системе, они будут подключаться к европейскому серверу, что снова им нужно будет иметь возможность читать и писать так без задержек. Однако задержка в репликации информации между этими серверами была бы приемлемой. См. Редактирование моего сообщения для одной моей идеи. - Andy Castles
Я планирую ответить на ваш вопрос, но хочу уделить ему должное внимание. На этой неделе я необычайно занят и еще не нашел эту возможность. На следующей неделе мне нужно было что-то вместе. - Warner
Спасибо, я с нетерпением жду вашего вклада, когда вы получите шанс. - Andy Castles


Ответы:


Циркулярная репликация, которая является просто мастером / мастером / мастером в вашем случае, будет работать. Хотя некоторые утверждают, что это может иногда быть немного «хрупким», так же как и любая установка нескольких серверов. Приятная система мониторинга, которая в любом случае должна быть частью вашего общего пакета, поможет выявить любые проблемы на ранней стадии, чтобы их можно было решить, прежде чем стать серьезной проблемой.

Автоматическая «проблема» настолько легко обойти, что я не могу поверить, что люди все еще поднимают ее как проблему. Просто запустите счетчик на каждом сервере с другим номером и используйте шаг, по крайней мере, такой же, как количество серверов, оставляя достаточно места для любых возможных будущих дополнений.


2
2017-09-15 06:03



Я утверждаю, что он хрупкий и пытается избежать его, хотя иногда я его использую. После того как вы перестроили достаточно большие серверы репликации MySQL, вы действительно устали от этого. У вас есть лучший успех лично? - Warner
@Warner, мне никогда не приходилось иметь дело с тем, что я считал бы действительно крупными инсталляциями, но добился отличных успехов с установкой 3-х основных мастеров / мастеров / мастеров с каждым сайтом в другом состоянии и связанными явно ненадежными соединениями. Единственный раз, когда он сломался, я использовал самый быстрый вариант, который для меня должен был стереть сломанную ссылку и воссоздать ее. Разумеется, это не будет жизнеспособным для всех. - John Gardeniers
@Warner, я ценю ваш вклад, поскольку у вас, похоже, много опыта работы с системами высокой доступности. По вашему опыту, что бы вы использовали в качестве альтернативы репликации master / master / master в этой ситуации? Благодарю. - Andy Castles
спасибо за то, что сообщили мне, что вы использовали master / master / master и что его можно заставить работать без особых проблем. Я буду исследовать его дальше, поскольку кажется, что это может быть возможным решением. Я надеюсь, что Уорнер может дать мне некоторое представление о какой-то альтернативе, чтобы я мог сравнить два разных угла и разработать, что было бы лучше. - Andy Castles
Что относительно распределенных файловых систем, таких как GlusterFS? Было бы целесообразно поставить мастера на то, чтобы справиться с репликацией в распределенной файловой системе или это избыточно? - CMCDragonkai


Для вашего приложения это звучит как круговая репликация (из которой мультимастер - это особый случай) не должен быть слишком большой проблемой.

Проблема auto_increment легко разрешается посредством auto_increment_increment а также auto_increment_offset,

Контролировать репликацию на всех событиях с относительно высокой частотой и фиксировать источники всего, что приводит к разрыву репликации или дрейфующим данным. Maatkitmk-table-checksum и mk-table-sync хороши для идентифицирующий дрейфующие данные. Gotta попал в двоичные журналы и код, чтобы идентифицировать источники ... :)


1
2017-11-23 18:08





Мы не против переписывания кода в   приложение, чтобы оно работало с   любое решение требуется, но я   не уверен, что репликация правильная   предмет для использования.

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

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

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


0
2017-09-15 01:06



Спасибо за предложение. Я думал о чем-то подобном, но о автоматической системе, т. Е. Задании cron, которое периодически толкает данные между серверами и делает это для всех пользователей. Причина, по которой я еще не делал этого, это похоже на то, что я просто повторно изобретаю репликацию, и я уверен, что MySQL мог бы сделать это гораздо эффективнее, чем я мог бы ожидать при работе с PHP-скриптом cron. Похоже, что это была общая проблема, которую я хотел выяснить, есть ли «правильный» способ решить проблему до того, как я придумаю свое решение. - Andy Castles


Я также использовал модель кольца репликации и имел как успехи, так и проблемы из-за хрупких аспектов. Самая большая проблема с кольцом заключается в том, что потеря одного сервера остановит все данные.

Если у вас есть мониторинг в реальном времени, вы можете сохранить кольцо живым с помощью CHANGE MASTER TO (сначала вам нужно остановить подчиненный). Это позволяет вам переключаться с master-master-master на master-master и обратно на лету. Это поможет только в сочетании с активным механизмом переключения при сбое, который запускает и направляет пользователей на активный сайт вместо «локального» (который в настоящее время не работает).

У меня было только два сайта, и у меня было два сервера на каждом сайте (вместо вашей модели с одним сервером на сайт). Потенциальным решением в нашем случае было создание кластера NDB MySQL на каждом сайте, который поддерживал экземпляры MySQL на каждом узле, и установил кольцо репликации среди экземпляров MySQL. Это означало бы, что потеря сайта (или связи между сайтами) не потребует каких-либо аварийных изменений, и все будет излечиваться после восстановления сайта с ошибкой.


0
2017-10-03 01:44





Если вы захотите перепроектировать свой уровень доступа к данным и модель данных, и вы захотите хранить данные где-то помимо ваших серверов, вы можете попробовать распределенную службу БД, такую ​​как http://aws.amazon.com/simpledb/


0
2017-10-27 17:48



Спасибо за предложение. У меня нет опыта работы с распределенными службами БД, как это, но я не уверен, сколько работы связано с его внедрением. Однако на данный момент уровень доступа к данным приложений не слишком четко определен, поэтому я уверен, что было бы очень большой работой, адаптировав его для работы с этим, поэтому даже попробовать это было бы невозможно в настоящий момент. Еще раз спасибо за предложение. - Andy Castles


Давайте рассмотрим простой сценарий, где все серверы баз данных (Server 1, Server2 и server3) географически расположены на разных сайтах, связанных через VPN или в какой-либо другой сети, которые могут иметь сбои в ссылках. Мы планируем, что каждые 10 минут мастер изменяется.

Чтобы это было возможно, мы должны остановить подчиненное устройство и изменить мастер на новый сервер. В принципе, это циклическое циклическое вращение вращения для IP-адресов мастеров в каждой базе данных, но не забудьте остановить ведомый, изменить мастер, а затем запустить ведомый.

Скрипт псевдокода для каждого сервера выглядит следующим образом:

Сервер 1

Скрипт 1 выполняется в течение 10 минут, затем цепочка к сценарию 2:

  • Остановить ведомый
  • Изменить мастер на сервер 2
  • Запустить ведомый

Скрипт 2 выполняется в течение 10 минут, затем цепочка к сценарию 1:

  • Остановить ведомый
  • Измените имя мастера на сервер 3
  • Запустить ведомый

Сервер 2

Скрипт 1 выполняется в течение 10 минут, затем цепочка к сценарию 2:

  • Остановить ведомый
  • Измените имя мастера на сервер 3
  • Запустить ведомый

Скрипт 2 выполняется в течение 10 минут, затем цепочка к сценарию 1:

  • Остановить ведомый
  • Измените имя мастера на сервер 1
  • Запустить ведомый

Сервер 3

Скрипт 1 выполняется в течение 10 минут, затем цепочка к сценарию 2:

  • Остановить ведомый
  • Измените имя мастера на сервер 1
  • Запустить ведомый

Скрипт 2 выполняется в течение 10 минут, затем цепочка к сценарию 1:

  • Остановить ведомый
  • Изменить мастер на сервер 2
  • Запустить ведомый

Это похоже на запланированную синхронизацию между мастерами.

Любые комментарии наиболее приветствуются.


0
2018-05-05 12:52