Форум сайта python.su
Есть две базы данных:
- онлайн БД (в электронном магазине)
- складская БД
Для фиксации покупки в БД используется таблица “заказы”.
Покупка возможна как непосредственно со склада так и онлайн.
Так выглядит таблица в онлайн БД:
$ id заказа
$ название товара
$ адрес доставки
В складской БД таблица имеет только два поля:
$ id заказа
$ название товара
Нужен механизм репликации складской и онлайн версии таблиц. В результате репликации в обеих версиях БД должны быть одни и те же данные.
И если изменить название товара в заказе в одной БД то после репликации название у этого заказа должно поменяться и в другой БД.
Репликация отложенная - будет производится, например, раз в 20 минут.
Репликация многосторонняя - данные могут изменяться и вводиться в обеих БД.
Механизм допустим любой:
- по принципу сравнения записей одной таблицы с записями другой
- или перенос только изменений, зафиксированных в журнале вносимых транзакций БД
В качестве СУБД используется MySQL (через ORM - SQLAlchemy+Elixir). В случае необходимости допустимо перейти на любую бесплатную СУБД.
Существуют ли какие-нибудь готовые изящные решения такой ситуации?
Отредактировано (Сен. 17, 2009 21:44:10)
Офлайн
Два можно разрулить следующим образом: в одной ставятся для pk ключей только четные, для другой – только нечетные значения – это исключит конфликты с добавлением записей. Но остается сложная часть – обновления. Если в промежутке времени и одна и другая сторона обновила одну и ту же строку – надо решить, кто победил. Для этого есть разные техники.
У меня такая система работает на PostgreSQL + Bucardo для двух серверов.
Офлайн
Я так понимаю репликация нужна на уровне приложения.
Офлайн
А готовое решение не устраивает?
http://www.webnext.ru/blog/2007/08/21/replication-mysql-master-slave.html
Офлайн
LexanderЕсли обратить внимание, на очень важное замечание в посте:
А готовое решение не устраивает?
http://www.webnext.ru/blog/2007/08/21/replication-mysql-master-slave.html
pymindТакое “Готовое” решение, скорее всего не подойдет.
В случае необходимости допустимо перейти на любую бесплатную СУБД.
Офлайн
FerromanК сожалению не понимаю что вы хотели сказать.
Я так понимаю репликация нужна на уровне приложения.
Офлайн
LexanderКак я уже заметил в своем посте, репликация здесь нужна многосторонняя (master-master). Иными словами, обе БД используются по отдельности, кажда со своим GUI (одна БД не служит для другой резервной копией (slave))
А готовое решение не устраивает?
http://www.webnext.ru/blog/2007/08/21/replication-mysql-master-slave.html
Офлайн
LolkaСпасибо за полезную информацию. Если не найду готового решения для MySQL, попробую Bucardo.
Два можно разрулить следующим образом: в одной ставятся для pk ключей только четные, для другой – только нечетные значения – это исключит конфликты с добавлением записей. Но остается сложная часть – обновления. Если в промежутке времени и одна и другая сторона обновила одну и ту же строку – надо решить, кто победил. Для этого есть разные техники.
У меня такая система работает на PostgreSQL + Bucardo для двух серверов.
Офлайн
pymindА что мешает запустить такой же механизм на 2 базе? :)
Как я уже заметил в своем посте, репликация здесь нужна многосторонняя (master-master). Иными словами, обе БД используются по отдельности, кажда со своим GUI (одна БД не служит для другой резервной копией (slave))
Офлайн
ZioNдопустимо != предусмотреть
Если обратить внимание, на очень важное замечание в посте:pymindТакое “Готовое” решение, скорее всего не подойдет.
В случае необходимости допустимо перейти на любую бесплатную СУБД.
Офлайн