Какой метод зеркалирования MySQL я должен использовать для этого?
Я использую службу хостинга веб-приложений (в основном, бесплатные форумы), и в моем распоряжении два удаленных сервера. Код для приложения хранится на обоих серверах и не является проблемой, но мне интересно, как работать с базами данных.
Когда кто-то заходит на сайт *.example-host.com, он отправляется на один из двух серверов, и оба должны иметь возможность загружать форумы из базы данных. База данных также должна иметь доступ для записи, когда новые участники регистрируются или публикуют темы и т. Д.
Основное требование - скорость, но также важно время безотказной работы (если сервер отключается, сайт все равно должен работать).
У меня есть несколько вариантов, но я неопытный и не уверен, что пойти с:
1) [PHP] Разделить записи форума 50:50 между двумя серверами. Если у сервера нет записи для запрошенного форума, он может запросить ее у другого через удаленный MySQL и загрузить ее. Эта идея звучала хорошо, пока я не понял, что в 50% случаев пользователи будут значительно дольше ждать загрузки страниц. Я также понял, что если один из серверов выйдет из строя, половина форумов будет недоступна, и регистрации придется отключить.
2) [MySQL] Двойная главная репликация. Это попыталось бы отразить две базы данных и звучит идеально, но я слышал, что это может быть очень проблематично. Я не знаю, как быстро это.
3) [MySQL] Используйте стандартную репликацию, распределяйте запросы только для чтения на обоих узлах и запросы на чтение / запись к мастеру. Это звучит как хороший вариант, но опять же, я не уверен в скорости. Я также не знаю, что произойдет, если главный сервер выйдет из строя.
Если у вас есть другие предложения, пожалуйста, напишите их:)
1 ответ
Решение 1 близко к шардингу, но вся архитектура должна быть рассмотрена и разработана для достижения этого наилучшим образом. Шардинг обычно приходит с крупномасштабными установками, расширяющими пределы технологических платформ.
Решение 2 или двойная главная репликация были бы применимы, но поскольку ваши ссылки физически разделены, было бы рискованно, чтобы приложение динамически указывало на любую базу данных. Вы хотели бы выбрать одну базу данных, и если база данных потерпела неудачу, вручную переназначить приложение в новую базу данных. Автоматический переход на другой ресурс приложения создает риск расщепления мозга. Вы можете сделать ночные снимки вторичных баз данных для резервного копирования.
Как описано в решении 3, репликация часто используется для распределения нагрузки только для чтения на разные серверы баз данных. Это также позволяет вам использовать различные механизмы и конфигурации для запросов на чтение. Например, MyISAM может быть быстрее для запросов только для чтения.
Репликация обычно зависит от физических ограничений оборудования, будь то сетевые или системные ресурсы. Если вы не храните двоичные данные в базе данных в большом масштабе, я бы не стал беспокоиться о задержках репликации при нормальной нагрузке.
Поскольку вашим главным требованием является скорость, я бы сначала сосредоточился на конфигурации и ресурсах локальной системы. Скорее всего, там можно сделать существенную оптимизацию.
Автоматические решения высокой доступности, как правило, лучше всего локализованы в одной физической среде, а в случае экстремального сбоя могут быть применены ручные решения для включения физически отдельного сайта.
Я обобщаю на основе стека LAMP и фокусируюсь на веб-приложениях. Различные приложения, протоколы и технологии немного меняются, но в отношении веб-серверов и баз данных то, что я описываю, более применимо.