വേഗമേറിയ VPN ഇപ്പോഴും സമകാലിക SQL കമ്മിറ്റിനെ മന്ദഗതിയിലാക്കുന്നതെന്തുകൊണ്ട്

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

പ്രാഥമികത്തിലെ കാത്തിരിപ്പ് തരത്തിൽ നിന്ന് തുടങ്ങുക

വിദൂര പകർപ്പിൽ കാത്തിരിക്കുന്ന എഴുത്ത് CPU അല്ലെങ്കിൽ ലോക്ക് കാത്തിരിപ്പല്ല, ലോഗുമായി ബന്ധപ്പെട്ട കാത്തിരിപ്പായി കാണപ്പെടുന്നു, ഇടപാടിന്റെ ദൈർഘ്യം വരികളുടെ എണ്ണത്തിന് പകരം പോയിവരവിനെ പിന്തുടരുന്നു. ഒട്ടേറെ ചെറിയ കമ്മിറ്റുകൾ ഇത് വ്യക്തമാക്കുന്നു, കാരണം ഓരോന്നും യാത്ര വെവ്വേറെ നൽകുന്നു. ഒരു വലിയ കൂട്ട പ്രവർത്തനം അതേ ചെലവ് ഒരു നീണ്ട സ്വീകരണത്തിനുള്ളിൽ ഒളിപ്പിക്കുന്നു.

ലിങ്കിനെക്കുറിച്ച് എന്തെങ്കിലും അനുമാനിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ ജോലിഭാരം കമ്മിറ്റ് ആവൃത്തി അനുസരിച്ച് അടുക്കുക.

നെറ്റ്വർക്ക് വായിക്കുന്നതിന് മുമ്പ് പകർപ്പിന്റെ അവസ്ഥ വായിക്കുക. പ്രധാനമായ കൗണ്ടറുകൾ അയയ്ക്കൽ ക്യൂ, redo ക്യൂ, സമകാലികീകരണ അവസ്ഥ എന്നിവയാണ്, അവ ഒരുമിച്ച് ദ്വിതീയം ഒപ്പമെത്തുന്നുണ്ടോ പിന്നിലാകുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. വളരുന്ന അയയ്ക്കൽ ക്യൂ ഗതാഗതത്തെ സൂചിപ്പിക്കുന്നു, വളരുന്ന redo ക്യൂ ദ്വിതീയത്തിന്റെ സ്വന്തം ജോലിയെയോ സംഭരണത്തെയോ സൂചിപ്പിക്കുന്നു. ഇവ വ്യത്യസ്ത നന്നാക്കലുകളാണ്, ബാൻഡ്വിഡ്ത്ത് ചേർത്താൽ ഒന്നും മെച്ചപ്പെടുന്നില്ല.

സ്വീകരണം ദ്വിതീയത്തിലേക്ക് പിന്തുടരുക

സമകാലിക കമ്മിറ്റിൽ, കമ്മിറ്റ് പൂർത്തിയായി പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ് ബന്ധപ്പെട്ട ലോഗ് ദ്വിതീയത്തിൽ കടുപ്പിച്ചുവെന്ന സ്ഥിരീകരണത്തിനായി പ്രാഥമികം കാത്തിരിക്കുന്നു. കടുപ്പിച്ചത് എന്നാൽ ലോഗിൽ ശാശ്വതം, ഡാറ്റ പേജുകളിൽ വീണ്ടും പ്രവർത്തിപ്പിച്ചതല്ല. ഈ വ്യത്യാസമാണ് സമകാലിക ദ്വിതീയം redo-യിൽ പിന്നിലായാലും കടുപ്പിക്കൽ സ്ഥിരീകരിക്കുന്നതിന് കാരണം.

പാത ക്രമത്തിൽ സഞ്ചരിച്ച് മൊത്തത്തിന് പകരം ഓരോ ഘട്ടവും അളക്കുക. ലോഗ് റെക്കോർഡുകൾ ഗതാഗതത്തിലൂടെ പോകുന്നു, ദ്വിതീയം അവ എഴുതി ഫ്ലഷ് ചെയ്യുന്നു, സ്വീകരണം അതേ പാതയിലൂടെ തിരികെ വരുന്നു. ഗതാഗത കാലതാമസം, ദ്വിതീയത്തിന്റെ ഷെഡ്യൂളിംഗ്, ദ്വിതീയത്തിന്റെ ലോഗ്-ഡിസ്ക് ലാറ്റൻസി എല്ലാം ആകെത്തുകയിൽ ചേരുന്നു, ആദ്യത്തേത് മാത്രം നെറ്റ്വർക്ക് ഉടമയുടേതാണ്. ലോഗ് വോളിയം മറ്റെന്തെങ്കിലും കൊണ്ട് പൂരിതമായ ദ്വിതീയം, ലിങ്ക് നിഷ്ക്രിയമായിരിക്കുമ്പോഴും ഓരോ കമ്മിറ്റും നീട്ടാം.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

