купил базу - очень радует разделение на категории - покупкой доволен, ну а результаты будут видны позже, но думаю и с этим все впорядке будет
спасибо за качественную базу
в честь праздника за бесплатно сделаю - кидайте в личку ссылку на архив
реф линк Платону нужно кинуть и все ок будет
DLag, спасибо за наводку - будут проблему - обращусь
remsys, обязательно почитаю, спасибо
rusevgen добавил 30.12.2008 в 19:15
Searchers, для меня важны именно базы - скрипты будут "знать" куда ломиться, если база отвалилась (днс тут вообще ни при чем)
клиент-скриптов у меня было много (как пример - централизованная база новостей, которые по некоторому алгоритму "раздаются" на разные сайты).
я не утверждаю что решение оптимальное, да и не считаю себя знатоком в этой области - просто как пример что и за десятку уе можно увеличить надежность при маленьких проектах
если кто даст совет по моему вопросу - буду благодарен
вопрос:
что оптимальнее при отложенном дублировании изменений в резервной БД (грубо говоря в час ночи все изменения с основной БД нужно слить на резервную(ые) )- напихать везде флагов изменения+(возможно) полей с датой или создать отдельные таблицы в которых будут храниться изменения
это почему? если у меня клиент-скрипт может обратиться к любой из БД на этих "страховочных" аккаунтах если главная БД упала... конечно если одна база падала, мне приходилось потом вручную ее обновлять до актуального состояния... ну как бы за 15уе вполне нормальное решение, цель достигалась - данные доступны при отказах главной БД
да, при нормальных нагрузках и большой БД так не получится сделать (поэтому просил совета)
ну это больше вопрос к требованиям - можно придумать и по своим средствам, например раньше у меня вообще БД дублировалась на пару баз на обычных хостинг-аккаунтах - тогда меня вполне устраивала такая подстраховка и нагрузки были маленькие.
Сейчас продумываю более универсальное решение.
так будут проблемы если одна база пропустила запрос (грубо говоря сервер был недоступен несколько минут) - то есть так не факт что все что попало на главный сервер перенесется на резервные - а это обязательное условие - на резервном сервере не должно быть так, что есть запись за 10*50, но нету записи за 10*45 (для примера) - то есть обязательно должно быть, что либо обе записи попали на резервный сервер, либо вторая, но не может быть "провал" по времени.
тоже думал на тему надежности и тоже хочу пинка в нужном направлении ;)
как синхронизировать несколько БД (mysql) - суть мысли - есть одна главная база - в ней происходят все апдейты и раз в сутки (может и чаще) все изменения в базе должны продублироваться в другие архивные базы - как такое лучше реализовать? (самая простая мысля - всюду насувать полей изменения записи и по ним перетаскивать измененные данные) Всю базу бекапить на другой сервер не дело - она может быть весьма большой, а изменения будут преимущественно вставки и мало апдейтов старых записей, то есть за сутки будет меняться около 2-5% базы ориентировочно + периодически добавляться новых записей до 10% от общего объема.
Основная задача - вопервых если будет утеряна главная бд - восстановить "вчерашние" данные, вовторых, что бы в случае падения сервака основной бд скрипт мог обратиться к резервной бд для чтения данных.
была такая ситуация (правда на сателите большом) - помогло переписывание главной + периодическое добавление маленьких уникальных новостей (около 1к знаков каждая) - за месяц неуник странички тоже вернулись
rusevgen добавил 29.12.2008 в 10:51
как вариант - в социалки уник статьи добавьте
