т.е. на web серверах в качестве сервера БД указывались адреса разных mysql. А как в таком случае отрабатывает транзакция на изменение данных? Она ждет какого-то подтверждения от MySQL Proxy?
«был настроен mysql proxy, который занимался вопросами синхронизации данных на серверах. »
иными словами ВСЕ 5 серверов работали с ОДНИМ сервером БД, который занималася контролем целостности данных на остальных серверах БД? Да, такой вариант рабочий. Единственное ограничение скорости — время отработки транзакции на прокси сервере БД. Но в этом случае приложение должно знать, что читать данные оно должно с одного сервера БД, а писать — через другой. Т.е. изменение в приложение внести нужно.
плохо будет работать Joomla, когда редактор удалит раздел в который пользователь на лругом сервере вносит изменения. При репликации возникнет конфликт.
Зачем нужен такой сервис — я написал. Совершенно реальные примеры, которые могут успешно работать в такой системе.
Я указываю на некорректность некоторых заявлений в тексте с обоснованием, почему так считаю.
«Если сервер недоступен — ну что ж, плохо, не будет работать и морда что привязана к этому серверу. Тут много серверов поможет тем, что будет хоть для части людей сайт работать.» Мы вроде как о внесении изменений говорили. Что будет с изменяемыми данными, когда один из участников репликации недоступен?
При чем здесь «большие сервисы»? У них процедура внесения изменений — отдельный технологический процесс. И они проектировались под работу в распределенной среде.
В данном же примере объявлено, что «Система работает таким образом, что владельцу сайта не нужно изменять работу веб-приложения для работы с распределенной архитектурой.» Это не верно. Система будет прекрасно работать для приложений, ориентированных на подобный способ (контролированное внесение изменений). Либо использовать только часть функционала, например, быстрая отдача статического контента при использовании единой БД (такой вот мини акамай).
Вы рассматриваете только случай кратковременной задержки репликации. А если сервер БД (один из многих) был недоступен, положим, час?
«Проблемы возникнут там где один пользователь может быть обработан несколькими серверами в пределах одной сессии» я честно старался представить себе такую ситуацию. Не смог. Приведите пример.
А вот вариант, когда одни и те же данные могут быть изменены разными пользователями на разных серверах — запросто.
Существуют два подхода к репликации — синхронный и асинхронный. В первом случае транзакция должна отработать на всех участниках. Второй — недопустим в учетных, биллинговы и т.п. системах.
Позвольте, любой сайт, где есть изменяемый каталог (интернет-магазин), форум и т.п. критичен к синхронизации данных. Вам же не понравиться оплатить счет за товар, который был куплен чуть раньше другим пользователем? Такая схема кластера допустимо только для сайтов, где изменения вносятся централизованно, либо не вносятся совсем.
А кто будет разрешать конфликты? При одновременном изменении данных с разных серверов либо нужно жадть обновления на всех серверах БД (как поступить в случае недоступности одного из серверов?), либо допускать возможность, что пользователи разных узлов будут видеть разные данные.
Врядли это возможно. В схеме master-slave изменения могут вноситься только на мастере. Это, кстати, самая большая проблема всех гео решений. В случае, когда WEB приложение допускает внесение изменений, транзакция должна завершится. А в данном случае это возмодно только на мастере. Так что он — узкое место всей системы :(
иными словами ВСЕ 5 серверов работали с ОДНИМ сервером БД, который занималася контролем целостности данных на остальных серверах БД? Да, такой вариант рабочий. Единственное ограничение скорости — время отработки транзакции на прокси сервере БД. Но в этом случае приложение должно знать, что читать данные оно должно с одного сервера БД, а писать — через другой. Т.е. изменение в приложение внести нужно.
Зачем нужен такой сервис — я написал. Совершенно реальные примеры, которые могут успешно работать в такой системе.
Я указываю на некорректность некоторых заявлений в тексте с обоснованием, почему так считаю.
При чем здесь «большие сервисы»? У них процедура внесения изменений — отдельный технологический процесс. И они проектировались под работу в распределенной среде.
В данном же примере объявлено, что «Система работает таким образом, что владельцу сайта не нужно изменять работу веб-приложения для работы с распределенной архитектурой.» Это не верно. Система будет прекрасно работать для приложений, ориентированных на подобный способ (контролированное внесение изменений). Либо использовать только часть функционала, например, быстрая отдача статического контента при использовании единой БД (такой вот мини акамай).
«Проблемы возникнут там где один пользователь может быть обработан несколькими серверами в пределах одной сессии» я честно старался представить себе такую ситуацию. Не смог. Приведите пример.
А вот вариант, когда одни и те же данные могут быть изменены разными пользователями на разных серверах — запросто.
Существуют два подхода к репликации — синхронный и асинхронный. В первом случае транзакция должна отработать на всех участниках. Второй — недопустим в учетных, биллинговы и т.п. системах.