Отказоустойчивые решени, пните в нужном направлении

ну это больше вопрос к требованиям - можно придумать и по своим средствам, например раньше у меня вообще БД дублировалась на пару баз на обычных хостинг-аккаунтах - тогда меня вполне устраивала такая подстраховка и нагрузки были маленькие.

Сейчас продумываю более универсальное решение.

Существует элементарно, просто выбирайте правильных датацентров. Общий хостинг на VPS - 2008 16 / 66776 99.850%.

Нет такой проблемы, просто правильно выбирайте технологию виртуализации ;)

Не надо городить сложные кластеры для бюджетных проектов. Результат будет отрицательный.

otcek, +100000

Описаная Вами схема не является отказоустойчивой. Как Вы правильно обозначили, это подстраховка. Дублирование БД на аккаунты обычных хостингов это backup.

это почему? если у меня клиент-скрипт может обратиться к любой из БД на этих "страховочных" аккаунтах если главная БД упала... конечно если одна база падала, мне приходилось потом вручную ее обновлять до актуального состояния... ну как бы за 15уе вполне нормальное решение, цель достигалась - данные доступны при отказах главной БД

да, при нормальных нагрузках и большой БД так не получится сделать (поэтому просил совета)

Но в таком случае слабым звеном является клиент-скрипт. Это частный случай повышения надежности системы (за счет дублирования элементов системы), но не отказоустойчивая система в полном смысле этих слов.

клиент-скриптов у меня было много (как пример - централизованная база новостей, которые по некоторому алгоритму "раздаются" на разные сайты).

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

если кто даст совет по моему вопросу - буду благодарен

вопрос:

что оптимальнее при отложенном дублировании изменений в резервной БД (грубо говоря в час ночи все изменения с основной БД нужно слить на резервную(ые) )- напихать везде флагов изменения+(возможно) полей с датой или создать отдельные таблицы в которых будут храниться изменения

Пример:

Скрипт работает сразу с 2-мя БД,

Если одна БД падает, а скрипту нужно записать в обе, то скрипт временно создает файл в который сохраняет все запросы не прошедшие к этой БД.

Как только упавшая БД поднимается он проводит все не проведенные транзакции.

Могу подробней пояснить по реализации.

Получается дешево и сердито.

Зачем придумывать велосипеды с скриптами если можно использовать обычную репликацию MySQL?

http://dev.mysql.com/doc/refman/5.0/en/replication.html

Настраивается за максимум час .

При желании можно сделать даже схему master-master когда все изменения будут сохранятся на обоих MySQL серверах, независимо от того на какой сервер определенные данные записались.

Насколько я понимаю , самая большая проблема будет не в актуальности базы данных , а в смене записей в ДНС , пока по всем разойдется пол дня пройдет.