да я такой! сутки прочь, работа стоит. придётся ночь вкалывать.
как будто я имею опыт.    зафлудили...

как ни инкапсулируй, запросы все равно переделывать. о чем ты?

в случае чего мне понадобиться что бы то ни было отслеживать? 

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

навряд ли. необходимости не вижу 

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

скажем, так: в этом случае отсуствие коллизий зависит не от кода и некой веорятности, а только от человеческого фактора. положим, номер сервера(namespace) хранится в отдельном файле. и при обновлении алгоритмической составляющей неаккуратный программист заменит и этот файл... и все! амба! так что невеорятной коллизия все равно не будет.

не понял тебя. как я планирую делать систему, инициировать синхронизацию будет админ. т.е. и так будет происходить по схеме "мастер запросил - слейв ответил"
-----
ладно, достоинства и недостатки вариантов с GUID и с namespace + id обсудили. 
вариант Mal Hackа ещё обдумаю. может, я его неправильно понял?
систему bars80080 тоже не до конца, как мне кажется, понял.
ещё варианты для мозгоштурма будут? 

А кто говорит о раделении? У тебя есть лог изменений в Базе в виде запросов. Есть лог измененных файлов на севере. Все логи идут строго за сутки, ты берешь в час Х, в 00:30 к примеру делаешь апргрейда за вчера из этих логов. Никакой проблемы несоответствия файлов записям в БД не будет.


Ну так вообще замечательно =) Упрощает задачу разв 50 =)

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


Да, но совершить одну единственную ошибку,  в одном единственном файле из скажем 100 строк... Мгм
к тому же это может быть не файл а база с автоинкрементным полем 
Просто при установке сервера, регистрируешь его в ней и она отдает тебе новый ID для сервера (он же namespace). Ты его тут же прописываешь на сервере и все ок.

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



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

имхо

skyboy, для синхронизации файлов существует rsync, а mysql, может это поможет http://code.google.com/p/mysql-master-master/

skyboy, я не совсем понял, все таки это зеркало или два разных сайта с периодическим слиянием данных?

В первом случае всее предельно просто, как сказал bars80080. Настраиваем репликации данных master-slave, при использовании обновления/добавления данных используем master, при единственной выборки один из slave серверов. Все, данные будут гарантированно и прозрачно синхронизованы на всех серверах без каких либо коллизий индексов и без костылей с SQL дампами в PHP.
Единственный недостаток - это изменения на слйвы будут приходить с задержкой в несколько секунд.
Что же касаемо файлов пользователей, то их нет смысла дублировать. Для не них лучше выделить отдельный(ые) файловый(ые) сервер(а) и шустрыми винтами в raid 5, к примеру.

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


Я аж чуть кофем не подавился! Не шутите так больше  

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

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

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

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

чур меня, чур. ещё одно звено с неединичной надежностью. на котором ещё и работа системы завязана. брррр..

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

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

частичное обобщение дискуссии:
в случае необходимости создания зеркала с отдельно хранящимися БД и файлами(к примеру, фотки и прочие контент, генерируемый пользователями) возможны два подхода: репликация слиянием(как первое зеркало, так и второе имеют БД/файлы,которые могут модифицироваьтся вне зависимости от состояния второго зеркала; и наоборот - второе может модифицироваться вне зависимости от первого) и репликация транзакциями(когда модифицироваться может содержимое только первого зеркала, а второе и остальные зеркала подстраивают свое содержимое под содержимое первого).
достоинства второго подхода - относительная простота реализации и отсутствие коллизий(под коллизией понимается ситуация, когда произошла модификация какого-то объекта на обоих зеркалах независимо и тогда односторонняя синхронизация затрет изменения на синхронизируемом сервере)
достоинства первого подхода - равноправие контента на серверах(создание контента пользователями невозможно контролировать; и возможность добавить комментарий пользователя в момент, когда первое зеркало не работает и его подменяет второе - действительно важно).
----
для реализации первого сценария(слияния) надо задуматься над тем, чтоб исключить(или хотя бы снизить) возможность коллизии. Когда каждый объект идентифицируется только автоинкрементным ключом, то коллизий нет только в пределах одной таблицы на одном из зеркал. В масштабе несколькиз зеркал коллизии неизбежны. 
для уникальной идетификации объектов можно:
- дополнить автоинкрементным id неким полем вроде namespace, в котором будут данные, уникальные для каждого отдельного сервера(зеркала). тогда, даже после слияния списков, коллизии отсутствуют вовсе; одни и те же объекты отлично обнаруживаются даже после редактирования. недостаток: требуется  доработка кода(порою - значительная; приходится переделывать все запросы, в которых есть связывание таблиц) или предварительное проектирование(чтоб запросы сразу получались такими, как нужно)
- иденитфицировать объект неким псевдослучайным ключом, значительно снижающим вероятность коллизий(5 полей типа int, заполненные результатом вызова random() или результат вызова функции UUID()). достоинство в том, что это дополнительное поле можно заполнять только при экспорте данных, при импорте данных(если идентификатор не найден в БД и это новый, добавляемый объект) происходит генерирование "обычного" автоинкрементного(уникального в пределах БД) илдетификтора. что некритично повышает производительность(в сравнении с ключом из 2 полей) и, что главное, позволяет пользоваться теми же запросами, что и в БД без возможности слияния  - то есть код дорабатывается только в отношении механизмов экспорта и импорта. недостаток: вероятность коллизии существует и не зависит от кода/корректности настроек.
------
механизм репликации тоже зависит от того, будем ли мы делать объединение данных с зеркал, или просто перекроем содержимое одного зеркала(slave) содерджимым другого сервера(master). 
в случае, если нам требуется только подстроить состояние slave-сервера под состояние master-сервера(как мне кажется, именно об этом говорят sTa1kEr, bars80080 и Mal Hack),то и правда  - лучше вести лог действий в виде отельных файлов  - дамп запросов изменения БД и дамп манипуляции над файлам(можно в хитром формате лога, можно в виде PHP-скрипта).
в случае, если нам требуется слияние(то есть сложная логика по коррекции имеющихся объектов и определния расходений в данных), то возможно либо писать данные в виде XML(причем, использование всяких библиотек, строящих DOM дерево в памяти, неприменимо из-за потенциально большого размера результата - придется писать напрямую в файл), либо создавать "инструкцию по синхронизации" в виде готового к запуску PHP-скрипта: перенесели на нужный сервер. указали в настройках параметры доступа к БД и настройки путей  - и скрипт сам все сделал. естественно, вариант с XML гибче.
-------
сиим выделял достоинства, красным - недостатки.

