आपका सिंक्रोनस SQL कमिट VPN राउंड ट्रिप का इंतज़ार क्यों करता है

दूसरी साइट पर रेप्लिका जाने के बाद लिखने की विलंबता उछल गई, और टनल सबसे नया घटक है, इसलिए दोष उसी पर जाता है। टनल निर्दोष हो सकती है: सिंक्रोनस-कमिट उपलब्धता समूह के भीतर प्राथमिक दूरस्थ लॉग लेखन पूरा होने तक कमिट स्वीकार नहीं कर सकता, इसलिए हर लेन-देन एक राउंड ट्रिप चुकाता है, चाहे लिंक कितने भी मेगाबिट ले जा सके। थ्रूपुट प्रति सेकंड बाइट मापता है, विलंबता मापती है कि एक आदान-प्रदान में कितना समय लगता है, और कमिट को पूरा होने के लिए बस एक छोटा आदान-प्रदान चाहिए। एक संख्या ही बहस तय करती है: एक छोटे लेन-देन की कमिट अवधि, जो उपलब्धता डेटाबेस के भीतर और फिर उसी इंस्टेंस पर स्थानीय तालिका के सामने मापी जाती है।

प्राथमिक वास्तव में किसका इंतज़ार करता है

सिंक्रोनस कमिट के तहत प्राथमिक कमिट की स्वीकृति रोके रखता है जब तक साथी पुष्टि न कर दे कि उसके लॉग रिकॉर्ड स्थायी रूप से लिखे गए हैं। स्थायी का अर्थ है द्वितीयक के लेन-देन लॉग में टिकाऊ रूप से लिखा गया, उसके डेटा पृष्ठों में दोबारा नहीं चलाया गया। रीडू मिनटों पीछे रह सकता है, प्राथमिक की कमिट में एक मिलीसेकंड भी जोड़े बिना।

उपलब्धता मोड पर Microsoft का दस्तावेज़ उस हैंडशेक को समझाता है और बताता है कि साथी के बाहर होने पर प्लेटफ़ॉर्म क्या करता है। सिंक्रोनस के रूप में चिह्नित रेप्लिका इंतज़ार का नियम है, हर कमिट के लिए स्वस्थ दूरस्थ प्रति होने का स्थायी वादा नहीं। डिस्कनेक्टेड पथ अलग से परिभाषित है, और वह सिर्फ़ यह नहीं है कि कमिट विफल हो जाए।

इसलिए आप जो इंतज़ार देखते हैं वह एक योग है: लॉग परिवहन, दोनों होस्ट पर शेड्यूलिंग और दूरस्थ संग्रहण में लेखन। संतृप्त लॉग वॉल्यूम वाला द्वितीयक ऐसा समय जोड़ता है जो कोई गति परीक्षण नहीं दिखाएगा। शिकायत में VPN का नाम आने पर वह डिस्क शायद ही मापी जाती है।

बैंडविड्थ राउंड-ट्रिप विलंब नहीं है

गति परीक्षण पथ को थोड़ी देर के लिए भर देता है और दर बताता है। कमिट कुछ अधिक संकीर्ण माँगता है: एक छोटे संदेश को दूसरी ओर पहुँचने, सहेजे जाने और वापस आने में कितना समय लगता है। पथ की लंबाई, कतार और पैकेट हानि वह संख्या तय करते हैं, और प्रदाता सीमा बढ़ाने पर इनमें से कोई बेहतर नहीं होता।

इसलिए «तेज़» टनल कई छोटे अनुक्रमिक लेन-देनों से बने लेखन-भारी कार्यभार में दिखने वाला दंड जोड़ सकती है। वही कुल बाइट हज़ार कमिट में बाँटे जाने पर राउंड ट्रिप हज़ार बार चुकाती है; एक बड़ा स्थानांतरण उसे एक बार चुकाता है।

नेटवर्क मालिक से प्रतिनिधि भार के तहत रेप्लिका मार्ग पर ही विलंब और हानि मापने को कहें। कार्यालय के लैपटॉप से 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;

पहला परिणाम लॉग परिवहन को रीडू से अलग करता है। log_send_queue_size बढ़ना जबकि redo_queue_size सपाट रहना मतलब लॉग नहीं पहुँचा; उल्टा मतलब वह पहुँचा और रीप्ले पीछे है। सिर्फ़ पहला मामला कमिट पथ पर बैठता है।

