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