Kial via sinkrona SQL-fiksado atendas la VPN-vojaĝon tien kaj reen

La skriba latenteco saltis post kiam replikaĵo translokiĝis al la dua ejo, kaj la tunelo estas la plej nova komponento, do ĝi ricevas la kulpon. La tunelo povas esti senkulpa: ene de havebleca grupo kun sinkrona fiksado la ĉefa ne povas konfirmi fiksadon ĝis malproksima protokola skribo finiĝos, do ĉiu transakcio pagas vojaĝon tien kaj reen, kiom ajn da megabitoj la ligilo povas porti. Trafluo mezuras bajtojn en sekundo, latenteco mezuras kiom longe unu interŝanĝo daŭras, kaj fiksado bezonas nur unu malgrandan interŝanĝon por finiĝi. Unu nombro solvas la disputon: la daŭro de fiksado de malgranda transakcio, mezurita ene de la havebleca datumbazo kaj denove kontraŭ loka tabelo sur la sama instanco.

Kion la ĉefa efektive atendas

Sub sinkrona fiksado la ĉefa retenas la fiksadan konfirmon ĝis la partnero konfirmas, ke ĝiaj protokolaj rikordoj estas malmoligitaj. Malmoligita signifas daŭre skribita al la transakcia protokolo de la sekundara, ne rearanĝita en ĝiajn datumpaĝojn. Redo povas malantaŭiĝi je minutoj sen aldoni eĉ unu milisekundon al la fiksado de la ĉefa.

Dokumentaro de Microsoft pri la haveblecaj reĝimoj priskribas tiun manpremon kaj kion la platformo faras kiam partnero elfalas. Replikaĵo markita kiel sinkrona estas regulo pri atendo, ne konstanta promeso, ke ekzistas sana malproksima kopio por ĉiu fiksado. La malkonektita vojo estas difinita aparte, kaj ĝi ne simple signifas, ke la fiksado malsukcesas.

Do la atendo, kiun vi vidas, estas sumo: protokola transporto, planado sur ambaŭ gastigantoj kaj la malproksima stokada skribo. Sekundara kun saturita protokola volumo aldonas tempon, kiun neniu rapidtesto montros. Tiu disko malofte estas mezurata kiam la plendo nomas la VPN-on.

Bandlarĝo ne estas prokrasto de vojaĝo tien kaj reen

Rapidtesto mallonge inundas la vojon kaj raportas rapidon. Fiksado demandas ion pli mallarĝan: kiom longe malgranda mesaĝo bezonas por atingi la alian flankon, esti konservita kaj reveni. Voja longo, vicigo kaj paketa perdo difinas tiun nombron, kaj neniu el ili pliboniĝas kiam la provizanto levas la plafonon.

Do «rapida» tunelo povas aldoni videblan punon al skrib-peza laborŝarĝo konstruita el multaj malgrandaj sinsekvaj transakcioj. La sama bajta sumo dividita sur mil fiksadoj pagas la vojaĝon tien kaj reen mil fojojn; unu pogranda transigo pagas ĝin unufoje.

Petu de la retposedanto prokraston kaj perdon mezuritajn sur la replika vojo mem sub reprezenta ŝarĝo. Ping de oficeja tekkomputilo al la VPN-pordego, aŭ rapidtesto al proksima nodo, atribuas preskaŭ nenion al la vojo, kiun la protokolo efektive vojaĝas. Certigu, ke la mezura fenestro interkovras la horojn, kiam skribado estas malrapida.

Legu la staton de la replikaĵo antaŭ ol ŝanĝi ion

Komencu de tio, kion la instancoj raportas pri si mem, ĉar la du flankoj povas malkonsenti pri tio, kiom sana la partnereco estas, kaj panela averaĝo kaŝas, kiu vico moviĝas. La demandoj sube respondas diversajn demandojn: unu legas la reproduktan staton laŭ datumbazo, la alia legas kiel ĉiu replikaĵo estas agordita. Rulu ambaŭ antaŭ ol tuŝi reĝimon.

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;

