Использование центрального сервера базы данных для многих сайтов: правдоподобно?

Question

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

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

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

• При каждой загрузке страницы должно быть установлено несколько соединений с базой данных.
• Задержка сигнала, проходящего между двумя физическими точками.

Правильно ли я беспокоиться? Было бы разумнее синхронизировать базы данных с cronjobs или другими технологиями?

---

Наряду с назначением награды я добавляю к вопросу, надеясь, что эксперт с реальным опытом этого придет:

Какие есть еще технологии (кроме cron) для синхронизации баз данных MySql?

Answer 1

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

Некоторые вещи, которые следует учитывать при работе с репликацией

• Требуется как минимум 2 (предпочтительно 3 или более, 1 главный и 2 подчиненных) сервера баз данных.
• Вы никогда не будете писать на подчиненные серверы.Все операции записи передаются ведущему устройству, и репликация будет синхронизировать ведомые вскоре после этого.
• Вы всегда читаете с подчиненных серверов (если только вы не хотите гарантировать, что у вас самые свежие данные).Разделив операции чтения и записи между серверами, вы можете значительно повысить производительность.

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

Answer 2

Этот вопрос действительно относится к вашей ситуации, и я полагаю, что вы определили две основные проблемы с решением для центральной БД - так что да, вы правы, если вы обеспокоены. выберите синхронизацию данных с серверами, используя cron (или любой другой метод, который вы выбрали), что позволит сократить расходы на оборудование и время загрузки страниц.Для меня это более техническое решение, но с точки зрения его преимуществ (более быстрое время загрузки страницы, отсутствие зависимости от центральной БД, более низкие затраты) - правильное решение.

В качестве альтернативы, вы всегда можете настроить небольшоеБаза данных MySQL на удаленном сервере, создайте несколько тестовых веб-сайтов и запустите несколько тестов, это даст вам некоторые данные о том, довольны ли вы временем загрузки.

Answer 3

Мой быстрый ответ на это будет использовать систему очереди заданий, такую ​​как Gearman , чтобы также разгрузить синхронизацию. Таким образом, это не влияет на загрузку страницы или пользовательский опыт. Вы просто создаете задание Gearman, и оно отправляет задание в очередь Gearman и добирается до него, как только может.

Это также кажется намного лучшим, мгновенным решением для использования cron. Потому что это мгновенно добавит задание в очередь и обработает его практически мгновенно. И поскольку вы, похоже, хотите реплицировать только выбранные данные, я не понимаю, как MySQL Replication будет вам очень полезна.

Я работал с Gearman раньше (даже с PHP), и это было отличное решение для разрыва работы, которую нужно завершить, когда загрузке страницы не нужно было ждать завершения этой работы.

Хотя это может быть и не так просто, как мне показалось, поскольку вам нужно настроить и изучить Gearman, но это очень удобный инструмент.

Надеюсь, это поможет!

Answer 4

любой метод, который предлагает автономную синхронизацию, тратит впустую преимущества репликации mysql

(учитывая неясную ситуацию, которую вы упомянули)
ваше решение может быть столь же простым, как и сохранить READ /ЗАПИШИТЕ отдельно

, что означает для локальной базы данных,

1. убедитесь, что локальное чтение доступно только для базы данных, которую вы хотите синхронизировать из централизованной базы данных
2. операция записиэто фиксация в централизованной базе данных (вместо локальной базы данных)
3. централизация базы данных будет реплицировать обновление на все локальные базы данных

проблема

1. задержка репликации из-за задержки в сети

преимущества

1. целостность данных, поскольку операция записи может выполняться только централизованным сервером и с использованием репликации вкопировать изменения в различные локальные базы данных
2. локальная база данных позволяет разрешить отдельную операцию записи (другой набор данных / база данных)
3. чтение из локальных данныхabase намного быстрее, чем централизованная база данных (рассмотрим операцию чтения чаще, чем операцию записи)

Answer 5

Во-первых, предупреждение, что вы пытаетесь сделать, это не легко; В то время как MySQL поддерживает репликацию master / slave, и у вас может быть несколько master и slave, работающих на всех уровнях уровней, вам нужно подумать о том, «как я могу восстановиться после сбоя сервера базы данных» - вы продвигаете slave? как насчет согласованности (так как гарантируется, что репликация между подчиненными не удалась)? и т. д. Также необходимо учитывать изменения схемы; все хорошо, если у вас одна и та же схема на всех серверах, но как только вам нужно отправить обновление кода, требующее одновременного изменения базы данных, вы не можете полагаться на это изменение схемы, опубликованное в репликациях.

Хорошо, предупреждаю, так как ты это делаешь? Самый простой способ - запустить последнюю версию PhpMyAdmin, которая позволяет очень быстро и легко настроить репликацию. Прежде чем сделать это, убедитесь, что у вас включена двоичная регистрация на всех серверах MySql, так как это поможет вам избежать аварийного восстановления; http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

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

Если вам нужно определить местоположение, чтобы все они не могли быть сохранены в одном хранилище данных, то все становится немного сложнее; Теперь у вас есть время ожидания, чтобы бороться с. В этой ситуации, поскольку Интернет не является мгновенным, запись, сделанная ведущему, займет время, чтобы распространиться на подчиненное устройство. Поэтому любой запрос на выборку, выполненный очень скоро после записи, вероятно, не вернет новые данные, поскольку он еще не был реплицирован на ведомый. Это называется «возможной согласованностью», и ее относительно легко преодолеть, если принять во внимание, что это произойдет, и код ожидать, то есть никогда не предполагать, что данные присутствуют.

Я не могу ответить на ваш вопрос с какой-либо реальной справедливостью на этом сайте. Лучше всего прочитать книгу, я настоятельно рекомендую эту;

Высокая доступность MySQL - ISBN-13: 978-0-596-80730-6

Answer 6

То, как Google решил эту проблему (вы получаете некоторую информацию здесь . Извините, у меня нет ссылки на реальную опубликованную статью, описывающую ее), более или менее в серии триггеров.

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

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

Это может быть немного много для ваших нужд, но именно так Google это делает.

Answer 7

Я сделал некоторую синхронизацию базы данных между приложением php клиент-сервер и использовал следующую идею http://vitana -group.com / article / php / data-synchronization

Answer 8

Мне было интересно, используете ли вы SQL Server в качестве вашего сервера или что-то еще.Я почти уверен, что с SQL вы можете использовать SQL Replication http://technet.microsoft.com/en-us/library/ms151198.aspx для достижения желаемой цели.В этот момент ваши локальные приложения получат доступ к своему собственному экземпляру SQL, в то время как каждый экземпляр sql будет «реплицировать» и «синхронизировать» свои данные с основным сервером БД.Конечным результатом является то, что ваша центральная БД всегда будет в курсе и будет содержать агрегированные данные от каждого спутникового SQL-сервера.(Хотя, пожалуйста, не цитируйте меня по этому вопросу ... Я не эксперт по SQL.)

(Извините, я только что понял, что вы используете PHP / MySQL ... и, вероятно, предпочитаете открытый код ..Тем не менее, я думаю, что это стоит посмотреть.)