|
Можно ли доступиться с Secondary Replica к данным на Primary Replica?
|
|||
---|---|---|---|
#18+
Добрый день, Возможно кто-то сталкивался с похожей проблемой и имеет элегантное решение. В системе имеется функционал "ре-рендеринга" данных на UI, который завязан на сравнении версии данных в базе и версией, отображаемой на UI. Номер версии генерируется при помощи сиквенса (sys.sequences). Поскольку сервера находятся в Availability Group (MS SQL 2016 (SP2)), для разгрузки решили перенаправить этот функционал на SECONDARY реплику, сделав её read-only. При вычитке текущего значения сиквенса данные на primary и secondary отличаются на размер кэша, указанного при создании сиквенса (secondary всегда впереди максимум на размер этого кэша). Из за этого функционал ре-рендеринга не работает должным образом. Код: sql 1. 2. 3.
Можно ли каким-то образом сделать так, чтобы при запуске хранимой процедуры, отвечающей за "ре-рендеринг", текущее значение сиквенса считывалось всегда с primary сервера? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2021, 16:18 |
|
Можно ли доступиться с Secondary Replica к данным на Primary Replica?
|
|||
---|---|---|---|
#18+
JustCurious, понятно, что Вы не хотите выдавать секреты, но описание ситуации и проблемы малоинформативно, по крайней мере, для меня. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2021, 17:34 |
|
Можно ли доступиться с Secondary Replica к данным на Primary Replica?
|
|||
---|---|---|---|
#18+
Владислав Колосов, Секретов никаких нет ) Картина следующая. Допустим, размер кэша для сиквенса равен 5. Значение сиквенса в sys.sequences на обеих репликах приведён ниже PRIMARY SECONDARY 1 5 2 5 3 5 4 5 5 5 6 10 7 10 8 10 9 10 10 10 11 15 Пока прикрутил "костыль", который, выгребая текущее значение сиквенса на secondary реплике, делает поправку этого значения на размер кэша, чтоб не пропустить нужные данные, которые надо "ре-рендернуть" Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
В данном решении есть проблема, что ререндериться будет больше данных, чем надо, а приложением пользуется большое количество пользователей, что повысит нагрузку вцелом. Плюс, есть моменты, когда сиквенсы на обеих репликах совпадают (по крайней мере удалось этого добиться на тест-энвайронменте). Происходит это тогда, когда рендерить нечего в течение продолжительного времени и страницы со значениями сбрасываются на диск (на проде такое крайне маловероятно). ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2021, 18:02 |
|
Можно ли доступиться с Secondary Replica к данным на Primary Replica?
|
|||
---|---|---|---|
#18+
JustCurious, а почему current_value оказывается кратно размеру кэша, а не тому значению которое реплицируется с первичной реплики? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 20:50 |
|
Можно ли доступиться с Secondary Replica к данным на Primary Replica?
|
|||
---|---|---|---|
#18+
JustCurious, В целом, архитектурно -- лажа полная. Но закостылять можно отдельным коннектом, который всегда смотрит на primary и читает значение счетчика с нее. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 21:47 |
|
Можно ли доступиться с Secondary Replica к данным на Primary Replica?
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевич, я так и не понял смысла этого решения, так как на реплике находятся целостные данные, которые невозможно изменять. Если система читает данные с реплики, то она читает согласованные данные. Зачем портить это чтением данных с первичной реплики - совершенно непонятно. Думаю, что само решение написано "враскорячку" - часть данных берет с первичной реплики, а часть - со вторичной. Это приводит к несогласованности данных, за такие решения архитектора надо гнать в шею с работы. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2021, 16:51 |
|
|
start [/forum/topic.php?fid=46&fpage=35&tid=1685118]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 149ms |
0 / 0 |