Каморка

Нужна помощь клуба, чегой-то я торможу...
Имеется N DB-серваков.
Хочется следующего:
1.Синхронно писать на все серваки одни и те же данные, типа репликации такой.
2. Надо добавить новый (N+1) не прерывая сервиса, в крайнем случае можно использовать рабочих серваков отключив его от реплицирования.
3. middleware будет писаться мной, так что любые идеи приветствуются.
Или может существуют уже готовые решения, было бы интересно обсудить как там это делается.

search: distributed transaction service...

Про майсиквел не помню наверняка есть в виде отдельного проекта, для постгреса ето Slony-I например.

Как ты собираешься писать промежуточный уровень? Сокеты? XML CORBA? Тебе нужна только репликация или кластер с лоад балансингом?

Если хочешь кинь тз поподробнее завтра пороюсь в своих архивах, я когда то мультиплексер писал, ето тот который запрос распаралеливает по разным базам данным а потом ответы в кучку собирает, уже естсественно не очень хорошо помню но порыться наверняка можно.

Marmot писал(а):Нужна помощь клуба, чегой-то я торможу...
Имеется N DB-серваков.
Хочется следующего:
1.Синхронно писать на все серваки одни и те же данные, типа репликации такой.
2. Надо добавить новый (N+1) не прерывая сервиса, в крайнем случае можно использовать рабочих серваков отключив его от реплицирования.
3. middleware будет писаться мной, так что любые идеи приветствуются.
Или может существуют уже готовые решения, было бы интересно обсудить как там это делается.

тебе на майсиквел? тады ой...

Ну скажи как для мс. мне будет интересно узнать...

Ок, попробую спросить по другому

The middleware для клиента выглядит как write-only DB, к мне приходят INSERTs/UPDATEs/DELETEs а я делаю простейшее мультиплексирование и tranaction management/coordination на N DBs. Если хотя бы на одной возникают проблемы, то вся операция инвалидируется.
Все это уже описано в многих местах и сделать это можно без проблем.

Теперь представим ситуацию: все работает, все хорошо... и вдруг появилась необходимость добавить в кластер на ходу, не прерывая потока INSERTs/UPDATEs/DELETEs еще один сервак.
Вот тут-то у меня затык....
Единственное что приходит в голову это остановить записи на один сервак, и сразу начать писать все записи в лог.
Сдлать копию DB на новый сервак и начать проигрывать лог на обоих серваках. А лог при этом продолжает расти с головы, btw...
А тут уже совсем затык, как переключится с лога на real-time updates ?

У тебя есть дата последнего обновления записи?

aldep писал(а):У тебя есть дата последнего обновления записи?

Неа, под записью я тут имею ввиду SQL statement-ы а так же записи в логе. SQL statement-ы могут быть какие угодно, в то числе работающие с множественными записями в таблицах.

aissp писал(а):search: distributed transaction service...

Про майсиквел не помню наверняка есть в виде отдельного проекта, для постгреса ето Slony-I например.

Как ты собираешься писать промежуточный уровень? Сокеты? XML CORBA? Тебе нужна только репликация или кластер с лоад балансингом?

Если хочешь кинь тз поподробнее завтра пороюсь в своих архивах, я когда то мультиплексер писал, ето тот который запрос распаралеливает по разным базам данным а потом ответы в кучку собирает, уже естсественно не очень хорошо помню но порыться наверняка можно.

У меня во все базы пишется одно и тоже, клиенты читают напрямую из случайной DB.
Общатся будем по сокетам, нах мне всякие там обертки...

Ну ето делается довольно просто. Логика примерно такая, как только ты начинаешь "медленную" репликацию ты заводишь очередь которая копит инсерты апдаты. Как только репликация закончилась, ты заводишь воторую очередь, которая копит запросы на изменения, а первую раскручиваешь, как первая раскрутилась вся, ты меняешь очереди местами теперь раскручивается вторая а первая пополняется новыми. Процесс продолжается до тех пор пока на момент переключения очередей в той которая копит не будет ни одной записи. Так примерно устроено переключение процессов в 2.6 ядре.

Marmot писал(а):

aldep писал(а):У тебя есть дата последнего обновления записи?

Неа, под записью я тут имею ввиду SQL statement-ы а так же записи в логе. SQL statement-ы могут быть какие угодно, в то числе работающие с множественными записями в таблицах.

напиши "монитор". транзакции гони через него. в нем сделай очередб которая в обычной ситуациц "курит". как только пришло вермя бобавить сервак дергаешь свитч -- изменения пошли в очередь... в это время спокойно добавляешь сервак. дергаешь свитч назад... монитор добивает транзакции в базу.

aissp писал(а):Ну ето делается довольно просто. Логика примерно такая, как только ты начинаешь "медленную" репликацию ты заводишь очередь которая копит инсерты апдаты. Как только репликация закончилась, ты заводишь воторую очередь, которая копит запросы на изменения, а первую раскручиваешь, как первая раскрутилась вся, ты меняешь очереди местами теперь раскручивается вторая а первая пополняется новыми. Процесс продолжается до тех пор пока на момент переключения очередей в той которая копит не будет ни одной записи. Так примерно устроено переключение процессов в 2.6 ядре.

Ндаа... похоже что может сработать, проблема в том что очередь надо будет держать на диске, а не в памяти, на случай внезапной смерти...
Хммм, recovery случае краша в момент синхронизации я пожалуй затрахаюсь отлаживать....
Ну да ладно, надо будет посмотреть как оно разложится в коде...

А еще какие идеи у кого есть?

Файл те нужен тока для внезапной смерти, и пишешь ты всегда тока в конец файла никаких практически страниц и навигации - писать в конец читать с начала. А в целом конечно надо нагрузку смотреть - величина базы данных и мошность потока обновлений, а то могет получиться так что никогда не реплицируешь

Ать да забыл сказать - тебе нафиг не надо делать рековери в случае креша, заново повторяешь процесс синхронизации.

папа Карло писал(а): напиши "монитор". транзакции гони через него. в нем сделай очередб которая в обычной ситуациц "курит". как только пришло вермя бобавить сервак дергаешь свитч -- изменения пошли в очередь... в это время спокойно добавляешь сервак. дергаешь свитч назад... монитор добивает транзакции в базу.

Мне надо сначала новый сервак наполнить данными, а откуда их брать в этом случае ?
Не забывай, клиенты хотят видеть свои апдэйты сразу, я не могу откладывать writes на те серваки с которых клиенты читают в момент синхронизации...

aissp писал(а):А в целом конечно надо нагрузку смотреть - величина базы данных и мошность потока обновлений, а то могет получиться так что никогда не реплицируешь

Во во, а нагузка у меня будет не слабая...

Пир-2-пир сеть с монитором синхронизации.