планируется создаться зеркало сайта на другом хостинге для повышения надежности. 
встал вопрос синхронизации. сайт развлекательного плана, кроме содержимого БД есть ещё и файлы(фотографии). причем, файлы в имеющейся модели имеют уникальное имя, основанное на значениях из БД(к примеру, относительно сущности, к которой фотки относятся или просто автоинкрементое поле). в то же время, как может происходить, данные могут заноситься и на одном сервер и(например, в случае недоступности первого) на втором сервере.
данные не просто отличаются, и там и там могут иметься уникальные записи. т.е. просто переброс дампа исключается. такая себе синхронизация слиянием. а для 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 и тоже соответствие, что и мастер

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

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

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

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

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

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

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

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

скажем, так: в этом случае отсуствие коллизий зависит не от кода и некой веорятности, а только от человеческого фактора. положим, номер сервера(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. выиграваем в скорости и размере ключа.

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

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

Видимо теперь я вас совершенно не понимаю. Примитивный пример: у нас есть таблица users, и есть 100 таблиц которые связаны с таблицей users по первичному ключу. После "синхронизации" что бы избежать коллизии у половины строк из users назначаются новые первичные ключи. Теперь, что бы ссылочная целостность сохранилась, надо так же обновить индексы у 100 зависимых таблиц... 


Потому что вместо одного insert select используется 10 селектов и 100 апдейтов.


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



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

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

Да хоть раз в год пусть происходит. объект должен однозначно идентифицироваться всего 1м ключем одинаковым для всех серверов (пусть даже и составным)

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

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

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

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

в моем варианте так и происходит - поле guid это "где-то сохраненные ключи внешних сущностей"

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

ну, что за горячие финские парни! неужто я так раздражаю своей упрямостью/ограниченностью/непониманием(нужное подчеркнуть)?

Нет, не мог бы, т.к. id в яндекс маркете - это загран паспорт, а id у нас - это наш российский паспорт, который генерируется по своим законам, и которые яндексу не подвластны. 

А вот если бы все интернет магазины, участвующие в программе яндекса, были разработаны самим яндексом, то тогда он бы так и сделал.

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


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

И опять же. У яндекс маркета это вынужденная мера, т.к. данные к ним приходят из-вне от 3d-paty магазинов, и уверен это доставило им не мало хлопот при разработке. Вы же добровольно вешаете себе эту петлю на шею.


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


Синхронизация и репликация - это разные вещи. replication



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



Ну вы же сами согласились с тем, что сервер с данными месячной "свежести" никому не нужен 

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

дошли до споров о терминах. о"кей. как тогда под "тиражирование" попадает репликация слиянием(merge replication)?

Добавлено через 4 минуты и 8 секунд

как пример. на данном форуме вот так выглядит ссылка на раздел: http://forum.vingrad.ru/forum/PHP-forum.html
в БД ведь не "PHP-forum" выступает первичным ключом, а какой-нибудь id, равный 125487. правда? и ничего. два уникальных идентификатора: людям/поисковикам и "для внутренней кухни"

Добавлено через 7 минут и 32 секунды
наверное, уперся я в свой вариант исключительно оттого, что он "свой" и предполагает внесенния минимум изменений в существующий код.
пришла пора много думать и беспристрастно сравнивать   
спасибо за внимание.

Ок, проехали. Я вас не правильно понял. Вероятно, яндекс пользуется подобной схемой.


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


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

Все же первичные ключи, я уверен, здесь уникальны (как это про guid-ы говорится) во времени и пространстве.

И обрати внимание, что для топиков доступ уже по id http://forum.vingrad.ru/forum/topic-222972/anchor-entry1600986/30.html

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

конечно, обратил.
Но "PHP-forum" однозначно резолвится и никто от этого не страдает. правда? 
вообще говоря, нашел ещё один штук возможности дампить без привязки к автоинкременту: можно сделать неполный дамп и только на основании уникального идентификатора вытянуть все связанные объекты. т.е. такой себе объектный бекап в отличие от низкоуровневого "все подряд" лога изменений. 
но, правда, это уже никак не связано с созданием резерва-зеркала...

А теперь вопрос: стоит ли всё это создания сайта-зеркала?   
Большинство хороших хостеров гарантируют uptime около 99,9% и резервируют данные

Синхронизация?  


PHP-forum - это не первичный ключ, это индекс. Я тоже не знаком с движком форума, но уверен на ~100%, что первичные ключи в нем нигде не перегенерируются.

Не понимаю, откуда у всех PHP программистов такая любовь к велосипедам?

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

с точки зрения человека - это первичный ключ.

а сколько у форума независимых на уровне данных(в смысле - нет общего сервера БД или файлсервера) зеркал?   

откуда у всех РНР-программистов такая тяга к глобальным обобщениям?   

Первое не убедительно, ИМХО, проще сменить хостинг на нормальный. А вот вторая часть заинтересовала   

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

Плюс такого способа - можно делать n зеркал, и простота реализации.

Это сообщение отредактировал(а) HackMan - 4.8.2008, 23:04

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


Сколько зеркал не знаю, но у него как миниму еще 2 проекта использующего базу с юзерами.


Не знаю, я на C# программирую 


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

sTa1kEr, оу, сорри. Прочитал сначала первую страницу, остальное сразу не осилил  
Потом написал пост и стал читать дальше   

А вот импорт данных делать на тот случай, если ляжет master-сервер. Хотя, если ведущий сервер ляжет, можно на сайтах написать что-то вроде "Извините, в данный момент сайт недоступен по техническим причинам". Такое же не каждый день будет случаться, и пережить можно?

Добавлено @ 23:25

А вот про коллизии - можно реализовать структуру как на Вики - хранить историю изменений.

Это сообщение отредактировал(а) HackMan - 4.8.2008, 23:26

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

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

блоги и vingrad.ru? а они разве не на одном хостинге(т.е. просто работают с одной БД общего пользования)?

Ты однака не человека - ты программиста 


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

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

Если у тебя система это 1 сервер, то ты можешь смотреть с его точки зрения.

Но в данном конкретном случае у тебя получается так:

Жило было фото на имя Ивана Петровича Козлова, 
и тут сделали его копию и переложили из левого кармана в правый... И вуаля! Теперь у нас фото Иннокентия Абрамовича Шмыги.

Тебе не кажется это странным? 

война аналогий? пожалуйста. контент же остается прежним, потому тут скорее уместно сравнение: если на бумаге "кодак", то это фото Ивана Петровича Козлова. А если напечатать на другой бумаге, то это . Так у тебя получается?   

Ну вот ты сам все и объяснил 
Тогда ответь, почему одно и тоже изображение, но на разной фотобумаге - у тебя считается разным человеком? (имеет разный ID)

guid(т.е. уникальный в масштабах всей системы) - одинаковый. а то, что id разный - так и бумага разная... 

По этому-то именно он и должен быть первичным ключем пользователей.


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

Это сообщение отредактировал(а) sTa1kEr - 5.8.2008, 17:57

Только мы от него отказались раньше

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

skyboy, скажи, а у сайта динамика большая? Если нет, то можно еще один вариант использовать...

Верно, так как при использовании стандартного механизма репликаций этой проблемы просто нет - можно спокойно использовать int.

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

skyboy, ну тут смысл вообще какой. Начиналось все с того, что я долго думал, как снизить нагрузку на сервер практически до нуля (до уровня обработки статических страниц). Динамика помимо того что генерирует страницу сохраняет ее копию в качестве статической html. При обращении к движку он делает проверку, мол а надо ли страницу генерировать? (ответ на "надо ли" может зависеть от многих факторов, не суть в этом), если надо - генерируем, если нет, тупо через readfile отдаем пользователю уже готовый html. Процесс - псевдо-кэширование.

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

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

P.S. я надеюсь ты продумал ситуацию, когда у тебя первый сервак отказал, второй работает, обновляет СВОЮ базу, а потом, когда заработает первый ты должен уже его синхронизировать со вторым...

Вариант со статикой как раз-таки решает эту проблему, второй сервер не обновляется, но сделать это можно, если ты можешь отказаться от динамики хотя бы на 6-7 часов...

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