Кластеры SQL серверов
или
"сферический слон в вакууме" [1]
……………………
Откуда что пошло.
Есть HP двухпроцессорный сервер, стоит 10 тыс. долларов. Так его не
проапгрейдишь, не изменишь производительность. За эти деньги можно купить
примерно 20 блейд серверов, из которых можно организовать кластер. При этом мы
получаем масштабируемость, апгрейд.

Собственно вопрос.
Почему широко не используют кластеры SQL серверов? Что это такое? (то есть
чистое любопытство. Далее что удалось выяснить для себя.

Что точно работает.
Работает формула «read one, write all». При этом имеем масштабируемость при
чтении (скорость обработки пишущих транзакций линейно растет с числом серверов в
кластере N) и отсутствие масштабируемости при пишущих транзакциях.

Хочется масштабируемости при пишущих транзакциях.
Предлагается простой (и кажется единственный) способ - превратить пишущую
транзакцию в «читающую» (фокус): пишущая транзакция пишет необходимые данные в
некий буфер (копия тех страниц данных, которые необходимо изменить), и не
изменяет базу данных (см.рис.). При этом для базы данных нет разницы – пишущая
или читающая транзакция – работает формула «read one». На основе буфера делаем
скрипт репликации, который отсылаем на центральный узел кластера – Application
server, который последовательно (один скрипт за другим) отсылает (после
соответствующей отбраковки – удалении некоторых скриптов для сохранения
ссылочной целостности) параллельно всем серверам скрипты репликации. При этом,
если репликация проходит значительно быстрее самой транзакции, мы и получим
требуемую масштабируемость.

Свойства полученного кластера.
1) Пишущие транзакции физически крутятся на разных серверах, поэтому не могут
блокировать друг друга во время исполнения.
2) В результате, транзакция может завершится успешно (на одном из серверов), но
при репликации может привести к нарушению ссылочной целостности – такие
транзакции будут удалены на Application server при проверке.
3) Проверки на Application server будут проходить на весьма малом объеме данных:
пусть пишущая транзакция стартовала на состоянии сервера ID1, завершилась, когда
уже сервер(а) дошли до состояния ID2, так вот проверки необходимо провести на
объеме данных (ID2- ID1).

Собственно и все.
……………………
[1] "сферический слон в вакууме" – так назвали тему в конфе. Это характеризует,
во первых, тему – отвлеченную от конкретных реализаций SQL серверов, от
конкретной практики. Во вторых – это характеризует отношение читателей конфы к
теме. Было два типа отношений: (1) – «мы вообще то работаем» - то есть не до
этого, бег по кругу отнимает много сил, (2) – «почитай, что пишут на эту тему
оракл, мелкомягкие, и т.д.» - то есть не по Сеньке шапка. Так что с жанром мы
разобрались - литературно-художественный.

Чуть промахнулся форумом (хотел просто в "программирование")- а удалить немогу.

У oracle 9i, 10g - своя простая система кластера - база данных (файл базы) общая для всех и нет проблемы репликации (Кластерное решение компании Oracle, получившее название "Real Application Cluster (RAC) ).

ПользовательКластеры SQL серверов
или
"сферический слон в вакууме"
________________
Рассмотрим простейший пример реализации идеи кластеров SQL-серверов с использованием общедоступных SQL серверов и сервера приложений.

Рассматриваем только пишущие транзакции. Потребуется три стадии:

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

Соответственно, по аналогии, назовем это трехфазной репликацией. Собственно интересно получить ответ на вопрос: «Будет ли толк от подобного кластера SQL серверов?»
_______________________
(*) – скрипт репликации готовим с помощью триггеров на запись\модификацию, и скрипт является последовательностью самых простых SQL команд записи\модификации данных, которая (последовательность) заменяет собой пишущую транзакцию, и служит для ускорения записи пишущей транзакции на все SQL сервера.