Дано: SQL2019CU31 Standard, настроена Push репликация на пару десятков таблиц.

Question

Дано: SQL2019CU31 Standard, настроена Push репликация на пару десятков таблиц.

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

Проблема: sp_refreshsubscriptions накладывает блокировку схемы Sch-M не только на добавляемую таблицу, но и на другие входящие в ту же публикацию, в том числе, ВНЕЗАПНО, на высоко нагруженные. Поскольку Sch-M не совместима ни с какими другими блокировками, инсерты начинают ждать эту сессию, выстраиваться друг за другом, тупить, вплоть до дедлоков между несколькими инсертами и сессией с Sch-M и длится это в лучшем случае 20 секунд, что недопустимо для бизнеса ака ЖОПА. Альтернативный вариант добавления sp_addarticle + sp_addsubscription (с указанием конкретной статьи), увы даёт ту же картину.

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

Может кто-то уже борол подобную хрень?

#programming #russian #sql

0

21.09.2023

14 ответов

23 просмотра

Free Raid

Вообще возникают вопросы к архитектуре! А зачем там репликация..

0

7 месяцев назад

Gopneg

Реплицируй базу, а не таблицы

0

7 месяцев назад

Evgeny V Автор вопроса

Free Raid
Репликация и высоконагруженные таблицы- это боль. ...

Если поделишься спецификой конкретных болей я с интересом послушаю, ибо мне наверняка предстоит с ними встретиться.

0

7 месяцев назад

Free Raid

Evgeny V
Если поделишься спецификой конкретных болей я с ин...

Там где можно отказаться от репликации. Посчитать , сколько данных меняется в таблице, сколько ради этого перечитывается лога базы данных . Справочники ( мало меняющиеся таблицы) передавать через прямые запросы или SSIS . Часто меняющиеся - выяснять потребности бизнеса - возможно не все и не так надо передавать. PS В моем примере каждый день реплицировалось 150Гб по медленному каналу. После доуточнения требований стало меньше 30 Гб (~2Гб в час)

0

7 месяцев назад

Mikhail Krupskiy

Gopneg
Реплицируй базу, а не таблицы

так если таблиц (для реплики) условно на гигабайт, а база на террабайт, накладных расходов сколько будет?

0

7 месяцев назад

Gopneg

Mikhail Krupskiy
так если таблиц (для реплики) условно на гигабайт,...

сколько? если этот тб не меняется? %)

0

7 месяцев назад

Mikhail Krupskiy

Gopneg
сколько? если этот тб не меняется? %)

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

0

7 месяцев назад

Gopneg

Mikhail Krupskiy
не, если не меняется то да. у нас просто почти так...

https://t.me/sqlcom/208089

0

7 месяцев назад

Evgeny V Автор вопроса

Free Raid
Там где можно отказаться от репликации. Посчитат...

А, то есть ваша боль была - тянуть репликацией большие объемы данных куда-то по медленному каналу. Да, тут её ограничения понятны. В нашем случае сервера рядом, канал максимально возможный. Объем реплицируемых данных в наших условиях - не проблема.

0

7 месяцев назад

Free Raid

Evgeny V
А, то есть ваша боль была - тянуть репликацией бол...

Проблема была не только и не столько в канале.

0

7 месяцев назад

Free Raid

Evgeny V
А, то есть ваша боль была - тянуть репликацией бол...

Проблема в архитектуре. Например, где-то использовали голденгейт

0

7 месяцев назад