Добавлено через 1 минуту и 5 секунд

забыл отметить, что этот вариант исполнения мы обсуждаем с Fortop.

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


Ага. Тогда еще проще - работаем только с мастером, все данные реплицируются на слейвы. Если мастер падает, то вместо него мастером делаем один из слейвов и продолжаем работать.


Если мастер лег, то на его замену мастером может стать любой из слейвов.


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

Хотя использовать guid я бы все-таки не стал просто за не надобностью и из-за достаточно значительного увеличения размера индексов.

моя идея, кстати, в том, что guid-like индекс используется только при импорте/экспорте. а в "обычных" запросах как использовался автоинкрементный int, так и используется. только один и тот же объект на разных серверах потенциально может иметь разный этот самый autoincrement int - он при импорте создается. и со всеми связями синхронизируется.

репликация происходит непостоянно. приведу на примере комментариев. 
0. живы оба сервера. основным(master) выступает первый. некто добавляет комментарий.
1. после чего сервер ложится и основным(master) выступает второй сервер. некто добавляет комментарий.
2. кого теперь ни сделаешь master'ом, при односторонней синхронизации один из комментариев будет удален.
или все же я уже второй день вас не понимаю, и вы тоже о слиянии данных говорите?

А после импорта/экспорта полностью перестраивать ВСЕ autoincrement индексы в БД? Или как?


Вы правильно меня понимаете. Только не учитываете, что:
1. Время между репликациями короткое, много комментариев за несколько секунд запостить не успеют.
2. На мастере ведется бинарный лог, т.ч. восстановить данные, которые не успели реплицироватся - минутное дело.
3. Как ни крути, но всякими PHP скриптами более надежная схема не получится. Можно использовать вариант Nigel с полной синхронизацией серверов, но в ущерб производительности.



Это сообщение отредактировал(а) sTa1kEr - 4.8.2008, 10:43

есть таблица objects. с полем guid и int auto_increment. 
есть таблица objects_links, где есть четыре поля: 
object_id_1 int,
object_guid_1 guid,
object_id_2 int,
object_guid_2 guid
когда импортируем, то в первую таблицу значение поля id не выставляем и оно генерируется автоматически.
во вторую таблицу вставляем значения только в поля типа guid. int'овские поля пока пусты.
после чего определяем из первой таблицы, с какими id были вставлены объекты и вставляем в нужные записи второй таблицы. вуа-ля. все старые запросы вполне работают без учета поля типа guid.

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

А как же ссылочная целостность? Какой вообще смысл в первичных ключах, если они будут по новой генерироваться каждый раз заново, причем для каждой таблицы отдельно? Если уж использовать guid, то только в качестве "нормальных" первичных ключей, и не надо никаких плясок с бубном тогда.


Тогда смысл репликаций вообще теряется.

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

при экспорте роль внешнего ключа играет guid, после импорта используется уже поле типа int. выиграваем в скорости и размере ключа.

почему же "пляски с бубном"? почему тогда номер загранпаспорта не используется в качестве идентификатора внутри страны?   

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