Чаму ваша сінхронная фіксацыя SQL чакае кругавога шляху праз VPN
Сінхронная фіксацыя ў групе даступнасці ўключае замацаванне аддаленага журнала. Памерце гэты шлях, перш чым вінаваціць прапускную здольнасць або змяняць рэжым.
Затрымка запісу падскочыла пасля пераносу рэплікі на другі сайт, а тунель — найноўшы кампанент, таму вінавацяць яго. Тунель можа быць невінаватым: у групе даступнасці з сінхроннай фіксацыяй асноўная не можа пацвердзіць фіксацыю, пакуль не завершыцца запіс аддаленага журнала, таму кожная транзакцыя плаціць кругавы шлях, колькі б мегабіт ні здольна была перадаць лінія. Прапускная здольнасць мерае байты за секунду, затрымка мерае, колькі доўжыцца адзін абмен, а фіксацыі патрэбны толькі адзін невялікі абмен, каб завяршыцца. Адзін лік вырашае спрэчку: працягласць фіксацыі невялікай транзакцыі, вымераная ў базе даступнасці і зноў супраць лакальнай табліцы на тым жа асобніку.
Чаго асноўная насамрэч чакае
Пры сінхроннай фіксацыі асноўная трымае пацверджанне фіксацыі, пакуль партнёр не пацвердзіць, што яго запісы журнала замацаваныя. Замацаваныя значыць надоўга запісаныя ў журнал транзакцый другаснай, а не перайграныя ў яе старонкі даных. Redo можа адставаць на хвіліны, не дадаючы ні мілісекунды да фіксацыі асноўнай.
Дакументацыя Microsoft пра рэжымы даступнасці апісвае гэтае рукапацісканне і тлумачыць, што робіць платформа, калі партнёр выпадае. Рэпліка, пазначаная як сінхронная, — гэта правіла пра чаканне, а не пастаянная абяцанка, што для кожнай фіксацыі існуе здавальняючая аддаленая копія. Адключаны шлях вызначаны асобна, і гэта не проста правал фіксацыі.
Такім чынам, чаканне — гэта сума: перадача журнала, планаванне на абодвух хастах і запіс на аддаленым сховішчы. Другасная з насычаным аб'ёмам журнала дадае час, якога не пакажа ніводзін тэст хуткасці. Гэты дыск рэдка вымяраюць, калі скарга называе VPN.
Прапускная здольнасць — не затрымка кругавога шляху
Тэст хуткасці ненадоўга затапляе шлях і паведамляе пра хуткасць. Фіксацыя ж пытае вузчэйшае: колькі часу трэба невялікаму паведамленню, каб дасягнуць таго боку, быць захаваным і вярнуцца. Даўжыня шляху, чэргі і страты пакетаў вызначаюць гэты лік, і нішто з гэтага не паляпшаецца, калі пастаўшчык падымае столю.
Таму «хуткі» тунель можа дадаць прыкметны штраф да працаёмкай па запісе нагрузкі, пабудаванай з мноства невялікіх паслядоўных транзакцый. Тыя ж байты, падзеленыя на тысячу фіксацый, плацяць кругавы шлях тысячу разоў; адно масавае перанясенне плаціць яго адзін раз.
Папрасіце ўладальніка сеткі вымераць затрымку і страты на самім маршруце рэплікі пад рэпрэзентатыўнай нагрузкай. Ping з офіснага ноўтбука да шлюза VPN або тэст хуткасці да блізкага вузла амаль нічога не адносяць да маршруту, па якім журнал сапраўды ідзе. Дабіцеся, каб акно вымярэння перакрывала гадзіны, калі запіс павольны.
Прачытайце стан рэплікі, перш чым нешта змяняць
Пачніце з таго, што асобнікі паведамляюць пра сябе, бо два бакі могуць разыходзіцца ў думках пра тое, наколькі здаровае партнёрства, і сярэдняе на панэлі хавае, якая чарга рухаецца. Запыты ніжэй адказваюць на розныя пытанні: адзін чытае стан рэплікацыі па кожнай базе даных, другі — як наладжана кожная рэпліка. Запусціце абодва, перш чым кранаць рэжым.
SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;
SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;
Першы вынік аддзяляе перадачу журнала ад redo. log_send_queue_size расце, а redo_queue_size стаіць на месцы — журнал не дайшоў; адваротнае значыць, што ён дайшоў, а перайгрыш адстае. Толькі першы выпадак знаходзіцца на шляху фіксацыі.
Другі вынік пацвярджае, якія рэплікі сапраўды наладжаныя так, як вы мяркуеце, бо рэжым, зменены падчас папярэдняга інцыдэнту, схільны заставацца змененым і недакументаваным. Чытайце радок, які вас цікавіць, а не стандарт групы: availability_mode_desc і failover_mode_desc — для кожнай рэплікі. secondary_lag_seconds існуе толькі ў SQL Server 2016 і пазней, таму старэйшая зборка пакідае вам толькі слупкі чаргі адпраўкі і redo.
Потым вымерайце рэпрэзентатыўны запіс замест таго, каб верыць сярэдняму на панэлі. Запусціце блок ніжэй у базе даступнасці, а затым зноў супраць такой жа формы табліцы ў базе па-за групай на тым жа асобніку. Розніца паміж дзвюма працягласцямі — прыблізны кошт аддаленага журнала, і ў спрэчцы з сеткавай камандай яна трымаецца значна лепш за графік. Пасля гэтага змяняйце адну зменную за раз, інакш розніца страчвае сэнс.
IF OBJECT_ID('dbo.CommitProbe') IS NULL
CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;
Што дае асінхронная фіксацыя і колькі яна каштуе
Пры асінхроннай фіксацыі асноўная перастае чакаць пацверджання аддаленага замацавання, таму кругавы шлях сыходзіць з шляху фіксацыі. Затрымка фіксацыі падае, а другасная вольная адставаць на колькасць, якую ніхто не кантралюе. Гэта сапраўднае выпраўленне чакання і сапраўдная змена абяцанкі.
Кошт — гэта рашэнне пра кропку аднаўлення. Калі асноўная памірае, перш чым яе журнал дасягне мэты failover, якую вы сапраўды можаце выкарыстаць, перанос службы на асінхронную копію адкідвае транзакцыі, якія праграма ўжо паведаміла як зафіксаваныя. Ніводнае акно наладаў не падае гэта так, бо гэта бізнес-пытанне пра дапушчальную страту, а не параметр прадукцыйнасці. Запішыце дапушчальнае акно страт да інцыдэнту, а не падчас яго.
Узгодніце рэжым з тым, хто валодае данымі, пісьмова, разам з працэдурай failover для выпадку, калі пераважная мэта недаступная. Сінхроннасць у праектным дакуменце — не аперацыйная інструкцыя, а асінхроннасць — не ліцэнзія перастаць сачыць за чэргамі.
Выберыце выпраўленне, якое зможаце абараніць потым
Існуюць чатыры сумленныя варыянты. Скараціце пазбежныя кругавыя шляхі фіксацыі там, дзе семантыка праграмы дазваляе пакетную апрацоўку; выпраўце вымераны вузкі месца перадачы або сховішча, што можа азначаць хутчэйшы аб'ём журнала на другаснай, а не шырэйшую трубу; наблізьце рэпліку, каб кругавы шлях скараціўся; або паслабце палітыку абароны і прыміце шырэйшае акно страт. Кожны варыянт купляе затрымку, выдаткаваўшы нешта іншае, а чацвёрты выдаткавае надоўгасць. Назавіце выдатак, перш чым выбіраць.
Вырашайце, трымаючы перад сабой адначасова мэту затрымкі нагрузкі і патрабаванне надоўгасці, бо аптымізацыя аднаго ціха выдаткаўвае другое. Потым паўторна запусціце тую ж транзакцыю, якую вымералі да змены. Выпраўленне, якое не можа зрушыць гэты лік, — здагадка ў білеце на змену.
Захоўвайце паказанні да і пасля ў запісе пра змену. Інакш наступны чалавек, які ўбачыць павольны запіс, паўторыць расследаванне з пачатку і зноў пачне вінаваціць тунель.