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

Имелось в виду свойство синхронной мультимастер репликации, отличающее ее от асинхронной.

Ну если СУБД умеет выполнять распределенные транзакции в распределенной среде, то почему синхронную репликацию реализовать сложнее чем асинхронную?
Dimitry Sibiryakov удивляло что сделали синхронную. И этот ответ был намеком, что таковую сделать, возможно, проще ячем асинхронную на СУБД которая подеоживает распределленные транзакции.

В асинхронной транзакция в исходнном узле помещается в очередь отложенных, потом распространяется по расписанию (через 10 сек) на другие и там выполняется. Если не сможет выполниться то помещается в очередь отложенных транзакций: можно искать причину почему не выполнилась, устранить причину и повторно выполнить.

iv_an_ru, Вы, возможно, начинаете хвататься за такие приемы, которые показывают Ваши заинтересованность как чрезмерную. Это для лидирующих СУБД не имеет значеия (им нельзя повредить), а для остальных, скорее всего, нуждается в большей осмотрительности.
Впрочем, дело Ваше. Вам пополяризировать Линтера, Вам виднее.

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

SergSuperблин, ну не надоело? Вам действительно интересно что он ответит?
Интересно иму, видать, с помощью назиданий типа отсаивать мыстль, что все СУБД примерно равны зачем-то. Возможно, и ТЖ7 или как там она ФМАЗ. Но собака лает, караван идет.

rodenЕсли мне не изменяет память в Oracle репликация появилась где-то в 2001 году.
В ЛИНТЕР в 2000-ом!

А в Аксцессе в 98? Или раньше? Возможно, даты прошлого не вседа могут помочь. Не вседа.
Нужно, возможно, еще что-то. Возможно, сегодняшнее. Да и ожидания завтрашнего могут, опять же иметь некое значение.

rodenВсе что касается ЛИНТЕР и Oracle, давайте переведем сюда

Это разумно. Сравнение, дествительно, поможет понять тем хто знает Оракл, что есть Линтер.
Ну и это безусловно претензия. И если есть что в нем то оценить. Ну а если превзойдет Оракла, то это серьезная заявка. Кста еще есть TCP тесты, куда бы прорваться было бы не лишним, шобы координально изменить положение дел у Линтера.

iv_an_ruvadiminfo,

Синхронность репликации не означает, что "транзакция или выполнится на всех узлах, или ни на одном". Она означает, что транзакция, успешно завершившаяся на мастере, успешно помещается во все журналы репликации одновременно с локальным коммитом, и что ни один подписчик не будет брать данные из таблицы, в которую выливается подписка, без проверки, что он в синхроне с мастером. При этом подписчик может хоть лагать, хоть вообще в дауне лежать --- мастеру по барабану, он будет просто писать в журналы. Подписчик прочухается --- залочит таблицу с подпиской, прочитает журнал до конца, встанет в синхронную позу и разлочит таблицу. Вот этим локом-разлоком синхронная репликация и отличается от асинхронной, больше ничем.

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

iv_an_ruМне линтер абсолютно по барабану, я OpenLink Virtuoso пишу. И как бы очевидно, что псевдореалтаймовая СУБД для бортовых систем и малых машин никак не пересекается с кластерной миддлварной СУБД/СУБЗ :)
Да но у Оракла есть в линейке продуктов БерклейДБ для тех же целей. Есть у него и in memory, если что. Так шо особо не расслабляйтесь там раньше времени.

rodenvadiminfo, а Вы разве встраиваемыми системами не занимаетесь?
В проектах в которох нужно было бы встраивать БД в устройства типа пулемента или КПК, пока не участвовал. Но семинар от Оракла был. Слушал.