Miért vár a szinkron SQL-véglegesítés a VPN oda-vissza útjára

Az írási latencia megugrott, miután egy replika átkerült a második telephelyre, és az alagút a legújabb komponens, így azt hibáztatják. Az alagút ártatlan lehet: egy szinkron véglegesítésű rendelkezésre állási csoporton belül az elsődleges nem nyugtázhat véglegesítést, amíg egy távoli naplóírás be nem fejeződik, így minden tranzakció fizet egy oda-vissza utat, akárhány megabitet is tud szállítani a kapcsolat. Az áteresztőképesség bájt/másodpercben mér, a latencia azt méri, mennyi ideig tart egy csere, és egy véglegesítésnek csak egyetlen kis cserére van szüksége a befejezéshez. Egyetlen szám dönti el a vitát: egy kis tranzakció véglegesítésének időtartama, a rendelkezésre állási adatbázison belül mérve, majd újra egy helyi tábla ellen ugyanazon a példányon.

Mire vár valójában az elsődleges

Szinkron véglegesítésnél az elsődleges visszatartja a véglegesítés nyugtázását, amíg a partner meg nem erősíti, hogy naplórekordjai megkeményítettek. A megkeményített tartósan a másodlagos tranzakciós naplójába írt rekordot jelent, nem az adatlapjain újrajátszottat. A redo percekkel lemaradhat anélkül, hogy egyetlen ezredmásodpercet is hozzáadna az elsődleges véglegesítéséhez.

A Microsoft dokumentációja a rendelkezésre állási módokról végigvezet ezen a kézfogáson, és leírja, mit tesz a platform, amikor egy partner kiesik. A szinkronként megjelölt replika a várakozásról szóló szabály, nem állandó ígéret arra, hogy minden véglegesítéshez létezik egészséges távoli másolat. A megszakított útvonal külön van definiálva, és nem csupán arról van szó, hogy a véglegesítés meghiúsul.

Tehát a megfigyelt várakozás összeg: naplószállítás, ütemezés mindkét gazdagépen és a távoli tároló írása. A telített naplómennyiségű másodlagos olyan időt ad hozzá, amelyet egyetlen sebességteszt sem mutat meg. Azt a lemezt ritkán mérik, amikor a panasz a VPN-t említi.

A sávszélesség nem oda-vissza késleltetés

A sebességteszt rövid időre elárasztja az útvonalat, és sebességet jelent. A véglegesítés valami szűkebbet kér: mennyi idő alatt ér egy kis üzenet a túloldalra, perzisztálódik és visszatér. Az útvonal hossza, a sorban állás és a csomagvesztés határozza meg ezt a számot, és egyik sem javul, amikor a szolgáltató megemeli a plafont.

Ezért egy «gyors» alagút látható büntetést adhat egy írásigényes munkaterheléshez, amely sok kis, egymást követő tranzakcióból épül fel. Ugyanaz a bájtszám ezer véglegesítésre osztva ezerszer fizeti meg az oda-vissza utat; egy tömeges átvitel egyszer fizeti meg.

Kérje a hálózat tulajdonosától a késleltetés és a veszteség mérését magán a replika útvonalán, reprezentatív terhelés alatt. Egy ping az irodai laptopról a VPN-átjáróhoz, vagy egy sebességteszt egy közeli csomóponthoz, szinte semmit sem tulajdonít annak az útvonalnak, amelyen a napló valóban halad. Gondoskodjon arról, hogy a mérési ablak átfedje azokat az órákat, amikor az írás lassú.

Olvassa el a replika állapotát, mielőtt bármit megváltoztat

Kezdje azzal, amit a példányok magukról jelentenek, mert a két fél vitatkozhat arról, mennyire egészséges a partnerség, és az irányítópult átlaga elrejti, melyik sor mozog. Az alábbi lekérdezések különböző kérdésekre válaszolnak: az egyik adatbázisonként olvassa a replikációs állapotot, a másik azt olvassa, hogyan van konfigurálva az egyes replikák. Futtassa mindkettőt, mielőtt hozzányúl egy módhoz.

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;

