Nima uchun sinxron SQL commit'ingiz VPN sayohatini kutadi

Replika ikkinchi saytga ko'chirilgandan so'ng yozish kechikishi sakrab ketdi va tunnel eng yangi komponent bo'lgani uchun ayb unga yuklanadi. Tunnel begunoh bo'lishi mumkin: sinxron commit'li mavjudlik guruhi ichida asosiy replika uzoq log yozuvi tugamaguncha commit'ni tasdiqlay olmaydi, shuning uchun har bir tranzaksiya borib-kelishni to'laydi, havola qancha megabit tashisa ham. O'tkazuvchanlik soniyasiga baytlarni o'lchaydi, kechikish bitta almashinuv qancha vaqt olishini o'lchaydi va commit tugashi uchun faqat bitta kichik almashinuv kerak. Bitta raqam bahsni hal qiladi: kichik tranzaksiyaning commit davomiyligi, mavjudlik ma'lumotlar bazasi ichida va keyin o'sha instansiyadagi mahalliy jadvalga qarshi qayta o'lchangan.

Asosiy replika aslida nimani kutadi

Sinxron commit ostida asosiy replika sherik o'z log yozuvlari qotirilganini tasdiqlamaguncha commit tasdig'ini ushlab turadi. Qotirilgan ikkilamchining tranzaksiya logiga barqaror yozilganini bildiradi, uning ma'lumot sahifalarida qayta ishga tushirilmagan. Redo asosiy replikaning commit'iga bir millisekund ham qo'shmasdan daqiqalar ortda qolishi mumkin.

Microsoft'ning mavjudlik rejimlari haqidagi hujjati bu qo'l berib ko'rishishni tushuntiradi va sherik chiqib ketganda platforma nima qilishini tavsiflaydi. Sinxron deb belgilangan replika kutish haqidagi qoida, har bir commit uchun sog'lom uzoq nusxa borligi haqidagi doimiy va'da emas. Uzilgan yo'l alohida belgilangan va bu shunchaki commit muvaffaqiyatsiz bo'lishi emas.

Demak, siz ko'rayotgan kutish yig'indi: log tashish, ikkala hostda rejalashtirish va uzoq xotiraga yozish. To'yingan log hajmli ikkilamchi hech qanday tezlik sinovi ko'rsatmaydigan vaqtni qo'shadi. Shikoyat VPNni tilga olganda o'sha disk kamdan-kam o'lchanadi.

O'tkazuvchanlik borib-kelish kechikishi emas

Tezlik sinovi yo'lni qisqa vaqt suv bosadi va tezlikni bildiradi. Commit torroq narsani so'raydi: kichik xabar narigi tomonga yetishi, saqlanishi va qaytishi uchun qancha vaqt ketadi. Yo'l uzunligi, navbatlar va paket yo'qotilishi bu raqamni belgilaydi va provayder shiftni ko'targanda ularning hech biri yaxshilanmaydi.

Shuning uchun «tez» tunnel ko'plab kichik ketma-ket tranzaksiyalardan qurilgan yozishga og'ir ish yukiga ko'rinadigan jarima qo'shishi mumkin. Xuddi shu umumiy bayt ming commit'ga bo'linsa, borib-kelishni ming marta to'laydi; bitta ommaviy uzatish uni bir marta to'laydi.

Tarmoq egasidan vakillik yuki ostida replika yo'lining o'zida kechikish va yo'qotishni o'lchashni so'rang. Ofis noutbukidan VPN darvozasiga ping yoki yaqin tugunga tezlik sinovi log haqiqatan yuradigan yo'lga deyarli hech narsa yuklamaydi. O'lchov oynasi yozish sekin bo'lgan soatlarga to'g'ri kelishini ta'minlang.

Biror narsani o'zgartirishdan oldin replika holatini o'qing

Instansiyalar o'zlari haqida bildirgan narsadan boshlang, chunki ikki tomon sheriklik qanchalik sog'lom ekani borasida kelisha olmasligi mumkin va boshqaruv paneli o'rtachasi qaysi navbat harakatlanayotganini yashiradi. Quyidagi so'rovlar turli savollarga javob beradi: biri har bir ma'lumotlar bazasi bo'yicha replikatsiya holatini o'qiydi, ikkinchisi har bir replika qanday sozlanganini o'qiydi. Rejimga tegishdan oldin ikkalasini ham ishga tushiring.

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;

