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

http://www.drbd.org/ решения на его основе http://www.linux-ha.org/

Берете несколько бюджетных серверов и строите распределнную систему.

cdn?

десять cdn?

расшифруйте если не сложно, самое подходящее, что я нашел, content delivery network

cdn - Content Distribution Network так и есть. Работает н апринципе географического кеширования популярного контента т.е. в основном статики. Есть мастер сервер на котором осздается сам сайт с контентом, а в мире куча географических точек на которые разбрасываются наиболее часто запрашивыемый контент, например хтмл сайт, видео или картинка...естественно мастер сайт никогда не умирает, да же если один узел умирает, то все остально остается доступным НО!!!!

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

Уж лутше тогда сделать фронт- бекенд, причем бекенд поставить на 2-а сервера(фактически ваша база данных), а фронты разнести по разным дата центрам на vps-ы...и купить у кого-нибудь большого ДНС службу с поддержкой роунд робина. Если настроете на впс-ах фаерволы, то вам даже ддос не так страшен!

тоже думал на тему надежности и тоже хочу пинка в нужном направлении ;)

как синхронизировать несколько БД (mysql) - суть мысли - есть одна главная база - в ней происходят все апдейты и раз в сутки (может и чаще) все изменения в базе должны продублироваться в другие архивные базы - как такое лучше реализовать? (самая простая мысля - всюду насувать полей изменения записи и по ним перетаскивать измененные данные) Всю базу бекапить на другой сервер не дело - она может быть весьма большой, а изменения будут преимущественно вставки и мало апдейтов старых записей, то есть за сутки будет меняться около 2-5% базы ориентировочно + периодически добавляться новых записей до 10% от общего объема.

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

чисто теоретически пишите сразу в 2-е базы, а читайте всегда с одной...что вам мешает это сделать? Недостаток тут конечно тот что нужно подифицировать все скрипты, где идет запись. Ведь на самом деле чтение к записи идет как 95/5 т.е. особой нагрузки запись делать не будет.

так будут проблемы если одна база пропустила запрос (грубо говоря сервер был недоступен несколько минут) - то есть так не факт что все что попало на главный сервер перенесется на резервные - а это обязательное условие - на резервном сервере не должно быть так, что есть запись за 10*50, но нету записи за 10*45 (для примера) - то есть обязательно должно быть, что либо обе записи попали на резервный сервер, либо вторая, но не может быть "провал" по времени.

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

Но если чесно, то мнене кажется что это правильное решение, сздайте для бекенда архитектуру, которая будет поддерживать 99.99% уптайм, с резервным сервером и т.д. и делайте просто бекуп 1 раз в сутки...этого вполне достаточно...и это можно сделать за оченъ небольше $!!!

Ну не проблема то построить MySQL кластер, для этого нужно минимум 3 сервера, делается средствами MySQL.

В интернете мануалы есть, да там собственно и делать то нечего особо...

При желании поднимается весь кластер HTTP+MySQL за 1-4 часа, в зависимости от кол-ва серверов и опыта в этом деле.

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