La unua rezulto apartigas protokolan transporton de redo. log_send_queue_size supreniranta dum redo_queue_size restas ebena signifas, ke la protokolo ne alvenis; la malo signifas, ke ĝi alvenis kaj la reludado malantaŭiĝas. Nur la unua kazo sidas sur la fiksada vojo.

La dua rezulto konfirmas, kiuj replikaĵoj efektive estas agorditaj tiel, kiel vi supozas, ĉar reĝimo ŝanĝita dum pli frua okazaĵo emas resti ŝanĝita kaj nedokumentita. Legu la vicon, kiu gravas al vi, anstataŭ la grupan defaŭlton: availability_mode_desc kaj failover_mode_desc estas po replikaĵo. secondary_lag_seconds ekzistas nur en SQL Server 2016 kaj pli nova, do pli malnova konstruo lasas al vi nur la kolumnojn de sendovico kaj redo.

Poste mezuru reprezentan skribon anstataŭ fidi panelan averaĝon. Rulu la blokon sube en la havebleca datumbazo, poste rulu ĝin denove kontraŭ la sama tabela formo en datumbazo ekster la grupo sur la sama instanco. La breĉo inter la du daŭroj estas kruda prezo por la malproksima protokolo, kaj en diskuto kun la reta teamo ĝi teniĝas multe pli bone ol grafikaĵo. Poste ŝanĝu unu variablon samtempe, alie la breĉo ĉesas signifi ion.

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;

Kion aĉetas nesinkrona fiksado kaj kiom ĝi kostas

Kun nesinkrona fiksado la ĉefa ĉesas atendi la konfirmon de malproksima malmoligo, do la vojaĝo tien kaj reen forlasas la fiksadan vojon. Fiksada latenteco falas kaj la sekundara estas libera malantaŭiĝi je kvanto, kiun neniu kontrolas. Tio estas vera riparo por la atendo kaj vera ŝanĝo de la promeso.

La prezo estas decido pri reakira punkto. Se la ĉefa mortas antaŭ ol ĝia protokolo atingas failsuperan celon, kiun vi efektive povas uzi, ŝovi la servon al la nesinkrona kopio forĵetas transakciojn, kiujn la aplikaĵo jam raportis kiel fiksitajn. Neniu agorda dialogo prezentas ĝin tiel, ĉar ĝi estas komerca demando pri akceptebla perdo, ne agordo de rendimento. Skribu la toleratan perdan fenestron antaŭ la okazaĵo, ne dum ĝi.

Interkonsentu la reĝimon kun tiu, kiu posedas la datumojn, skribe, kune kun la failsupera proceduro por la kazo, kiam la preferata celo ne estas disponebla. Sinkrona en dezajna dokumento ne estas operacia manlibro, kaj nesinkrona ne estas permesilo ĉesi observi la vicojn.

Elektu riparadon, kiun vi povos defendi poste

Ekzistas kvar honestaj opcioj. Tranĉu eviteblajn fiksadajn vojaĝojn tien kaj reen, kie la semantiko de la aplikaĵo permesas ariĝon; riparu mezuritan botelon en transporto aŭ stokado, kio povas signifi pli rapidan protokolan volumon sur la sekundara anstataŭ pli granda tubo; proksimigu la replikaĵon, por ke la vojaĝo tien kaj reen malgrandiĝu; aŭ malstreĉu la protektan politikon kaj akceptu pli larĝan perdan fenestron. Ĉiu aĉetas latentecan per elspezo de io alia, kaj la kvara elspezas daŭrecon. Nomu la elspezon antaŭ ol elekti.

Decidu kun la latenteca celo de la laborŝarĝo kaj ĝia daŭreca postulo samtempe antaŭ vi, ĉar optimumigo de unu kviete elspezas la alian. Poste reludu la saman transakcion, kiun vi mezuris antaŭ la ŝanĝo. Riparo, kiu ne povas movi tiun nombron, estas konjekto portanta ŝanĝbileton.

Konservu la antaŭajn kaj postajn legaĵojn en la ŝanĝa registro. Alie la sekva persono, kiu vidos malrapidajn skribojn, ripetas la esploron de la komenco kaj komencas denove kulpigi la tunnelon.