Az első eredmény elválasztja a naplószállítást a redótól. log_send_queue_size növekszik, miközben redo_queue_size lapos marad, azt jelenti, hogy a napló nem érkezett meg; az ellenkezője azt, hogy megérkezett, és az újrajátszás lemarad. Csak az első eset ül a véglegesítés útvonalán.

A második eredmény megerősíti, mely replikák vannak valóban úgy konfigurálva, ahogy feltételezi, mert egy korábbi incidens során megváltoztatott mód hajlamos megváltozott és dokumentálatlan maradni. Az érdekes sort olvassa a csoport alapértéke helyett: availability_mode_desc és failover_mode_desc replikánként értendő. A secondary_lag_seconds csak SQL Server 2016-tól létezik, így egy régebbi build csak a küldési sor és a redo oszlopait hagyja meg.

Ezután mérjen egy reprezentatív írást, ahelyett hogy az irányítópult átlagában bízna. Futtassa az alábbi blokkot a rendelkezésre állási adatbázisban, majd futtassa újra ugyanazon a példányon, a csoporton kívüli adatbázisban lévő azonos táblaszerkezet ellen. A két időtartam közötti különbség durva ár a távoli naplóért, és a hálózati csapattal folytatott vitában sokkal jobban megáll, mint egy grafikon. Utána egyszerre egy változót módosítson, különben a különbség értelmét veszti.

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;

Mit vásárol az aszinkron véglegesítés, és mennyibe kerül

Aszinkron véglegesítésnél az elsődleges abbahagyja a távoli megkeményítés visszaigazolására való várakozást, így az oda-vissza út elhagyja a véglegesítés útvonalát. A véglegesítési latencia csökken, és a másodlagos szabadon lemaradhat egy olyan mértékben, amelyet senki sem irányít. Ez valódi javítás a várakozásra és valódi változás az ígéretben.

Az ár egy helyreállítási pontról szóló döntés. Ha az elsődleges meghal, mielőtt a naplója elérné azt a feladatátvételi célt, amelyet valóban használhat, a szolgáltatás aszinkron másolatra tolása eldobja azokat a tranzakciókat, amelyeket az alkalmazás már véglegesítettként jelentett. Egyetlen konfigurációs párbeszéd sem mutatja be így, mert ez az elfogadható veszteségről szóló üzleti kérdés, nem teljesítménybeállítás. Írja le az elviselt veszteségablakot az incidens előtt, nem közben.

Egyezzen meg a módról az adat tulajdonosával írásban, együtt a feladatátvételi eljárással arra az esetre, amikor az előnyben részesített cél nem elérhető. A szinkron egy tervezési dokumentumban nem üzemeltetési kézikönyv, és az aszinkron nem engedély a sorok figyelésének abbahagyására.

Válasszon olyan javítást, amelyet utólag meg tud védeni

Négy őszinte lehetőség van. Vágja le az elkerülhető véglegesítési oda-vissza utakat ott, ahol az alkalmazás szemantikája engedi a kötegelést; javítsa a mért szállítási vagy tárolási szűk keresztmetszetet, ami a másodlagoson gyorsabb naplómennyiséget jelenthet nagyobb cső helyett; vigye közelebb a replikát, hogy az oda-vissza út zsugorodjon; vagy lazítsa a védelmi szabályzatot, és fogadjon el szélesebb veszteségablakot. Mindegyik latenciát vásárol valami más elköltésével, a negyedik pedig tartósságot költ. Nevezze meg a költést, mielőtt választ.

Döntsön úgy, hogy a munkaterhelés latenciacélja és tartóssági követelménye egyszerre van előtte, mert az egyik optimalizálása csendesen a másikat költi el. Ezután futtassa újra ugyanazt a tranzakciót, amelyet a változtatás előtt mért. Az a javítás, amely nem tudja mozgatni ezt a számot, egy változtatási jeggyel ellátott találgatás.

Őrizze meg a változtatási rekordban az előtti és utáni leolvasásokat. Különben a következő ember, aki lassú írásokat lát, elölről megismétli a vizsgálatot, és újra az alagút hibáztatásával kezdi.