Kot358Задача такова, чтобы две базы могли "общаться между собой", т.е. изменения в одной попадали во вторую и также, изменения во второй попадали в первую.
Эта задача выглядит без дополнительных пояснений как равноправная репликация в распеределенной БД.
Такая можеь поддерживаться на уровне СУБД.
Например, в Оракле мультимастер репликация и поодерживается только в самых дорогих редакциях.

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

Т.е. в общем случае расчитывать на простое решение, не несущее хоть и редких, но тяжелых напрягов не следует, скорее всего.

Kot358Значит, если мы не можем решить эту задачу методами SQL, самый лучший вариант - продолжить "топтаться" на РИБ, правильно я понял?
Не уверен. Тем более, что термин методы SQL нуждаются в уточнении. По видимому Вы имели в виду на уровне СУБД. Я писал "про ручки подкрутить" у СУБД: настроить репликацию. Кто-то может быть взялся и сам разрабатывать что-то на уровне СУБД.

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

chatmKot358,

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

Вообще обнаружили, к примеру, что данные на серверах не равны. Как узнать какие данные правильные, какие нет? Как теперь сделать как должно было бы быть, если бы все правильно работало?

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