તમારી સિંક્રોનસ 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;

એસિંક્રોનસ કમિટ શું ખરીદે છે, અને શું ખર્ચે છે

એસિંક્રોનસ કમિટ સાથે પ્રાથમિક દૂરના સ્થિરીકરણની પુષ્ટિની રાહ જોવાનું બંધ કરે છે, તેથી રાઉન્ડ ટ્રિપ કમિટ માર્ગમાંથી નીકળી જાય છે. કમિટ લેટન્સી ઘટે છે અને ગૌણ એટલા પ્રમાણમાં પાછળ રહેવા મુક્ત થાય છે જે કોઈ નિયંત્રિત કરતું નથી. તે રાહ માટે સાચો ઉપાય છે અને વચનમાં સાચો ફેરફાર છે.

કિંમત પુનઃપ્રાપ્તિ બિંદુનો નિર્ણય છે. જો પ્રાથમિક તેના લોગ સાચે જ વાપરી શકાય તેવા ફેઇલઓવર લક્ષ્ય સુધી પહોંચે તે પહેલાં મરી જાય, તો સેવાને એસિંક્રોનસ નકલ પર ખસેડવાથી એ વ્યવહારો ફેંકાય છે જે એપ્લિકેશને પહેલેથી કમિટ તરીકે જણાવ્યા હતા. કોઈ કન્ફિગરેશન સંવાદ તેને એ રીતે રજૂ કરતો નથી, કારણ કે તે સ્વીકાર્ય નુકસાન વિશેનો વ્યવસાયિક પ્રશ્ન છે, પ્રદર્શન સેટિંગ નથી. સહન કરી શકાય તેવી નુકસાન વિન્ડો ઘટનાના પહેલાં લખો, તે દરમિયાન નહીં.

ડેટાના માલિક સાથે મોડ પર સહમત થાઓ, લેખિતમાં, પસંદગીના લક્ષ્ય ઉપલબ્ધ ન હોય તે કિસ્સા માટેના ફેઇલઓવર પ્રક્રિયા સાથે. ડિઝાઇન દસ્તાવેજમાં સિંક્રોનસ ઓપરેશનલ માર્ગદર્શિકા નથી, અને એસિંક્રોનસ કતારો જોવાનું બંધ કરવાનું લાઇસન્સ નથી.

પછી જેનું તમે બચાવ કરી શકો તેવો ઉપાય પસંદ કરો

ચાર પ્રામાણિક વિકલ્પો છે. જ્યાં એપ્લિકેશનનું અર્થશાસ્ત્ર બેચિંગની મંજૂરી આપે ત્યાં ટાળી શકાય તેવી કમિટ રાઉન્ડ ટ્રિપ કાપો; તમે માપેલો પરિવહન કે સ્ટોરેજ અડચણ સુધારો, જેનો અર્થ ગૌણ પર મોટા પાઇપને બદલે ઝડપી લોગ વોલ્યુમ હોઈ શકે; રેપ્લિકાને નજીક લાવો જેથી રાઉન્ડ ટ્રિપ સંકોચાય; અથવા સુરક્ષા નીતિ ઢીલી કરો અને વિશાળ નુકસાન વિન્ડો સ્વીકારો. દરેક લેટન્સી બીજું કંઈક ખર્ચીને ખરીદે છે, અને ચોથો ટકાઉપણું ખર્ચે છે. પસંદ કરતા પહેલાં ખર્ચને નામ આપો.

કામભારનું લેટન્સી લક્ષ્ય અને તેની ટકાઉપણાની જરૂરિયાત એકસાથે સામે રાખીને નિર્ણય લો, કારણ કે એકને અનુકૂળ કરવું બીજાને શાંતિથી ખર્ચે છે. પછી ફેરફાર પહેલાં માપેલો તે જ વ્યવહાર ફરી ચલાવો. જે ઉપાય તે આંકડાને હલાવી શકતો નથી તે ફેરફાર ટિકિટ પહેરેલી અટકળ છે.

ફેરફાર રેકોર્ડમાં પહેલાં-પછીના વાંચન રાખો. નહીંતર ધીમું લેખન જોનાર આગળનો વ્યક્તિ તપાસ શરૂઆતથી પુનરાવર્તિત કરે છે અને ફરી ટનલને દોષ આપવાથી શરૂ કરે છે.