Firwat Äre synchrone SQL-Commit op d'VPN-Rondreeis waart

D'Schreiflatenz ass an d'Luucht gaang, nodeems eng Replika op den zweete Site geplënnert gouf, an den Tunnel ass déi neist Komponent, also kritt hien d'Schold. Den Tunnel kann onschëlleg sinn: bannent enger Disponibilitéitsgrupp mat synchronem Commit kann de primäre Replika e Commit net bestätegen, bis eng distanzéiert Logschreifung fäerdeg ass, sou datt all Transaktioun eng Rondreeis bezilt, egal wéi vill Megabit d'Verbindung ka droen. Den Duerchfloss misst Bytes pro Sekonn, d'Latenz misst wéi laang een Austausch dauert, an e Commit brauch nëmmen een klengen Austausch fir fäerdeg ze ginn. Eng eenzeg Zuel entscheet d'Diskussioun: d'Dauer vum Commit vun enger klenger Transaktioun, gemooss an der Disponibilitéitsdatebank an duerno nach eng Kéier géint eng lokal Tabell op der selwechter Instanz.

Op wat de primäre Replika wierklech waart

Bei synchronem Commit hält de primäre Replika d'Commit-Bestätegung zréck, bis de Partner bestätegt datt seng Logrecords gehärtet sinn. Gehärtet heescht dauerhaft an den Transaktiounslog vum sekundäre Replika geschriwwen, net a seng Datesäiten nei gespillt. Redo kann Minutten hannendrun hänken, ouni dem Commit vum primäre Replika eng Millisekonn bäizesetzen.

Microsoft seng Dokumentatioun zu den Disponibilitéitsmodi erkläert dee Handshake a beschreift wat d'Plattform mécht, wa en Partner erausfällt. Eng Replika, déi als synchron markéiert ass, ass eng Regel iwwer d'Waarden, net e stännegt Verspriechen, datt et fir all Commit eng gesond distanzéiert Kopie gëtt. Den ofgetrennte Wee ass separat definéiert, an et ass net einfach, datt de Commit feelt.

Also ass d'Waarden, déi Dir gesitt, eng Summ: Logtransport, Planung op béide Hosts an d'Schreifung an de distanzéierte Stockage. En sekundäre Replika mat engem gesättegte Logvolumen füügt Zäit bäi, déi keen Geschwindigkeitstest weist. Dee Disk gëtt seelen gemooss, wann d'Plaint d'VPN nennt.

Bandbreet ass keng Rondreeis-Verzögerung

En Geschwindigkeitstest iwwerschwemmt de Wee kuerz a mellt eng Taux. E Commit freet eppes méi Enges: wéi laang eng kleng Noriicht brauch, fir op déi aner Säit ze kommen, persistéiert ze ginn an zréckzekommen. D'Längt vum Wee, d'Queue an de Paketverloscht bestëmmen déi Zuel, an keen dovun verbessert sech, wann de Provider de Plaffong hieft.

En «schnellen» Tunnel kann dofir eng sichtbar Strof op eng schreifintensiv Aarbechtslaascht setzen, déi aus ville klengen uerdentlechen Transaktiounen opgebaut ass. Déi selwecht Byte-Summ op dausend Commits verdeelt bezilt d'Rondreeis dausendmol; eng Bulk-Transfert bezilt se eemol.

Frot den Netzwierkbesëtzer no Verzögerung a Verloscht, gemooss iwwer de Replika-Wee selwer ënner representativer Laascht. E Ping vun engem Büro-Laptop op de VPN-Gateway, oder en Geschwindigkeitstest op en noen Node, schreift bal näischt dem Wee zou, deen de Log tatsächlech hëlt. Suergt dofir, datt d'Miessfenster sech mat den Stonnen iwwerschneit, wou d'Schreifung lues ass.

Liest den Zoustand vun der Replika, ier Dir eppes ännert

Fänkt mat deem un, wat d'Instanze vu sech selwer berichten, well déi zwou Säite kënnen oneneeg sinn, wéi gesond d'Partnerschaft ass an e Dashboard-Duerchschnëtt verstoppt, wéi eng Queue sech beweegt. D'Ufroe hei drënner beäntweren ënnerschiddlech Froen: eng liest de Replikatiounszoustand pro Datebank, déi aner liest, wéi all Replika konfiguréiert ass. Fëllt béid aus, ier Dir e Modus ufänkt.

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;

