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

Ведь RAC выглядит в общем как несколько БД (нод), имеющее общее дисковое пространство, общие файлы БД. GoldenGate также использует общие параметры, общие трейлы и т.д.
Каким образом несколько процессов экстракта на разных нодах пишут в один трейл я могу ещё себе представить.
Но как несколько процессов репликата (на нескольких нодах) читают из одного трейла - понять не могу, каким образом они могут синхронизироваться по чтению, чтобы не применять одни и те же порции данных, как они делят общий трейл между собой, как договаривается кто какой блок читает и применяет?

Расскажите кто сталкивался, как это работает?

mefman,

Спасибо за комплимент.

Этот документ я читал, там не описано каким образом репликат, работая на нескольких нодах корректно вычитывает трейл, как он синхронизируется с репликатами на других нодах.
Там написано "сделайте вот так и будет хорошо".
А как работает - непонятно.

mefman,

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

проходил мимо...,

Правильно я понимаю тогда, что в конфигурации RAC:
extract работает на всех нодах источника
pump работает на одной ноде источника
replicat работает на одной ноде приёмника
???

Alexander RyndinLockerпроходил мимо...,

Правильно я понимаю тогда, что в конфигурации RAC:
extract работает на всех нодах источника
pump работает на одной ноде источника
replicat работает на одной ноде приёмника
???Нет. Вам уже выше сказали, что extract работает только на одной ноде. Дальнейшие детали зависят от типа extract. Например, у classic extract каждый поток redo парсит свой thread внутри extract

Тогда непонятно, например integrated extract каким образом работая на одной ноде сможет отслеживать данные, которые пишет другая нода?
То же самое classic, ведь на каждой ноде собственно свой "поток" записи в redo, каким образом classic extract может отследить поток redo который льётся с другой ноды?
Не понимаю.

Alexander RyndinRedo (online и archive) обоих нод должны быть доступны на обеих нодах. Всегда, это основное требование для работы RAC
Да, это понятно, они доступны на общей файловой системе.
Но ведь intergated extract (у нас работает в таком режиме) производит захват данных не из файловой системы, а подключается к стриму ноды (в оперативной памяти ноды). Если extract будет работать только на одной ноде, то соответственно данные, которые пишет в RedoLog другая нода - ему будут неизвестны и он их пропустит.
Вот это собственно мне непонятно, каким механизмом extract работая только на одной ноде будет видеть и захватывать данные, которые пишет другая нода?

Alexander RyndinIntegrated Extract будет просто читать redo с диска. Чтения из redo буфера это оптимизация, но если оттуда не получается читать, то он просто не будет использовать эту оптимизацию. Теряться ничего не будет.
Правильно ли я понял, что:
1. Каким-то волшебным образом ;-) LogMiner, работающий на ноде, на которой запущен Integated Extract вычитывает данные из RedoLog общей файловой системы, парсит его и отдаёт экстракту?
2. При этом будет немного потеряна оперативность - захват будет производиться только при switch logfile, так?

Большое всем спасибо, стало намного понятнее.
Видимо переделывать конфигурацию GoldenGate специально под RAC надо.

Alexander RyndinДля integrated ничего дополнительно настраивать не надоДа, у меня именно integrated.
Спасибо.