Birinchi natija log tashishni redodan ajratadi. log_send_queue_size ko'tarilib, redo_queue_size tekis tursa, log kelmagan; aksi kelsa, u kelgan va qayta ijro ortda qolgan. Commit yo'lida faqat birinchi holat o'tiradi.

Ikkinchi natija qaysi replikalar haqiqatan siz taxmin qilganday sozlanganini tasdiqlaydi, chunki avvalgi hodisa paytida o'zgartirilgan rejim o'zgartirilgan va hujjatsiz qolishga moyil. Guruh standarti o'rniga sizga muhim qatorni o'qing: availability_mode_desc va failover_mode_desc har bir replika uchun. secondary_lag_seconds faqat SQL Server 2016 va undan keyingilarida mavjud, shuning uchun eski build sizga faqat yuborish navbati va redo ustunlarini qoldiradi.

Keyin boshqaruv paneli o'rtachasiga ishonish o'rniga vakillik yozuvini o'lchang. Quyidagi blokni mavjudlik ma'lumotlar bazasida ishga tushiring, keyin uni o'sha instansiyadagi guruhdan tashqari ma'lumotlar bazasida xuddi shu jadval shakliga qarshi qayta ishga tushiring. Ikki davomiylik orasidagi farq uzoq logning qo'pol narxi va tarmoq jamoasi bilan bahsda u grafikdan ancha yaxshi turib beradi. Shundan keyin bir vaqtda bitta o'zgaruvchini o'zgartiring, aks holda farq ma'nosini yo'qotadi.

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;

Asinxron commit nima sotib oladi va qancha turadi

Asinxron commit bilan asosiy replika uzoq qotirish tasdig'ini kutishni to'xtatadi, shuning uchun borib-kelish commit yo'lidan chiqadi. Commit kechikishi tushadi va ikkilamchi hech kim nazorat qilmaydigan miqdorda ortda qolishga erkin bo'ladi. Bu kutishning haqiqiy tuzatishi va va'dadagi haqiqiy o'zgarish.

Narx — tiklash nuqtasi haqidagi qaror. Agar asosiy replika o'z logi haqiqatan ishlata oladigan nosozlikda o'tish maqsadiga yetmasdan o'lsa, xizmatni asinxron nusxaga ko'chirish ilova allaqachon commit deb bildirgan tranzaksiyalarni tashlab yuboradi. Hech qanday sozlash oynasi buni shunday ko'rsatmaydi, chunki bu qabul qilinadigan yo'qotish haqidagi biznes savoli, unumdorlik sozlamasi emas. Toqat qilinadigan yo'qotish oynasini hodisadan oldin yozing, uning davomida emas.

Rejimni ma'lumot egasi bilan yozma ravishda kelishing, afzal maqsad mavjud bo'lmagan holat uchun nosozlikda o'tish tartibi bilan birga. Loyiha hujjatidagi sinxron operatsion qo'llanma emas, asinxron esa navbatlarni kuzatishni to'xtatish uchun litsenziya emas.

Keyin himoya qila oladigan tuzatishni tanlang

To'rtta halol variant bor. Ilova semantikasi to'plamga ruxsat bergan joyda qochish mumkin bo'lgan commit borib-kelishlarini qirqing; o'lchagan tashish yoki xotira to'sig'ini tuzating, bu ikkilamchida kattaroq quvur o'rniga tezroq log hajmini anglatishi mumkin; borib-kelish qisqarishi uchun replikani yaqinlashtiring; yoki himoya siyosatini yumshatib, kengroq yo'qotish oynasini qabul qiling. Har biri kechikishni boshqa narsani sarflab sotib oladi, to'rtinchisi esa chidamlilikni sarflaydi. Tanlashdan oldin sarfni nomlang.

Ish yukining kechikish maqsadi va uning chidamlilik talabini bir vaqtda ko'z oldingizda turib qaror qiling, chunki birini optimallashtirish ikkinchisini jimgina sarflaydi. Keyin o'zgartirishdan oldin o'lchagan o'sha tranzaksiyani qayta ishga tushiring. Bu raqamni qimirlata olmaydigan tuzatish — o'zgartirish chiptasini kiygan taxmin.

O'zgartirish yozuvida oldingi va keyingi o'qishlarni saqlang. Aks holda sekin yozishni ko'rgan keyingi odam tekshiruvni boshidan takrorlaydi va yana tunnelni ayblashdan boshlaydi.