Déi éischt Resultat trennt den Logtransport vum Redo. log_send_queue_size, dee klëmmt, während redo_queue_size flaach bleift, heescht, datt de Log net ukomm ass; de Géigendeel heescht, datt en ukomm ass an d'Replay hannendrun ass. Nëmmen den éischte Fall sëtzt um Commit-Wee.

Déi zweet Resultat bestätegt, wéi eng Replike wierklech esou konfiguréiert sinn, wéi Dir unhëlt, well e Modus, dee wärend engem fréieren Tëschefall geännert gouf, meeschtens geännert an ondocumentéiert bleift. Liest d'Zeile, déi Iech interesséiert, amplaz vum Grupp-Default: availability_mode_desc an failover_mode_desc sinn pro Replika. secondary_lag_seconds gëtt et nëmmen op SQL Server 2016 an méi nei, also léisst eng eeler Build Iech nëmmen d'Kolonnen fir d'Sendqueue an de Redo.

Da misst eng representativ Schreifung, amplaz engem Dashboard-Duerchschnëtt ze vertrauen. Fëllt de Block hei drënner an der Disponibilitéitsdatebank aus, a fëllt en duerno nach eng Kéier géint déiselwecht Tabellform an enger Datebank ausserhalb vum Grupp op der selwechter Instanz aus. Den Ecart tëscht den zwou Daueren ass e graffe Präis fir de distanzéierte Log, an an enger Diskussioun mam Netzwierkteam hält en sech vill besser wéi eng Grafik. Ännert duerno eng Variabel op eemol, soss bedeit den Ecart näischt méi.

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;

Wat en asynchrone Commit kaaft, a wat en kascht

Bei asynchronem Commit hält de primäre Replika op, op d'Bestätegung vun der distanzéierter Härtung ze waarden, sou datt d'Rondreeis de Commit-Wee verléisst. D'Commit-Latenz fällt an de sekundäre Replika ass fräi, hannendrun ze hänken ëm eng Quantitéit, déi keen kontrolléiert. Dat ass eng richteg Korrektur fir d'Waarden an eng richteg Ännerung vum Verspriechen.

De Präis ass eng Entscheedung iwwer de Wiederherstellungspunkt. Wann de primäre Replika stierft, ier säi Log en Failover-Zil erreecht, dat Dir wierklech benotze kënnt, verwerft d'Verleeën vum Service op d'asynchron Kopie Transaktiounen, déi d'Applikatioun schonn als committéiert gemellt huet. Keen Konfiguratiounsdialog stellt et esou duer, well et eng Geschäftsfro iwwer akzeptablen Verloscht ass, net eng Leeschtungsastellung. Schreift d'toleréiert Verloschtfenster virum Tëschefall op, net während deem.

Verhitt Iech mam Besëtzer vun den Donnéeën iwwer de Modus, schrëftlech, zesumme mam Failover-Prozedur fir de Fall, wou dat gewënschten Zil net verfügbar ass. Synchron an engem Design-Dokument ass kee Betribshandbuch, an asynchron ass keng Lizenz, d'Queue stoppen ze beobachten.

Wielt eng Korrektur, déi Dir duerno verteidegen kënnt

Et gëtt véier éierlech Optiounen. Schneit vermeidbar Commit-Rondreeisen of, wou d'Semantik vun der Applikatioun Batching erlaabt; fixéiert en gemoossenen Transport- oder Stockagefläschhals, wat e méi schnelle Logvolumen op deem sekundäre bedeite kann amplaz engem méi groussen Rouer; bréngt d'Replika méi no, sou datt d'Rondreeis schrumpft; oder lockert d'Schutzpolitik a akzeptéiert eng méi breet Verloschtfenster. Jiddwereen kaaft Latenz andeems en eppes anescht ausgëtt, an de véierten gëtt Haltbarkeet aus. Nennt d'Ausgab, ier Dir wielt.

Entscheet Iech, während de Latenzzil vun der Aarbechtslaascht an hir Haltbarkeetsfuerderung gläichzäiteg virun Iech sinn, well d'Optimiséierung vun engem stëllden aneren ausgëtt. Fëllt duerno déiselwecht Transaktioun nach eng Kéier aus, déi Dir virun der Ännerung gemooss hutt. Eng Korrektur, déi déi Zuel net bewege kann, ass eng Vermutung mat engem Ännerungsticket.

Hält d'Vir- an No-Miessungen am Ännerungsprotokoll. Soss widderhëlt déi nächst Persoun, déi lues Schreifunge gesäit, d'Enquête vum Ufank un a fänkt nees un, den Tunnel ze beschëllegen.