दूसरा परिणाम पुष्टि करता है कि कौन-सी रेप्लिकाएँ वास्तव में वैसी कॉन्फ़िगर हैं जैसा आप मानते हैं, क्योंकि पिछली घटना में बदला गया मोड अक्सर बदला और बिना दस्तावेज़ के रह जाता है। समूह के डिफ़ॉल्ट के बजाय वह पंक्ति पढ़ें जो आपके लिए मायने रखती है: availability_mode_desc और failover_mode_desc प्रति रेप्लिका हैं। secondary_lag_seconds केवल SQL Server 2016 और बाद में मौजूद है, इसलिए पुराना बिल्ड आपको सिर्फ़ सेंड क्यू और रीडू कॉलम के साथ छोड़ता है।

फिर डैशबोर्ड के औसत पर भरोसा करने के बजाय एक प्रतिनिधि लेखन मापें। नीचे का ब्लॉक उपलब्धता डेटाबेस में चलाएँ, फिर उसी इंस्टेंस पर समूह से बाहर के डेटाबेस में उसी तालिका आकार के सामने फिर चलाएँ। दोनों अवधियों का अंतर दूरस्थ लॉग की मोटी कीमत है, और नेटवर्क टीम के साथ बहस में यह ग्राफ़ से कहीं बेहतर टिकता है। उसके बाद एक बार में एक चर बदलें, वरना अंतर का कोई अर्थ नहीं रहता।

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;

असिंक्रोनस कमिट क्या खरीदता है, और क्या कीमत देता है

असिंक्रोनस कमिट के साथ प्राथमिक दूरस्थ स्थायीकरण की पुष्टि का इंतज़ार करना बंद कर देता है, इसलिए राउंड ट्रिप कमिट पथ से हट जाती है। कमिट विलंबता घटती है और द्वितीयक उतना पीछे रहने को स्वतंत्र है जितना कोई नियंत्रित नहीं करता। यह इंतज़ार का असली उपाय है और वादे में असली बदलाव है।

कीमत रिकवरी-पॉइंट का फ़ैसला है। अगर प्राथमिक अपने लॉग के उस फेलओवर लक्ष्य तक पहुँचने से पहले मर जाता है जिसे आप सचमुच इस्तेमाल कर सकते हैं, तो सेवा को असिंक्रोनस प्रति पर ले जाना उन लेन-देनों को फेंक देता है जिन्हें एप्लिकेशन पहले ही कमिट बता चुका था। कोई कॉन्फ़िगरेशन संवाद इसे ऐसे नहीं दिखाता, क्योंकि यह स्वीकार्य हानि का कारोबारी सवाल है, प्रदर्शन सेटिंग नहीं। सह्य हानि विंडो घटना से पहले लिखें, उसके दौरान नहीं।

डेटा के मालिक के साथ मोड पर सहमति बनाएँ, लिखित में, पसंदीदा लक्ष्य के अनुपलब्ध होने की स्थिति के फेलओवर प्रक्रिया के साथ। डिज़ाइन दस्तावेज़ में सिंक्रोनस ऑपरेशनल गाइड नहीं है, और असिंक्रोनस कतारों को देखना बंद करने का लाइसेंस नहीं है।

ऐसा उपाय चुनें जिसे बाद में आप उचित ठहरा सकें

चार ईमानदार विकल्प हैं। जहाँ एप्लिकेशन का अर्थशास्त्र बैचिंग की अनुमति दे वहाँ बचाई जा सकने वाली कमिट राउंड ट्रिप काटें; आपने जो परिवहन या संग्रहण अड़चन मापी है उसे ठीक करें, जिसका मतलब द्वितीयक पर बड़े पाइप के बजाय तेज़ लॉग वॉल्यूम हो सकता है; रेप्लिका को पास लाएँ ताकि राउंड ट्रिप सिकुड़े; या सुरक्षा नीति ढीली करें और चौड़ी हानि विंडो स्वीकारें। हर एक विलंबता दूसरा कुछ ख़र्च करके खरीदता है, और चौथा टिकाऊपन ख़र्च करता है। चुनने से पहले ख़र्च का नाम लें।

कार्यभार के विलंबता लक्ष्य और उसकी टिकाऊपन आवश्यकता को एक साथ सामने रखकर फ़ैसला करें, क्योंकि एक को अनुकूलित करना दूसरे को चुपचाप ख़र्च करता है। फिर बदलाव से पहले मापा गया वही लेन-देन फिर चलाएँ। जो उपाय उस संख्या को हिला नहीं सकता वह बदलाव टिकट पहने एक अनुमान है।

बदलाव रिकॉर्ड में पहले और बाद के पाठ रखें। वरना धीमा लेखन देखने वाला अगला व्यक्ति जाँच शुरू से दोहराता है और फिर टनल को दोष देने से शुरू करता है।