നിങ്ങളുടെ സിൻക്രണസ് 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;

അസിൻക്രണസ് കമിറ്റ് എന്ത് വാങ്ങുന്നു, എന്ത് ചെലവാക്കുന്നു

അസിൻക്രണസ് കമിറ്റിൽ പ്രാഥമികം വിദൂര സ്ഥിരീകരണത്തിന്റെ സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കുന്നത് നിർത്തുന്നു, അതിനാൽ റൗണ്ട് ട്രിപ്പ് കമിറ്റ് പാതയിൽ നിന്ന് പുറത്തുപോകുന്നു. കമിറ്റ് ലേറ്റൻസി കുറയുന്നു, ദ്വിതീയ ആരും നിയന്ത്രിക്കാത്തത്ര പിന്നിലാകാൻ സ്വതന്ത്രമാകുന്നു. അത് കാത്തിരിപ്പിനുള്ള യഥാർത്ഥ പരിഹാരവും വാഗ്ദാനത്തിലെ യഥാർത്ഥ മാറ്റവുമാണ്.

വില വീണ്ടെടുക്കൽ പോയിന്റിനെക്കുറിച്ചുള്ള തീരുമാനമാണ്. പ്രാഥമികം തന്റെ ലോഗ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കാവുന്ന ഫെയിൽഓവർ ലക്ഷ്യത്തിൽ എത്തുന്നതിന് മുമ്പ് മരിച്ചാൽ, സേവനം അസിൻക്രണസ് പകർപ്പിലേക്ക് നീക്കുന്നത് അപ്ലിക്കേഷൻ ഇതിനകം കമിറ്റ് എന്ന് റിപ്പോർട്ട് ചെയ്ത ഇടപാടുകൾ വലിച്ചെറിയുന്നു. ഏതൊരു കോൺഫിഗറേഷൻ ഡയലോഗും അത് അങ്ങനെ അവതരിപ്പിക്കുന്നില്ല, കാരണം അത് സ്വീകാര്യമായ നഷ്ടത്തെക്കുറിച്ചുള്ള ബിസിനസ് ചോദ്യമാണ്, പ്രകടന ക്രമീകരണമല്ല. സഹിക്കാവുന്ന നഷ്ട വിൻഡോ സംഭവത്തിന് മുമ്പ് എഴുതുക, അതിനിടയിൽ അല്ല.

ഡാറ്റയുടെ ഉടമയുമായി മോഡിൽ രേഖാമൂലം യോജിക്കുക, ഇഷ്ടപ്പെട്ട ലക്ഷ്യം ലഭ്യമല്ലാത്ത സാഹചര്യത്തിലെ ഫെയിൽഓവർ നടപടിക്രമത്തോടൊപ്പം. ഡിസൈൻ ഡോക്യുമെന്റിലെ സിൻക്രണസ് ഓപ്പറേഷണൽ ഗൈഡല്ല, അസിൻക്രണസ് ക്യൂകൾ നിരീക്ഷിക്കുന്നത് നിർത്താനുള്ള ലൈസൻസുമല്ല.

പിന്നീട് സമർത്ഥിക്കാവുന്ന ഒരു പരിഹാരം തിരഞ്ഞെടുക്കുക

നാല് സത്യസന്ധമായ ഓപ്ഷനുകളുണ്ട്. അപ്ലിക്കേഷന്റെ സെമാന്റിക്സ് ബാച്ചിംഗ് അനുവദിക്കുന്നിടത്ത് ഒഴിവാക്കാവുന്ന കമിറ്റ് റൗണ്ട് ട്രിപ്പുകൾ വെട്ടിക്കുറയ്ക്കുക; നിങ്ങൾ അളന്ന ഗതാഗത അല്ലെങ്കിൽ സംഭരണ തടസ്സം പരിഹരിക്കുക, അത് ദ്വിതീയയിൽ വലിയ പൈപ്പിന് പകരം വേഗതയേറിയ ലോഗ് വോളിയം എന്നർത്ഥമാക്കാം; റൗണ്ട് ട്രിപ്പ് ചെറുതാകാൻ റെപ്ലിക്കയെ അടുപ്പിക്കുക; അല്ലെങ്കിൽ സംരക്ഷണ നയം അയച്ച് വിശാലമായ നഷ്ട വിൻഡോ സ്വീകരിക്കുക. ഓരോന്നും മറ്റെന്തോ ചെലവാക്കി ലേറ്റൻസി വാങ്ങുന്നു, നാലാമത്തേത് ഈട് ചെലവാക്കുന്നു. തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ചെലവ് പേരെടുത്ത് പറയുക.

ജോലിഭാരത്തിന്റെ ലേറ്റൻസി ലക്ഷ്യവും അതിന്റെ ഈട് ആവശ്യകതയും ഒരുമിച്ച് മുന്നിൽ വെച്ച് തീരുമാനിക്കുക, കാരണം ഒന്ന് മെച്ചപ്പെടുത്തുന്നത് മറ്റൊന്ന് നിശബ്ദമായി ചെലവാക്കുന്നു. തുടർന്ന് മാറ്റത്തിന് മുമ്പ് അളന്ന അതേ ഇടപാട് വീണ്ടും പ്രവർത്തിപ്പിക്കുക. ആ സംഖ്യ ചലിപ്പിക്കാനാവാത്ത പരിഹാരം മാറ്റ ടിക്കറ്റ് ധരിച്ച ഊഹമാണ്.

മാറ്റ രേഖയിൽ മുമ്പും ശേഷവുമുള്ള വായനകൾ സൂക്ഷിക്കുക. അല്ലാത്തപക്ഷം മന്ദഗതിയിലുള്ള എഴുത്ത് കാണുന്ന അടുത്ത വ്യക്തി അന്വേഷണം ആദ്യം മുതൽ ആവർത്തിച്ച് വീണ്ടും ടണലിനെ കുറ്റപ്പെടുത്തിത്തുടങ്ങുന്നു.