Некоторые из которых постоянно нагружены инсертами на уровне тысяч операций в секунду. И всё бы ничего, но надо иногда добавлять новые таблицы в репликацию, стандартно - через вызов пары хранимок sp_addarticle + sp_refreshsubscriptions.
Проблема: sp_refreshsubscriptions накладывает блокировку схемы Sch-M не только на добавляемую таблицу, но и на другие входящие в ту же публикацию, в том числе, ВНЕЗАПНО, на высоко нагруженные. Поскольку Sch-M не совместима ни с какими другими блокировками, инсерты начинают ждать эту сессию, выстраиваться друг за другом, тупить, вплоть до дедлоков между несколькими инсертами и сессией с Sch-M и длится это в лучшем случае 20 секунд, что недопустимо для бизнеса ака ЖОПА. Альтернативный вариант добавления sp_addarticle + sp_addsubscription (с указанием конкретной статьи), увы даёт ту же картину.
Надеялись заглянуть внутрь хранимки, чтобы понять логику работы, но там внутри лишь вызов зашифрованной процедуры из Resource базы, так что боль-печаль.
Может кто-то уже борол подобную хрень?
Репликация и высоконагруженные таблицы- это боль. Вы сами её выбрали. Никак. Или писать велосипеды. Велосипеды бывают неплохие..
Вообще возникают вопросы к архитектуре! А зачем там репликация..
Реплицируй базу, а не таблицы
Если поделишься спецификой конкретных болей я с интересом послушаю, ибо мне наверняка предстоит с ними встретиться.
Там где можно отказаться от репликации. Посчитать , сколько данных меняется в таблице, сколько ради этого перечитывается лога базы данных . Справочники ( мало меняющиеся таблицы) передавать через прямые запросы или SSIS . Часто меняющиеся - выяснять потребности бизнеса - возможно не все и не так надо передавать. PS В моем примере каждый день реплицировалось 150Гб по медленному каналу. После доуточнения требований стало меньше 30 Гб (~2Гб в час)
так если таблиц (для реплики) условно на гигабайт, а база на террабайт, накладных расходов сколько будет?
сколько? если этот тб не меняется? %)
не, если не меняется то да. у нас просто почти такая же боль, но не все высокнагруженные таблицы в реплике
https://t.me/sqlcom/208089
А, то есть ваша боль была - тянуть репликацией большие объемы данных куда-то по медленному каналу. Да, тут её ограничения понятны. В нашем случае сервера рядом, канал максимально возможный. Объем реплицируемых данных в наших условиях - не проблема.
Проблема была не только и не столько в канале.
Проблема в архитектуре. Например, где-то использовали голденгейт
а кто такое голденгейт?
https://docs.oracle.com/goldengate/c1230/gg-winux/GGCON/introduction-oracle-goldengate.htm#GGCON-GUID-EF513E68-4237-4CB3-98B3-2E203A68CBD4
Обсуждают сегодня