Miért lassítja mégis egy gyors VPN a szinkron SQL-véglegesítést

Nyisson lekérdezési munkamenetet az elsődlegesen, és nézze meg, mire vár egy egyszerű írás. Ha az adatbázis szinkron véglegesítésű rendelkezésre állási csoporthoz tartozik, és a másodlagos csatlakoztatva van, a várakozás egy része elhagyja az épületet: a naplórekordok a replikára utaznak, ott keményednek, és a keményedés híre visszaér, mielőtt a véglegesítés befejeződik. A sávszélesség nem rövidíti le ezt az oda-vissza utat. Az alábbi végigvezetés a nyugtát követi a képernyőtől a távoli lemezig és vissza.

Kezdje az elsődleges várakozási típusánál

A távoli replikán várakozó írás naplóhoz kapcsolódó várakozásként jelenik meg, nem processzor- vagy zárvárakozásként, és a tranzakció időtartama az oda-vissza utat követi a sorok száma helyett. Sok kis véglegesítés teszi nyilvánvalóvá, mert mindegyik külön fizet az útért. Egyetlen tömeges művelet ugyanezt a költséget egy hosszabb nyugta belsejébe rejti.

A kapcsolatról való bármilyen következtetés előtt rendezze a munkaterhelést a véglegesítések gyakorisága szerint.

A hálózat olvasása előtt olvassa el a replika állapotát. A fontos számlálók a küldési sor, a redo sor és a szinkronizálási állapot, és együtt megmutatják, hogy a másodlagos tartja-e a tempót, vagy lemarad. A növekvő küldési sor a szállításra utal, míg a növekvő redo sor a másodlagos saját munkájára vagy tárolójára. Ezek különböző javítások, és egyik sem javul sávszélesség hozzáadásától.

Kövesse a nyugtát a másodlagosig

Szinkron véglegesítésnél az elsődleges megvárja annak visszaigazolását, hogy a vonatkozó napló keményedett a másodlagoson, mielőtt késznek jelenti a véglegesítést. A keményedett tartósat jelent a naplóban, nem az adatoldalakba visszajátszottat. Ez a különbség magyarázza, miért maradhat le egy szinkron másodlagos a redóban, miközben továbbra is visszaigazolja a keményedést.

Járja végig az útvonalat sorrendben, és az egész helyett minden szakaszt mérjen. A naplórekordok átmennek a szállításon, a másodlagos kiírja és kiüríti őket, és a nyugta ugyanazon az úton tér vissza. A szállítási késleltetés, a másodlagos ütemezése és a másodlagos naplólemezének késleltetése mind bekerül az összegbe, és csak az első tartozik a hálózat tulajdonosához. Egy másodlagos, amelynek naplómennyiségét valami más telíti, minden véglegesítést megnyújthat, miközben a kapcsolat tétlenül áll.

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;

Készítse el ezt a pillanatképet egy reprezentatív írás előtt és után, ne egyszer egy csendes délután. A különbség mondja meg, melyik sor mozdult el, miközben a véglegesítés várt.

Az útvonalat mérje, ne a kapcsolatot

Egy átbocsátási teszt két olyan pont közötti kapacitást mér, amelyek nem a replikái, olyan terhelés alatt, amely nem a munkája. Kérje meg a hálózat tulajdonosát, hogy mérje a késleltetést és a veszteséget a valódi replikaútvonalon valódi forgalom mellett, mindkét irányban. A veszteség itt fontosabb a kapacitásnál, mert egy elveszett szegmens újraátvitelbe kerül, és minden véglegesítés egy nyugtára vár. Egy letöltési tesztben kiválónak látszó kapcsolat még mindig alkalmatlan lehet egy beszédes véglegesítési mintához.

Mérés közben tartsa érintetlenül az adatbázis szállítási biztonságát és a hozzáférés-vezérlést. Egy útvonal mérése soha nem ok ezek megkerülésére.

Korrelálja az időket a számlálókkal, ne a megérzéssel. Ha a küldési sor üres marad, és a véglegesítés mégis vár, a késleltetés a nyugtában vagy a másodlagos kiürítésében van. Ha a küldési sor folyamatosan nő, a szállítás vagy a kapacitás a korlát. Jegyezze fel, mely megfigyelés támasztotta alá a következtetést, hogy a következő ember a mérést ismételhesse meg, ne a vitát.

Mit változtat valójában az aszinkron mód

Az aszinkron véglegesítés eltávolítja a másodlagos keményedési nyugtájára való várakozást, ezért lesznek gyorsabbak az írások, és ezért változik a tartóssági helyzete. Az elsődleges a távoli visszaigazolás nélkül igazolja a tranzakciót. A másodlagos ekkor lemaradhat, és ez a lemaradás a kitettség.

Ha az elsődleges elveszik, mielőtt a napló elérne egy használható feladatátvételi célpontot, a szolgáltatás erőltetett átvitele arra a replikára eldobja azokat a tranzakciókat, amelyeket az alkalmazás már véglegesítettként kapott vissza.

Ez egy helyreállítási pontról szóló döntés, és az adatbázis tulajdonosáé, nem egy teljesítményvizsgálaté. Először állítsa be a tolerált adatvesztési ablakot, válassza ki az azt kielégítő módot, majd optimalizáljon ezen a határon belül. A szinkron védelmet megőrző lehetőségek közé tartozik az elkerülhető véglegesítési oda-vissza utak megszüntetése ott, ahol az alkalmazás engedi, egy mért szállítási vagy tárolási szűk keresztmetszet javítása, és a replika áthelyezése, hogy a nyugta rövidebb utat tegyen meg. Mérje fel ezeket a kezdeti tartóssági követelményhez képest, amely nem változott.