Я хотел купить 2 выделенных сервера и иметь один для хранения базы данных mysql, а другой для запуска веб-приложения, я не уверен, что это хорошая идея.
p.s. с точки зрения доступа к данным я собирался выполнить репликацию базы данных, имея подчиненную базу данных на веб-сервере, а главную, очевидно, на сервере mysql !!
Спасибо
Нет, это глупая идея. Это заставит ваше приложение работать медленнее и менее надежно, чем альтернатива ....
Настройте обе машины как веб-сервер и сервер базы данных. Один как мастер mysql, другой как подчиненный. Добавление циклического DNS. Если хотите, вы можете взвесить адрес веб-сайта на машине, на которой находится ведомое устройство, чтобы направить туда больше трафика.
Для полностью прозрачного подхода к отработке отказа подход «мастер-мастер» может быть лучше - вы все равно можете реализовать привязку обновлений для одного узла и привязку веб-запросов для другого, если действительно хотите.
Это позволяет вам:
Разделение функций на 2 узла означает, что теперь у вас есть 2 единые точки отказа. Если вы смоделируете вероятность отказа для двух подходов, скажем, с вероятностью отказа 0,001, то при использовании эквивалентных узлов вероятность отказа, приводящего к недоступности системы, составит 0,001 x 0,001. OTOH, для многоуровневого подхода вероятность отказа, приводящего к недоступности системы, составляет 0,001 + 0,001
Необходимость проходить через сеть каждый раз, когда вам нужно читать из базы данных (для большинства приложений чтения из базы данных намного чаще, чем записи) обычно как минимум в 10 раз медленнее, чем доступ к локальной службе.
В общем, да, разделение вашей БД и веб-серверов - хорошая идея. Вам не нужно иметь еще один сервер БД на веб-сервере, просто пусть ваше приложение напрямую подключается к серверу БД.
p.s. с точки зрения доступа к данным я собирался выполнить репликацию базы данных, имея подчиненную базу данных на веб-сервере, а главную, очевидно, на сервере mysql !!
Я не думаю, что репликация на веб-сервер имеет большое преимущество в производительности, но она действительно устанавливает хорошую недавнюю копию базы данных, которая является преимуществом для безопасности данных, но никоим образом не заменяет резервные копии, и это до тех пор, пока дополнительная нагрузка не будет ' t снижают производительность веб-приложения.
Если вы используете репликацию, убедитесь, что веб-приложение уже может использоваться с репликацией MySQL (или предназначено для нее). Ключевой проблемой является то, как репликация в конечном итоге является согласованной, что означает, что ведомое устройство потенциально может на некоторое время отставать от ведущего, поэтому его не следует рассматривать как источник достоверных данных.
В общем, это хорошая идея. Репликация вашей базы данных на другом компьютере должна увеличить общее время безотказной работы, но обычно только в том случае, если они находятся в разных центрах обработки данных. Большую часть времени, когда один из моих сайтов был недоступен, был сбой центра обработки данных (сбой питания и резервного питания, потеря соединения для передачи данных, выключение коммутатора ...), только несколько внеплановых простоев были на машинах или моей учетной записи. Но это, скорее всего, снизит производительность ...
С точки зрения безопасности, разделение базы данных и веб-сервера на разные машины в разных центрах обработки данных с резервной копией данных с других машин должно быть хорошим.
С точки зрения производительности, можно разделить приложение и базу данных на разные машины в одном центре обработки данных, но тогда вам не понадобится репликация. Обычной резервной копии должно быть достаточно, запуск подчиненного устройства на сервере приложений в конечном итоге снизит вашу общую производительность. Если вы запустите эту настройку, вы, вероятно, сможете сэкономить дополнительный сервер. В зависимости от ваших текущих запросов к базе данных вы можете позже добавить дополнительный сервер приложений без добавления другого сервера базы данных. Тогда вариант с горячим резервом через подчиненное устройство MySQL может быть вариантом.