ശാന്തമായ ഉച്ചയ്ക്ക് ഒരിക്കലല്ല, പ്രതിനിധീകരണ എഴുത്തിന് മുമ്പും ശേഷവും ആ സ്നാപ്പ്ഷോട്ട് എടുക്കുക. കമ്മിറ്റ് കാത്തിരിക്കുമ്പോൾ ഏത് ക്യൂ നീങ്ങി എന്ന് വ്യത്യാസം പറയുന്നു.

ലിങ്കല്ല, പാത അളക്കുക

ത്രൂപുട്ട് പരിശോധന നിങ്ങളുടെ പകർപ്പുകളല്ലാത്ത രണ്ട് പോയിന്റുകൾക്കിടയിലെ ശേഷി, നിങ്ങളുടെ ജോലിയല്ലാത്ത ഭാരത്തിന് കീഴിൽ അളക്കുന്നു. യഥാർത്ഥ ട്രാഫിക് നടക്കുമ്പോൾ യഥാർത്ഥ പകർപ്പ് പാതയിലുടനീളം കാലതാമസവും നഷ്ടവും ഇരുദിശകളിലും നെറ്റ്വർക്ക് ഉടമയോട് ചോദിക്കുക. ഇവിടെ നഷ്ടം ശേഷിയെക്കാൾ പ്രധാനമാണ്, കാരണം നഷ്ടപ്പെട്ട സെഗ്മെന്റിന് പുനഃപ്രക്ഷേപണ ചെലവുണ്ട്, ഓരോ കമ്മിറ്റും ഒരു സ്വീകരണത്തിനായി കാത്തിരിക്കുന്നു. ഡൗൺലോഡ് പരിശോധനയിൽ മികച്ചതായി തോന്നുന്ന ലിങ്കും സംസാരിക്കുന്ന കമ്മിറ്റ് മാതൃകയ്ക്ക് അനുയോജ്യമല്ലായിരിക്കാം.

അളക്കുമ്പോൾ ഡാറ്റാബേസ് ഗതാഗത സുരക്ഷയും പ്രവേശന നിയന്ത്രണങ്ങളും അതേപടി സൂക്ഷിക്കുക. പാത അളക്കുന്നത് അവ ഒഴിവാക്കാനുള്ള കാരണമല്ല.

സമയങ്ങളെ അന്തർജ്ഞാനത്തിന് പകരം കൗണ്ടറുകളുമായി ബന്ധിപ്പിക്കുക. അയയ്ക്കൽ ക്യൂ ശൂന്യമായി നിൽക്കുകയും കമ്മിറ്റ് ഇപ്പോഴും കാത്തിരിക്കുകയും ചെയ്താൽ, കാലതാമസം സ്വീകരണത്തിലോ ദ്വിതീയത്തിന്റെ ഫ്ലഷിലോ ആണ്. അയയ്ക്കൽ ക്യൂ സ്ഥിരമായി വളർന്നാൽ, പരിധി ഗതാഗതമോ ശേഷിയോ ആണ്. ഏത് നിരീക്ഷണം അനുമാനത്തെ പിന്തുണച്ചു എന്ന് രേഖപ്പെടുത്തുക, അടുത്തയാൾ വാദത്തിന് പകരം അളവ് ആവർത്തിക്കാൻ.

അസമകാലിക മോഡ് യഥാർത്ഥത്തിൽ മാറ്റുന്നത്

അസമകാലിക കമ്മിറ്റ് ദ്വിതീയത്തിന്റെ കടുപ്പിക്കൽ സ്വീകരണത്തിനുള്ള കാത്തിരിപ്പ് നീക്കുന്നു, അതിനാൽ എഴുത്തുകൾ വേഗത്തിലാകുന്നു, അതിനാൽ നിങ്ങളുടെ ദൃഢതാ നിലപാട് മാറുന്നു. ആ വിദൂര സ്ഥിരീകരണമില്ലാതെ പ്രാഥമികം ഇടപാട് സ്ഥിരീകരിക്കുന്നു. തുടർന്ന് ദ്വിതീയം പിന്നിലാകാൻ അനുവദിക്കുന്നു, ആ പിന്നിലാകൽ തന്നെയാണ് വിഷയം.

ലോഗ് ഉപയോഗയോഗ്യമായ ഫെയിൽഓവർ ലക്ഷ്യത്തിൽ എത്തുന്നതിന് മുമ്പ് പ്രാഥമികം നഷ്ടപ്പെട്ടാൽ, ആ പകർപ്പിലേക്ക് സേവനം നിർബന്ധമായി മാറ്റുന്നത് അപ്ലിക്കേഷനോട് കമ്മിറ്റ് ചെയ്തതായി അറിയിച്ച ഇടപാടുകൾ വലിച്ചെറിയുന്നു.

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