Есть одинаковые по структуре базы: База1 (офис), База2 (магазин 1), База3 (магазин 2).
В База3 и База2 забиваются приходы расходы, а в База1 Приходы-Расходы и Платежи по всем базам.
Тоесть создают Платеж на основании документов полученых из База2-3, и потом синхронизируются.

MySQL, INNODB

Необходимо организовать двухсторонний обмен между базами.
В голову ничего не лезет кроме как использование уникального идентификатора.

tbl_doc
`doc_id` INT AUTO_INCREMENT NOT NULL, -- локальный ключ
`doc_uuid` BINARY(16) -- глобальный ключ
`doc_type` INT NOT NULL COMMENT 'тип документа',
`doc_date` DATETIME NOT NULL,
`doc_number` INT
........
PRIMARY KEY (`doc_id`),
UNIQUE INDEX doc_uuid (doc_uuid)

tdl_docrow
`docr_id` INT AUTO_INCREMENT NOT NULL, -- локальный ключ
`docr_uuid` BINARY(16) -- ключ записи спецификации документа
`docr_docuuid` BINARY(16) -- ссылка-ключ на документ
`docr_produuid` BINARY(16) -- ссылка на товар
........
PRIMARY KEY (`docr_id`)

Локальный ключ используется для работы непосредственно в локальном приложении
Глобальный- для связи сущностей и при передаче из одной базы в другую.

Верном ли направлении двигаюсь?
Как можно еще обеспечить двухсторонний обмен?

Dimitry Sibiryakov :
1) текущее приложение в качестве идентификатора использует INT. И исходников приложения нет. Поэтому как выход из приложения передаем INT а уже sql через функции линкует его с BINARY(16).
2) вы предлагаете совсем отказаться от INT как идентификатора? Как это отразиться на производительности и индексами в базе?

koJIo6ok:
В магазинах нет интернета. Рассматриваем вариант 3G, но это тоже не выход.

SERG1257:
Про репликацию понятно, почитаю. Но все же, вышеприведенный вариант с UUID рабочий?
Базы должны содержать все изменения других баз.
Какие есть проверенный схемы (кроме репликации) для двустороннего обмена?

SERG1257: Репликация отпадает - не вижу как она поможет в нашем случает. Суть в том что все базы являются "мастером", просто на База2 и База3 есть ограничения по управлению некоторыми документами. И ессно Василий из магазина 2 не может просто так удалить документы Петрова с магазина 1.

Dimitry Sibiryakov: нет :)

Быстрым поиском нашел на Хабре http://habrahabr.ru/blogs/personal/87394/ о мултимастерах.

Итого:
Вариант 1: на UUID (описанный выше);
Вариант 2: Multi-Master репликация
- полностью отказаться от UUID
- в таблицах каждой базы определить auto_increment поля согласно схеме:
* Установим auto_increment_increment в N на каждом мастере.
* На каждом из N мастеров ставим разные значения auto_increment_offset, используя 1, 2,…, N.

Еще есть варианты?

Dimitry Sibiryakov: SERG1257 : выбрать такой, чтобы в дальнейшем существенно не менять схему.

Под репликацией я подразумеваю "репликацию средствами СУБД", напрямую сервер-сервер.

Вариант 2 на автоинкерментах имеет один ньюанс: максимальное количество серверов - 10 (0-9). Это не критично, но все же надо иметь ввиду. Разбивка ИДов на интервалы для каждого сервера не приемлема. Локальный ID хоть и назван локальным, но в амках одной базы он уникальный (сквозной по таблицам).
С UUID (GUID) такого нет.

С UUID (GUID) такого нет - нет предела по количеству серверов.

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