Чаму хуткі VPN усё яшчэ запавольвае сінхроннае фіксаванне ў SQL

Адкрыйце сеанс запыту на асноўным серверы і паглядзіце, чаго чакае простае запісванне. Калі база даных уваходзіць у групу даступнасці з сінхронным фіксаваннем і другасны сервер падключаны, частка гэтага чакання выходзіць за межы будынка: запісы журнала ідуць на рэпліку, там замацоўваюцца, і вестка пра гэтае замацаванне вяртаецца раней, чым фіксаванне завершыцца. Прапускная здольнасць не скарачае гэты шлях туды і назад. Ніжэйшае апісанне прасочвае пацвярджэнне ад экрана да выдаленага дыска і назад.

Пачніце з тыпу чакання на асноўным серверы

Запісванне, якое чакае на выдаленай рэпліцы, выглядае як чаканне, звязанае з журналам, а не як чаканне працэсара ці блакіроўкі, і працягласць транзакцыі залежыць ад шляху туды і назад, а не ад колькасці радкоў. Мноства дробных фіксаванняў робіць гэта відавочным, бо кожнае асобна плаціць за шлях. Адна масавая аперацыя хавае тую ж цану ў адным даўжэйшым пацвярджэнні.

Перад любым высновам пра канал адсартуйце працоўную нагрузку паводле частаты фіксаванняў.

Прачытайце стан рэплікі раней, чым чытаць сетку. Істотныя лічыльнікі — чарга адпраўкі, чарга перанабірання і стан сінхранізацыі, і разам яны паказваюць, ці паспявае другасны сервер ці адстае. Чарга адпраўкі, якая расце, паказвае на транспарт, а чарга перанабірання, якая расце, — на ўласную працу ці сховішча другаснага сервера. Гэта розныя рамонты, і ні адзін не паляпшаецца ад дадання прапускной здольнасці.

Прасочыце пацвярджэнне да другаснага сервера

Пры сінхронным фіксаванні асноўны сервер чакае пацвярджэння, што адпаведны журнал замацаваны на другасным, перш чым паведаміць пра завяршэнне фіксавання. Замацаванне азначае даўгатрываласць у журнале, а не перайгранне ў старонкі даных. Менавіта гэтае адрозненне тлумачыць, чаму сінхронны другасны сервер можа адставаць у перанабіранні, але працягваць пацвярджаць замацаванне.

Прайдзіце шлях па парадку і замерце кожны этап, а не ўвесь цэлы. Запісы журнала ідуць праз транспарт, другасны сервер запісвае і скідвае іх на дыск, а пацвярджэнне вяртаецца тым жа шляхам. Затрымка транспарту, планаванне на другасным серверы і затрымка дыска журнала другаснага сервера — усё гэта ўваходзіць у агульны час, і толькі першае належыць уладальніку сеткі. Другасны сервер, чый аб’ём журнала насычаны чымсьці іншым, можа падоўжыць кожнае фіксаванне, пакуль канал стаіць без работы.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Зрабіце такі здымак да і пасля паказальнага запісвання, а не адзін раз у ціхі паўдзень. Менавіта рознасць скажа, якая чарга рухалася, пакуль фіксаванне чакала.

Мерце шлях, а не канал

Тэст прапускной здольнасці вымярае ёмістасць паміж дзвюма кропкамі, якія не з’яўляюцца вашымі рэплікамі, пад нагрузкай, якая не з’яўляецца вашай працай. Папрасіце ўладальніка сеткі даць затрымку і страты на рэальным шляху рэплікі, пакуль ідзе рэальны трафік, у абодвух напрамках. Страты тут важнейшыя за ёмістасць, бо страчаны сегмент каштуе перадачы паўторна, і кожнае фіксаванне чакае на адным пацвярджэнні. Канал, які выглядае выдатна ў тэсце спампоўкі, можа дрэнна падыходзіць для шматслоўнай схемы фіксаванняў.

Падчас вымярэння не парушайце бяспеку транспарту базы даных і кантроль доступу. Вымярэнне шляху ніколі не з’яўляецца прычынай іх абыходзіць.

Суаднясіце час з лічыльнікамі, а не з інтуіцыяй. Калі чарга адпраўкі застаецца пустой, а фіксаванне ўсё яшчэ чакае, затрымка ў пацвярджэнні ці ў скідванні на другасным серверы. Калі чарга адпраўкі ўстойліва расце, абмежаваннем з’яўляюцца транспарт ці ёмістасць. Запішыце, якое назіранне пацвердзіла выснову, каб наступны чалавек мог паўтарыць вымярэнне, а не спрэчку.

Што асінхронны рэжым сапраўды змяняе

Асінхроннае фіксаванне здымае чаканне пацвярджэння замацавання ад другаснага сервера, і менавіта таму запісванне паскараецца і ваша становішча з даўгатрываласці змяняецца. Асноўны сервер пацвярджае транзакцыю без гэтага выдаленага пацвярджэння. Тады другаснаму дазволена адставаць, і гэтае адставанне і ёсць рызыка.

Калі асноўны сервер страчаны раней, чым журнал дасягае прыдатнай мэты пераключэння, прымусовае перанясенне сэрвісу на гэтую рэпліку адкідае транзакцыі, пра фіксаванне якіх праграма ўжо была апавешчана.

Гэта рашэнне пра кропку аднаўлення, і яно належыць уладальніку базы даных, а не агляду прадукцыйнасці. Спачатку задайце дапушчальнае акно страты даных, абярыце рэжым, які яго задавальняе, затым аптымізуйце ў гэтых межах. Варыянты, якія захоўваюць сінхронную абарону, уключаюць выдаленне пазбежных шляхоў фіксавання туды і назад там, дзе праграма гэта дазваляе, выпраўленне вымеранага вузкага месца ў транспарце ці сховішчы і перамяшчэнне рэплікі, каб пацвярджэнне пераадольвала меншую адлегласць. Узважце іх супраць патрабавання даўгатрываласці, з якога вы пачалі, і якое не змянілася.