план уйти на AG (2 ноды primary OLTP , Secondary DWH ) и избавиться от репликации.
( уже поднято на 2 тестовых env.)
и вот там возникли заморочки с change tracking
(ПК вычитывает на primary , А все остальное на Secondary и там есть задержка - редко но данные не успевают синкануться на секондари , 1-2 раза в стки но тем не менее ...)
рассматриваем возможность уйти на CDC ( чтобы читать все с Secondary)
Экспереиентирую , читаю пока мат. часть
https://desertdba.com/how-to-get-change-data-capture-to-work-in-an-availability-group/?utm_source=rss&utm_medium=rss&utm_campaign=how-to-get-change-data-capture-to-work-in-an-availability-group
нашли вроде вокрараунд как автоматом. переключиться после failover
https://malapatidatabase.wordpress.com/2017/11/21/recommendations-tips-and-tricks-for-change-data-capture-cdc/
Be aware also that when a log disk becomes full, you cannot shrink the log file by backing it up and manually shrinking it until change data capture has processed all transactions. But change data capture cannot process the transactions when the log disk is full, because change data capture writes to change tables are logged operations. In this case, the easiest way to recover from this situation is to temporarily add another log file on a different disk.
Про логи вот не нравится - будут ли они ночью шринкаться без проблем (а вдрук там каая зависнет CDC операция ?)
если кто имел РЕАЛЬНЫЙ Практический опыт использования CDC
и может чего подскзаать (ссылками или без) велком
лучше в личку (чтобы не засорять эфир.)
Простите за вопрос - а зачем логи ночью шринкаются?
Поддерживаю вопрос. Ночное шринкование логов - самое вредное и бесполезное занятие. На другой день они снова вырастут + потеря времени на выделение места. Настройте нормальный бекап логов, и они не будут расти. До 3/4 от размера MDF - вполне нормальный размер LDF.
Обсуждают сегодня