Синхронизация зеркал

[Ивансон]

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

[PorohoD]

Некропостером прошу не считать, но присоединюсь к вопросу.
Есть два хостинга: основной и зеркало
как сделать их синхронизацию раз в пол часа
Движок PhpBB 3.0.8

[MIT]

Зачем тебе это?

[PorohoD]

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

[MIT]

Кто мешает задосить второй хост?

[PorohoD]

второй хост не задосят потому что там динамик IP

[MIT]

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

[PorohoD]

да какая разница, это уже к теме не относится, вопрос как это сделать

[MIT]

Большая. Зачем делать вещи, не имеющие смысла и не приносящие пользы? Выбранное решение проблемы не всегда является оптимальным и наиболее верным. Если тебе надо защищаться от DDoS`а, то надо именно защищаться, а не ерундой страдать.

А что до синхронизации — крон тебе в помощь, пусть с одного сервака на другой через SSH кидается дамп базы, а также новые вложения и аваторки. Но второй хост будет в режиме ReadOnly, по-другому твоя задача с таким подходом нерешаема. Только не говори что у тебя шаред-хостинг и ты не знаешь что такое SSH и Cron.

[PorohoD]

нет не шаред, что такое ссш знаю, а вот крон что то где то слышал но никогда не видел

[MIT]

Почитай, это система выполнения задач по расписанию.

[PorohoD]

предположим, мне нужен второй зеркальный хост на случай неизвестного падения первого, а не для защиты от ддоса, какие варианты есть тогда?

[MIT]

Если тебе нужен второй хост в режиме ReadOnly, то схема, вкратце описанная выше, тебе подойдёт.
Если же тебе необходимы два параллельно работающих хоста, то вариантов несколько:

1) Использование одной базы данных. Подразумевается, что база существует в одном экземпляре и к ней одновременно подключены два хоста. Данный подход требует некоторых изменений скрипта форума (для использования разных таблиц конфигурации, например), однако стоит понимать, что падение сервера, на котором находится база, приведёт к неработоспособности обоих хостов. Как вариант, база может находится на третьем сервере, к которому подключаются оба форума.

2) На каждом из серверов имеется своя собственная база, все изменения проходят в режиме репликации в реальном времени. При грамотной модернизации скрипта форума можно добиться независимости форумов друг от друга, однако подобное решение довольно сложно в реализации.

[PorohoD]

вот меня интересует второй вариант, подробней пожалуйста опишите

[MIT]

Если подразумевается использование локальных серверов баз данных, то система может быть раелизована следующим образом:

Каждый из форумов запросы на изменение структуры/данных (UPDATE, INSERT, DELETE и т.п.) должен поочерёдно выполнить в двух базах. Сначала в своей базе, затем удалённо подключиться ко второму серверу и выполнить команды там.
Реализовать подобную синхронизацию можно либо общими транзакциями (если не выполнилось на втором хосте, то не выполнять и на локальном), а можно через систему отложенных заданий.

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

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

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

Если же возвращаться к проблеме высоких нагрузок, то куда как лучше подойдут системы одноранговой репликации транзакций, построенные, например, на основе нескольких узлов MSSQL. Не знаю насчёт аналогичных комплексных решений для MySQL, но Microsoft потратила немало усилий на создание довольно мощных инструментов в версии Server 2008.

Так что если хочешь попрактиковаться в написании подобных систем — пожалуйста. Но уверяю, от DDoS`а ты не защитишься (разве что если рассматривать другие два варианта синхронной работы, которые я описал выше). А если тебе нужна реальная защита, то почитай инфу по MSSQL, например тут: http://msdn.microsoft.com/ru-ru/library/ms151196.aspx. При желании можно построить даже отказоустойчивый кластер, но это уже и деньги и знания нужны существенные.