A K пишет:
А вот с синхронной репликацией на уровне триггеров есть реальный шанс
получить большие проблемы (по моему скромному мнению это путь в никуда).
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора. Изменения в оперативной БД, должны попадать
на архивную. Синхронная репликация триггерами тут сгодилась бы
как нигде. Сейчас все упирается в скорость, которая упирается в
невозможность держать открытым соединение из одной БД в другую на
уровне сервера.
Только не надо такую базу называть "архивной".
А то волосы дыбом встают от "синхронной репликации триггерами в архивную БД".
В качестве конструктива предлагаю подумать над архивированием в отдельную БД
только устаревших данных из наиболее быстрорастущих таблиц. При этом архив
должен только пополняться, но не редактироваться.
Те запросы (предположительно, редкие), которым нужен доступ к обеим частям БД,
можно переписать, например, с использованием процедур, где анализировать,
действительно ли затребованы архивированные данные.
В архив данные сбрасывать раз в месяц/квартал/полгода/год - на выбор.
