Хм. Если говорить об идеальном случае, то оптимальная частота репликации определяется скоростью внесения изменений - каждое изменение должно доехать максимально быстро. Количество проблем при репликации непосредственно зависит от запаздывания репликации (количества изменений, сделанных пока некая запись "в пути"). В реале может вмешаться нелинейная стоимость одного сеанса связи. Скажем, если есть некое значительное количество фиксированной служебной информации, передающейся при каждом сеансе незначительно от количества передаваемых изменений, буферизация изменений приведет к уменьшению траффика и соответственно удешевится.

Лично у меня хорошо работала схема "раз в минуту, если есть данные для репликации". Кроме того, был вопрос с большими объемами - например, если выполнен апдейт миллиона строк. На этот случай были лимиты в буферах, в результате например первые десять тысяч изменений обрабатывались, отправлялись и принимались на клиенте, не дожидаясь подготовки к отправке последних записей из этого миллиона.

При правильном написании клиента даже 4 кБит/с обеспечивают комфортную работу.
Иначе говоря, тысяча пользователей толкаются на широком и дорогом канале ради счастья "не работать всем филиалом" благодаря провайдеру, по техническим причинам положившему канал на четыре часа.

Заодно у меня есть смутное ощущение, что "правильное написание клиента" в таком контексте обычно означает "пользователю на самом деле не нужны те фичи, которых мы не можем нормально сделать".

Наконец, мне весьма любопытно будет посмотреть на "потрудиться программеру нетупо" при передаче на клиента хотя бы десятимегового блоба. Скажем, прямо сейчас мои коллеги работают над проектом, где основные данные - техническая документация по зданиям (планы и прочее).

Cat2При фиговых каналах репликация болбов будет длится вечно. На кой ляд тянуть то, что может никогда не понадобится?
А кто предлагает тупо тянуть то, что может никогда не понадобиться? Вариантов много, например:

- Изменения в блобах редки. Соответственно, после первоначальной раскладки, изменения спокойно тянутся в фоне, никому не мешая. У меня, в частности, была специальная возможность ставить некоторые таблицы на исключительно ночную передачу.

- Пересылка по запросу с многократным использованием присланного блоба.

Cat2А еще могут электричество отключить. Это гораздо чаще бывает
Да не сказал бы, во всяком случае по моей практике. Также в любом случае отметим, что из величин А и А+Б при положительном Б известно, какая больше :)

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

К сожалению, я совершенно некомпетентен в технологических процессах.

Употреблять репликацию без необходимости - разумеется, глупость. Имхо - такая же глупость, как и противоположная крайность. Нужно смотреть по требованиям к системе и ее ожидаемому развитию.

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

Да, безусловно, для уменьшения объема можно было бы посадить машинистку, которая слушала бы линию и быстро-быстро набивала запись беседы. Это вполне позволило бы работать по плохому каналу. Но мне кажется, решение... не совсем технологичное :)

Cat2Головному офису не нужны детали.
Может быть и так.

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

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

Но в обоих случаях передача данных между БД - одна из форм репликации, имхо.

Cat2Разумется, не хочется нарушать правило о том что любая информация из базы может быть получена единственным путем.
Хм. Я не слишком ретиво отношусь к этому правилу.

Cat2Но именно использование репликаций его и нарушают. На мой взгля, это один из способов денормализации. Что может быть оправдано в реальной работе, но только тогда, когда это резко поднимает производительность.
Я бы не стал рассматривать именно так, но в целом - не возражаю против такой постановки вопроса. Разумеется, если репликация не дает значимых преимуществ, использовать ее не следует (как и любой сложный механизм, не дающий явной выгоды).

vadiminfoНо бывают вообще синхронные - транзакция либо на всех среврах выполняется, либо нигде.
Вот если честно, смысла именно этой операции я не особо понимаю. Это такое узкое место, что дальше просто некуда, отличный способ остановить работу на всех серверах разом :)

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

vadiminfoПредставьте банк с филиалами в разных городах. И ловкий парень снимает тем или иным способом деньги одновременно в двух городах.
Не представляю себе. См. описанное ниже: в одном из этих городов или в обоих банк пошлет команду "снять деньги" тому серверу, который реально ведет счет этого парня (например, серверу его родного города). Что мы имеем:

1. "Больше чем есть" никто не снимет.
2. Вместо требований к "все сервера онлайн" появляется всего лишь "операция будет выполнена, как только сервер того города окажется онлайн".

Пример как раз вполне реальный - например, в моем случае это называлось "отдача со склада в другом городе".

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

1. Некоторые операции выполняются только на "условно главном" сервере. Этот условно главный выбирается достаточно произвольно.

2. Некоторые операции выполняются на сервере, соответствующем географической (обычно) привязке данных. То есть обычно обращение к данным X идет с сервера Y; в редких случаях удаленной операции удаленный сервер пересылает на Y команду модифицировать X.

"Команда" - термин достаточно условный. Например, в Вашем примере с расходом банковского счета процесс можно построить так:

1. Выписывается расходный ордер (на любом сервере)
2. При необходимости ордер реплицируется на сервер, ведущий счет клиента.
3. Ордеру проставляется статус "выполнен" либо "отказано" с изменением суммы на счете
4. Изменение реплицируется обратно, клиенту выдаются либо не выдаются деньги.

vadiminfoВ синхронной проблемы сразу видны.
Безусловно. Вопрос в том, что синхронная репликация выдвигает такие требования к каналам связи, что в этом случае становится более естественным работать на одном сервере/кластере без всякой репликации.

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

vadiminfoУ меня второй сервер - типа резервный, поэтому я в случай отпада репликации просто выравню по первому
А почему не просто стендбай? На глаз вроде разница только в возможности выполнять на втором особо сложные отчеты, но зато накладные расходы...

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

- на счете M1 денег на серверах S1 и S2
- на сервере S1 снимают X1 денег, на S2 отправляется апдейт на M1-X1 денег
- на сервере S2 снимают X2 денег, на S1 отправляется апдейт на M1-X2 денег
- в итоге на S1 M1-X2 денег. На S2 получается M1-X1 денег. Оба числа расходятся, и ни одно не соответствует реально требуемому.