तपाईंको सिंक्रोनस 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;

असिंक्रोनस कमिटले के किन्छ, र के खर्च गर्छ

असिंक्रोनस कमिटसँग प्राथमिकले दूरको स्थायीकरणको पुष्टिको प्रतीक्षा गर्न छोड्छ, त्यसैले राउन्ड ट्रिप कमिट मार्गबाट हट्छ। कमिट विलम्बता घट्छ र द्वितीयक कसैले नियन्त्रण नगर्ने मात्रामा पछाडि रहन स्वतन्त्र हुन्छ। त्यो प्रतीक्षाको साँचो उपाय र वाचामा साँचो परिवर्तन हो।

मूल्य पुनःप्राप्ति बिन्दुको निर्णय हो। प्राथमिक आफ्नो लग साँच्चै प्रयोग गर्न सकिने फेलओभर लक्ष्यसम्म पुग्नुअघि मर्यो भने, सेवा असिंक्रोनस प्रतिलिपिमा सार्दा एप्लिकेसनले पहिले नै कमिट भनी जनाएका कारोबार फ्याँकिन्छन्। कुनै कन्फिगरेसन संवादले त्यसो देखाउँदैन, किनकि त्यो स्वीकार्य हानिबारे व्यावसायिक प्रश्न हो, कार्यसम्पादन सेटिङ होइन। सह्य हानि विन्डो घटनाअघि लेख्नुहोस्, त्यसको क्रममा होइन।

डेटाको मालिकसँग मोडमा लिखित रूपमा सहमति गर्नुहोस्, रुचाइएको लक्ष्य उपलब्ध नहुने अवस्थाको फेलओभर प्रक्रियासहित। डिजाइन कागजातमा सिंक्रोनस सञ्चालन निर्देशिका होइन, र असिंक्रोनस लाइनहरू हेर्न छोड्ने इजाजतपत्र होइन।

पछि तपाईंले बचाउन सक्ने उपाय छान्नुहोस्

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

कामको बोझको विलम्बता लक्ष्य र त्यसको टिकाउपन आवश्यकता एकैचोटि सामु राखेर निर्णय गर्नुहोस्, किनकि एउटा अनुकूल बनाउँदा अर्को चुपचाप खर्च हुन्छ। त्यसपछि परिवर्तनअघि नापेको त्यही कारोबार फेरि चलाउनुहोस्। त्यो संख्या हल्लाउन नसक्ने उपाय परिवर्तन टिकट लगाएको अनुमान हो।

परिवर्तन रेकर्डमा अघि र पछिका पाठ राख्नुहोस्। नत्र ढिलो लेखन देख्ने अर्को व्यक्तिले जाँच सुरुदेखि दोहोर्याउँछ र फेरि टनेललाई दोष दिन थाल्छ।