планируется создаться зеркало сайта на другом хостинге для повышения надежности. 
встал вопрос синхронизации. сайт развлекательного плана, кроме содержимого БД есть ещё и файлы(фотографии). причем, файлы в имеющейся модели имеют уникальное имя, основанное на значениях из БД(к примеру, относительно сущности, к которой фотки относятся или просто автоинкрементое поле). в то же время, как может происходить, данные могут заноситься и на одном сервер и(например, в случае недоступности первого) на втором сервере.
данные не просто отличаются, и там и там могут иметься уникальные записи. т.е. просто переброс дампа исключается. такая себе синхронизация слиянием. а для MYSQL я нашел информацию только по репликации транзакций. потому решил изобретать велосипед. благо, вопрос о распределении непомерной нагрузки в данный момент не стоит.
решение вижу в следующей схеме:
0. сам движок(РНР-скрипты, html-шаблоны, javascrript и css) меняются сравнительно редко, при синхронизации в любом случае необходим контроль - сие делается вручную одновременно на двух серверах. 
1. дамп выглядит как РНР-скрипт. Т.е. один сервер формирует РНР-скрипт, который, будучи выполнен на втором сервере, сделает записи в БД(про синхронизацию БД чуть ниже), создаст файлы с соответствующими модели именами и заполнить файло из сериализованного содердимого, записанного в этом РНР-дампе. Т.е. и данные для БД, и содержимое файлов в любом случае - в одном-единственном файле.
2. при слиянии БД возникает вопрос конфликта имеющихся ключей. как синтетических автоинкрементных(на обоих серверах разные объекты могут иметь идентификатор 526), так и натуральных составных. так как у нас дамп формируется РНР-скриптом в виде РНР-скрипта, то мы можем реализовать следующее:
а) используем в качестве идентификаторов объектов дополнительно поле с уникальным содержимым. к примеру, подобным тому, что возвращает функци GUID() в MySQL. создаем в надежде, что возможность коллизии таких "ключей" на нескольких серверах намного ниже, чем у числового автоинкремента.
б) в работе сайта используем, как и раньше, в основном числовые ключи. добавленные поля станут уникальными идентификаторами только при репликации
в) следим за синхронизацией этих добавленных идентификаторов и используемых числовых ключей, чтоб они были синхронизированы
г) передаем в РНР-дампе инструкции по вставке только "глобально-уникальных" идентификаторов. плюс, формируем запросы, позволяющие уже на стороне-приемнике восстановить связи по числовым ключам по значениям "глобально-уникальных" строковых.
к примеру, 
categories
id        id_guid    parent_id      parent_id_guid      name
1         {89...}          0                      NULL                1111
2         {af...}           1                      {89...}             2222 
3         {f3...}           1                      {89...}             33333

причем, guid-ключи для хранения связей(в примере - поле parent_id_guid) может заполняться только перед созданием РНР-дампа и после создания благополучно очищаться - постоянно хранятся только идентифицирующее объекты.
в дампе, соотвественно примера, будет три инструции вставки и один запрос на update, который для записей, у которых parent_id == NULL обновит parent_id в соответствие с равенством id_guid = parent_id_guid.
-----------
зачем я так много писал? 
меня интересует, не просмотрел ли я чего? или может вообще - подобные механизмы синхронизации давно созданы и используются?

Мда, не совсем прозрачно. Сейчас попробую вникнуть.

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

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

Решается легко
Ключ должен быть составным.
1. часть это индекс сервера. 
2я часть это индекс объекта. 
3. один и тот же объект обязан иметь один и тот же индекс на всех серверах!
Для этого каждому серверу выделяется свое пространство имен для автоинкремента (для первого 0-1000000, для второго 1000000 - 2000000 и т.д.).

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

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

ээээ... а разве этой возможности нет? 

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

Не встречал.
Так или иначе они все реализуют схему namespace.


меня смущает зависимость от функции. Да и фраза в надежде.... 


Это не даст возможность нормальной работы с реплицированными данными. Так как числовые ключи пересекутся.
Теоретически ты можешь это отслеживать и пересчитывать ключи... ты что-то такое писал выше. Я не совсем понял 

Но на практике, пара NAMESPACE + ID должна быть неизменной все время существования записи (да и после ее смерти, ее не должны занимать). А значит что в работе ты должен использовать всегда ее,  а не только ID. По-сути эта пара и образует требуемый тебе GUID (global unique identificator)
Хотя, возможно, я просто не понял твоей мысли.



Это как раз и правильно. Бросать на самотек нельзя... Можно лишь частично автоматизировать учет границ.
Тут просто стоит разделить сразу две вещи.
1. когда используешь NAMESPACE + ID - то границы автоинкрементов не нужны.
2. Если используешь только ID - то нужно четко устанавливать границы.

Первый вариант мне кажется более простым в настройке 

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

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

Добавлено через 30 секунд
черт. как-то у меня слишком витеавато пишется 

Это существенный минус да. Но на практике...
У тебя должно это быть инкапсулировано. В общем, лично мое мнение, я бы пошел на эти трудозатраты... Потому что проблемы, которые могут возникнуть ниже, меня пугают больше, чем поработать лишнюю неделю.


Вот это мне и не нравится... Т.е. в случае чего, тебе будет очень сложно отследить откуда на этом конкретном сервере взялась именно эта конкретная запись

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

Возможна, в случае использования составного ключа с Namespace.

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

Но на любом сервере один и тот же объект будет иметь один и тот же ключ.

Добавлено через 1 минуту и 56 секунд
в смысле namespace + id у записи не меняется при репликации на другой сервер

Добавлено через 4 минуты и 1 секунду
И вот какой вопрос. А почему бы для повышения не только надежности, но и скорости не распределить данные?

Т.е. попросту не реплицировать их всюду, а хранить отдельно на каждом сервере свою порцию данных?

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

Я бы сделал несколько по другому. Я так понимаю, что два сайта вместе с базами будут физически на разных машинах.
Основной сервер, производя все изменения с БД посылает запрос в БД, и в случае успешного завершения тот же самый вопрос сохраняет в .sql файл. Добавление/редактирование файлов - фиксируется в текстовом файле filelist.xt в качестве полного имени файла.
Второй сервер раз в сутки запускает update.php, который забирает sql файл и fillist.txt с первого сервера и выполняет обновление БД по указанным звпросам, плюс через транспорт скачивает файлы. С файлами можно поступить еще таким образом, что update.php запускает на первом хосте time.php, который возвращает имена файлов с fileMtime, далее сравниваем с тем, что есть на зеркале и через транспорт переносим.

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

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

А смысл в телодвижениях целых два раза?

Если данные и так уже на зеркале...

Зачем их обновлять?

ну, не обновлять, упорядочивать в соответствии с серваком

bars80080, 
можешь объяснить чуть подробнее? Что значит "упорядочить" и для чего?
Я не работал с таким пока что. Поэтому мои изыскания больше теоретические. Поскольку даже книг не читал.

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

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

Ну и чего злится?

Я спросил твоего мнения, о том, в чем не имел опыта сам