. Дело в том что пока проект токо начинается писАться, поэтому я хочу как можно больше узнать о проблемах и их решениях связанные с репликацией.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > репликация |
| Автор: Zaman 8.9.2004, 12:43 |
| Какие методы решения могут быть при возникновении конфликтов |
| Автор: Akina 8.9.2004, 12:45 |
| 1) плюнуть 2) разрулить |
| Автор: Zaman 8.9.2004, 12:57 | ||
не решение Хочу использовать для СУБД MySQL, выяснил что там используется схема - ведущий/ведомый. Но она меня не устраивает! Хочу реализовать схему - "повсеместное обновление", при это решении могут возникать конфликты. Кто нибудь сталкивался с этой схемой и какие решения конфликтов существуют Добавлено @ 13:01 реально ли в субд mysql реализовать эту схему |
| Автор: Akina 8.9.2004, 13:11 |
| О! наконец-то мы знаем что речь идет о mySQL. Уже хорошо. Теперь опиши подробно о каких конфликтах при репликации идет речь. и какими средствами выполняется репликация. |
| Автор: GoodBoy 8.9.2004, 13:23 |
| Как-то делали систему управления для предприятия, так оно там было разбито на несколько филиалов. И целостность данных мы обеспечивали так: Использовали уникальные ключевые поля для каждого филиала. Т. е. у первого ВСЕ записи начинались на 1, у второго на 2 и т.д. И внутри филиала изменять можно было только свои записи, а чужие - только просматривать... Правда писано это было на Oracle, но думаю и для MySQL можно сделать что-то типа оракловых триггеров и сиквенсов для создания уникальных индексов НЕ через автоинкремент. Zaman, возможно такой метод тебе подойдет?? |
| Автор: Zaman 8.9.2004, 13:34 |
| GoodBoy твой метод похож на "повсеместное обновление", я учту твое решение этой задачи - благодарствую . Дело в том что пока проект токо начинается писАться, поэтому я хочу как можно больше узнать о проблемах и их решениях связанные с репликацией. |
| Автор: GoodBoy 8.9.2004, 13:50 |
| Zaman Ты опиши задачу - тогда легче будет что-нить посоветовать... :-))))))))) |
| Автор: Akina 8.9.2004, 13:51 |
| Основная проблема - исправление копии записи в 2 местах. разруливается по TimeStamp либо вручную. Остальные проблемы решаются более чем просто. Для независимых реплик - например выделением диапазона уникальных ID-ов каждой реплике либо хранением таблиц соответствия ID-ов локальной базы и удаленных реплик. Послебнее правильнее, поскольку не зависит от появления новых реплик, т.е. оповещение о появлении новой реплики (и ее регистрация) происходят явочным порядком, а не директивно. Кстати, это позволяет работать как в режиме реплицирования, так и в режиме распределенной базы без каких-либо изменений в структуре - просто добавляется модуль репликации отсутствующей записи. |
| Автор: LSD 8.9.2004, 15:02 |
| Всего может быть 3 типа конфликтов: - конфликт при insert, добавляются две записи конфликтующие по уникальному полю (полям) - конфликт при delete, в одной базе удалии запись а в другой ее подправили - конфликт при update, одновременная правка одной и той же записи Надо определиться со стратегией разрешения этих конфликтов и отсюда танцевать. |
| Автор: Zaman 8.9.2004, 18:40 | ||
Эти конфликты есть не тольк в репликации Не хотлеось бы занаво изобретать велосипед, а если есть универсальное решение, то его применить Всем благодарен за высказанные мнения |
| Автор: gemoglobin 9.9.2004, 08:36 |
| репликация и разрешение конфликтов вообще отдельная большая проблема в СУБД есть книга очень хорошая Э. Таненбаум, М. ван Стеен "Распределенные системы принципы и парадигмы" поищи в инете может e-вариант |
| Автор: GoodBoy 9.9.2004, 12:13 |
| Почитай вот тут: http://soft.org.ua/docs/mysql/ru/Replication.html может чем поможет... |
| Автор: Гость_Владимир 11.10.2004, 02:52 |
| Единственно хорошее описание на replication.narod.ru. В других местах - куча хороших общих фраз. А вообще то основная проблема связана с бардаком в бизнес правилах, приводящем к необходимости вручную разруливать конфликты. |