pymind
Я имею в виду, что обмениваться “новостями” между базами придётся на уровне приложения, а не на уровне базы данных, т.е. встроенные механизмы движков базы не подойдут по критериям задачи.
Не понятно почему нельзя пользоваться одной базой из всех клиентов. Тем не менее, я бы делал сравнением данных, если нужна надёжность, или журналом изменений, если нужна скорость.

Ferroman
встроенные механизмы движков базы не подойдут по критериям задачи.

Почему ты так думаешь? Вроде ничего не мешает.

Репликация должна быть обоюдной, отложенной и частичной. Стандратный механизм MySQL все вместе, вроде как, не поддерживает.
Можно взглянуть на PostgreSQL, я там что-то встречал такое. Ну и это все можно сэмулировать хранимыми процедурами/тригеррами на уровне базы.

Ferroman
Репликация должна быть обоюдной, отложенной и частичной. Стандратный механизм MySQL все вместе, вроде как, не поддерживает.

Углубился в тему немного. Таки есть проблемы с мастер-мастер. Согласен.

Ferroman
Можно взглянуть на PostgreSQL

Я бы даже на этом варианте и остановился. Но автор сам себе хозяин.

Ferroman
Ну и это все можно сэмулировать хранимыми процедурами/тригеррами на уровне базы.

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

Я бы даже на этом варианте и остановился.

Там есть какие-то более продвинутые инструменты для репликаций?

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

Почему?

Ferroman
Не понятно почему нельзя пользоваться одной базой из всех клиентов.

Дело в том, что на складе есть проблемы с интернетом. Есть большая вероятность, что его могут на продолжительное время отключить. Это происходит время от времени. И при наличии только одной БД, мы бы имели риск лишиться доступа к данным в нужный момент и не смогли бы вести учет заказов со склада.

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

А обратная связь тогда зачем? Не проще просто синхронизировать время от времени онлайн базу с основной?

Ferroman
Там есть какие-то более продвинутые инструменты для репликаций?

Да, особенно, если учитывать возраст СУБД по сравнению с Мускулом.
Причем, есть решения Enterprise-уровня (собственно, master-master репликация это и подразумевает, решений master-slave вообще с десяток) с разным функционалом: от PGCluster, указанного выше Bucardo до Cybercluster (решение от компании ,которая профессионально занимается поддержкой Постгри).

Ferroman
Почему?

1. Асинхронная (ключевое слово, из-за которого и возникает основная проблема) мастер-мастер репликация - штука сложная и при разработке будет много подводных камней. Учитывая планируемый автором интервал 20 минут, велика вероятность конфликтов при операциях: вставка (уникальность), обновление, удаление. А значит, нужен механизм разрешения конфликтов, сам знаешь, штука непростая в реализации (хотя должен делать вещи вполне простые).
2. Нужна система мониторинга. Спустя некоторое время после ввода в эксплуатацию самописанной системы всегда возникает вопрос (у руководства, конечно): в каком состоянии “это”, почему есть нестыковки (а они будут!) и как их устранить (не допустить в будущем). Мониторинг и будет этим заниматься. Плюс подспорье в отлове багов.
3. Еще к вопросам: как “этим” можно управлять. Т.е. система администрирования. Желательно, связанная с системой мониторинга.
4. Асинхронность подразумевает настраиваемый интервал репликации, который прямо влияет на объем данных реплик. К тому же упомянутая плохая связь и перебои с электричеством тоже будет влиять на объем реплик или их количество. Над этим вопросом тоже нужно подумать. Этот пункт можно опустить, если количество операций невелико и синхронизировать действительно нужно только пару-тройку “нешироких” таблиц.
5. Уже существуют устоявшиеся и работоспособные системы.

Все это и вызывает у меня из памяти фразу: зачем изобретать велосипед?

Впрочем, вот эти вот слова:

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

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

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

Ну, раз есть готовые решения с PostgreSQL, то действительно огород городить не стоит. А детальнее задачу тоже бы не помешало рассмотреть, может там просто мелкие изменения слать надо, и игратся с репликациями слать нет смысла. И кросс-базовость останется…

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

Спасибо за желание помочь. Итак подробнее:

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

Есть локальная складская БД.
1. Когда на склад поступают новые товары, они вносятся именно в локальную БД, и лишь после синхронизации эта информация становится доступна для пользователей электронного магазина.
2. Когда покупатель делает заказ не через сайт, а через телефон или приходит в офис, то заказ фиксируется менеджером в локальной БД. После синхронизации клиент может видеть все свои заказы в онлайн БД через свой аккаунт.

Таблица “заказы” может изменяться как клиентами в онлайн БД, так и менеджерами в локальной. Грубо говоря менеджер может работать локально со складской базой, вносить новые поступления, регистрировать новые заказы, а затем “отдать” эти изменения в олнайн БД. И “забрать” из онлайн БД заказы, которые были сделаны через электронный магазин.