При настройке ADG хочуподчеркнуть следущий момент.
На «log file sync» при наличии синхронного standby влияют: сеть и i/o-операции дисков standby.
Влияние i/o-операции дисков standby можно уменьшить, если включить режим передачи LogXptMode='FASTSYNC', ниже подробнее.
------------------
SYNC + AFFIRM
Соответствует свойству LogXptMode='SYNC' в Data Guard Broker.
Порядок действий при коммите на Primary:
1. Клиент делает COMMIT.
2. LGWR на Primary:
- записывает redo в локальный журнал,
- шлёт группy redo в Standby.
3. RFS на Standby:
- принимает группу и пишет её в SRL (буфер),
- вызывает fsync(), гарантированно записывает на диск.
4. RFS шлёт положительный отклик (ACK) обратно на Primary.
5. LGWR (Primary) получает ACK и возвращает управление клиенту.
Итого:
Гарантия нулевой потери данных: транзакция считается завершённой только когда redo физически записан на диск на Standby.
Высокий латентный overhead:
- дополнительная задержка на вызов fsync() на Standby,
SYNC + NOAFFIRM (он же FASTSYNC)
В Data Guard Broker: LogXptMode='FASTSYNC'.
Порядок действий при коммите на Primary:
1. Клиент делает COMMIT.
2. LGWR на Primary:
- записывает redo в локальный журнал,
- шлёт группу redo в Standby.
3. RFS на Standby:
- принимает группу и записывает её в SRL (буфер),
- не ждёт fsync() — то есть не гарантирует физическую запись на диск.
4. RFS шлёт ACK обратно на Primary сразу после приёма в память.
5. LGWR (Primary) получает ACK и возвращает управление клиенту.
Итого:
Умеренная защита данных: redo попал в SRL буфер, но может потеряться при сбое Standby до fsync.
Низкий латентный overhead:
- нет задержки на дисковый flush на Standby
Режим для ускорения failover и снижения задержек.
>>> "Умеренная защита данных: redo попал в SRL буфер, но может потеряться при сбое Standby до fsync."
О каких потерях идет разговор в режиме FASTSYNC?
Сценарий 1.
Наиболее реальный сценарий.
Изменения на Primary зафиксированы, т.к. отправлены и получены на Standby (в буфер, но пока не сброшены в redo).
Итого изменения пришли в буфер standby и далее Primary падает.
Standby докатит все изменения из буфера и далее активируется.
В итоге мы имеем синхронный активированный Standby.
Потерь нет.
Сценарий 2.
Редкий, но возможный сценарий.
Изменения на Primary зафиксированы, т.к. отправлены и получены на Standby (в буфер, но пока не сброшены в redo).
Итого изменения пришли в память буфер и далее Primary падает.
В этот момент падает Standby.
Изменения данных, которые были в буфере на Standby, но не скопированы в redo-файлы будут потеряны на стороне Standby.
В итоге мы имеем недоступные primary и standby c возможно разными данными.
Величина потенциальных потерь - объём несброшенных в Standby Redo Log страниц в кэше ОС (до fsync).
Ее размер не может превышать оразмер одного пакета (группы) redo, который LGWR формирует и отправляет RFS разовым write() вызовом (обычно ≤ log_buffer).
Конкретный размер прямо зависит от нагрузки (количества транзакций, объёма редо трафика) и от OS параметров (порогов dirty pages).
Общий вывод.
Предлагаю рассмотреть использование именно режима FASTSYNC (SYNC + NOAFFIRM).
Как на это повлиять на размер потенциальных потерь?
1. Уменьшить максимальный размер порции redo (то есть log_buffer) на Primary.
2. Настроить параметры ОС для более частой записи «грязных» страниц на диск
vm.dirty_background_ratio / vm.dirty_background_bytes — задать, сколько процентов ОЗУ или байт можно держать «грязными» до фонового writeback.
vm.dirty_ratio / vm.dirty_bytes — общий порог dirty страниц, после которого процессы вызывают writeback.
Чем ниже эти пороги, тем быстрее ОС будет самостоятельно сбрасывать буфер SRL на диск.
------------------------------
p.s.
DGMGRL> disable FAST_START FAILOVER;
Disabled.
DGMGRL> EDIT DATABASE mbank_02 SET PROPERTY LogXptMode = 'FASTSYNC';
Property "logxptmode" updated
DGMGRL> EDIT DATABASE mbank_01 SET PROPERTY LogXptMode = 'FASTSYNC';
Property "logxptmode" updated
DGMGRL> enable FAST_START FAILOVER;
Enabled in Zero Data Loss Mode.
