तुमचा सिंक्रोनस 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;

असिंक्रोनस कमिट काय विकत घेते, आणि काय खर्च करते

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

किंमत पुनर्प्राप्ती बिंदूचा निर्णय आहे। प्राथमिक आपला लॉग खरोखर वापरता येईल अशा फेलओवर लक्ष्यापर्यंत पोहोचण्यापूर्वी मेला, तर सेवा असिंक्रोनस प्रतीवर हलवल्यास अॅप्लिकेशनने आधीच कमिट म्हणून कळवलेले व्यवहार टाकून दिले जातात। कोणताही संरचना संवाद हे असे मांडत नाही, कारण हा स्वीकार्य हानीबद्दलचा व्यावसायिक प्रश्न आहे, कार्यक्षमता सेटिंग नाही। सहन करण्यायोग्य हानीची खिडकी घटनेपूर्वी लिहा, तिच्या दरम्यान नाही।

डेटाच्या मालकाशी मोडवर लिखित स्वरूपात सहमती द्या, पसंतीचे लक्ष्य उपलब्ध नसल्याच्या प्रकरणासाठीच्या फेलओवर प्रक्रियेसह। रचना दस्तऐवजातील सिंक्रोनस हे कार्यचालन पुस्तिका नाही, आणि असिंक्रोनस रांगा पाहणे थांबवण्याचा परवाना नाही।

नंतर ज्याचे तुम्ही समर्थन करू शकाल असे उपाय निवडा

चार प्रामाणिक पर्याय आहेत। अॅप्लिकेशनची अर्थशास्त्र बॅचिंगला परवानगी देत असेल तिथे टाळता येणारे कमिट राउंड ट्रिप कापा; तुम्ही मोजलेला वाहतूक किंवा साठवणी अडथळा दुरुस्त करा, ज्याचा अर्थ दुय्यमवर मोठ्या पाईपऐवजी वेगवान लॉग व्हॉल्यूम असू शकतो; राउंड ट्रिप आकुंचन पावण्यासाठी रेप्लिका जवळ आणा; किंवा संरक्षण धोरण सैल करा आणि विस्तृत हानी खिडकी स्वीकारा। प्रत्येकजण विलंब दुसरे काही खर्च करून विकत घेतो, आणि चौथा टिकाऊपणा खर्च करतो। निवडण्यापूर्वी खर्चाचे नाव घ्या।

कामाच्या भाराचे विलंब लक्ष्य आणि त्याची टिकाऊपणाची गरज एकाच वेळी समोर ठेवून निर्णय घ्या, कारण एक अनुकूल करणे दुसरे शांतपणे खर्च करते। नंतर बदलापूर्वी मोजलेला तोच व्यवहार पुन्हा चालवा। ती संख्या हलवू न शकणारा उपाय बदल तिकिट घातलेला अंदाज आहे।

बदल नोंदीत आधीची आणि नंतरची वाचने ठेवा। नाहीतर संथ लेखन पाहणारा पुढचा माणूस तपासणी सुरुवातीपासून पुन्हा करतो आणि पुन्हा टनेलला दोष देण्यापासून सुरुवात करतो।