Kial rapida VPN ankoraŭ malrapidigas sinkronan SQL-konfirmon

Malfermu konsultan seancon ĉe la ĉefa kaj rigardu, kion atendas simpla skribo. Se la datumbazo apartenas al disponebla grupo kun sinkrona konfirmo kaj la sekundara estas konektita, parto de tiu atendo forlasas la konstruaĵon: protokolaj rikordoj vojaĝas al la kopio, estas malmoligitaj tie, kaj la sciigo pri tiu malmoligo revenas antaŭ ol la konfirmo finiĝas. Bendlarĝo ne mallongigas tiun vojaĝon tien kaj reen. La suba trairo sekvas la konfirmon de la ekrano al la fora disko kaj reen.

Komencu ĉe la atenda tipo sur la ĉefa

Skribo atendanta ĉe la fora kopio montriĝas kiel atendo ligita al la protokolo, ne kiel atendo de procesoro aŭ ŝloso, kaj la daŭro de la transakcio sekvas la vojaĝon tien kaj reen anstataŭ la nombron de vicoj. Multaj malgrandaj konfirmoj tion evidentigas, ĉar ĉiu pagas la vojaĝon aparte. Unu amasa operacio kaŝas la saman koston en unu pli longa konfirmo.

Ordigu vian laborŝarĝon laŭ konfirma ofteco antaŭ ol konkludi ion ajn pri la ligo.

Legu la staton de la kopio antaŭ ol legi la reton. La gravaĵoj estas la sendovico, la redo-vico kaj la sinkroniga stato, kaj kune ili montras ĉu la sekundara tenas paŝon aŭ restas malantaŭe. Kreskanta sendovico indikas transporton, dum kreskanta redo-vico indikas la propran laboron aŭ konservejon de la sekundara. Tiuj estas malsamaj riparoj, kaj neniu pliboniĝas per aldonado de bendlarĝo.

Sekvu la konfirmon al la sekundara

Ĉe sinkrona konfirmo la ĉefa atendas konfirmon, ke la koncerna protokolo estis malmoligita sur la sekundara, antaŭ ol raporti la konfirmon kiel finitan. Malmoligita signifas daŭra en la protokolo, ne reludita en datumaj paĝoj. Ĝuste tiu distingo klarigas, kial sinkrona sekundara povas resti malantaŭe pri redo dum ĝi ankoraŭ konfirmas malmoligon.

Trairu la vojon laŭorde kaj mezuru ĉiun etapon anstataŭ la tuton. Protokolaj rikordoj iras tra la transporto, la sekundara skribas kaj elfluigas ilin, kaj la konfirmo revenas laŭ la sama vojo. Transporta prokrasto, planado de la sekundara kaj latenteco de la protokola disko de la sekundara ĉiuj eniras la totalon, kaj nur la unua apartenas al la retposedanto. Sekundara, kies protokola volumeno estas saturita de io alia, povas streĉi ĉiun konfirmon dum la ligo sidas senokupa.

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;

Prenu tiun momentfoton antaŭ kaj post reprezenta skribo anstataŭ unufoje en trankvila posttagmezo. La diferenco estas tio, kio diras al vi, kiu vico moviĝis dum la konfirmo atendis.

Mezuru la vojon, ne la ligon

Trakvanta testado mezuras kapaciton inter du punktoj, kiuj ne estas viaj kopioj, sub ŝarĝo, kiu ne estas via laboro. Petu de la retposedanto prokraston kaj perdon laŭ la reala vojo de la kopio dum reala trafiko fluas, en ambaŭ direktoj. Perdo pli gravas ol kapacito ĉi tie, ĉar perdita segmento kostas resendon kaj ĉiu konfirmo atendas unu konfirmon. Ligo, kiu aspektas bonega en elŝuta testo, povas tamen esti maltaŭga por babilama konfirma ŝablono.

Konservu sendifektaj la transportan sekurecon de la datumbazo kaj la alirregulojn dum vi mezuras. Mezuri vojon neniam estas kialo por preterpasi ilin.

Kunrilatigu la tempojn kun la nombriloj anstataŭ kun intuicio. Se la sendovico restas malplena kaj la konfirmo ankoraŭ atendas, la prokrasto estas en la konfirmo aŭ en la elfluigo de la sekundara. Se la sendovico konstante kreskas, la limigo estas transporto aŭ kapacito. Notu, kiu observo subtenis la konkludon, por ke la sekva persono povu ripeti la mezuron anstataŭ la diskuton.

Kion la nesinkrona reĝimo vere ŝanĝas

Nesinkrona konfirmo forigas la atendon por la malmoliga konfirmo de la sekundara, kaj tial skriboj plirapidiĝas kaj tial via daŭripova pozicio ŝanĝiĝas. La ĉefa konfirmas la transakcion sen tiu fora konfirmo. Tiam al la sekundara estas permesite resti malantaŭe, kaj tiu maltrafiĝo estas la elmeto.

Se la ĉefa perdiĝas antaŭ ol la protokolo atingas uzeblan celon de malsukcesa transiro, devigi la servon al tiu kopio forĵetas transakciojn, kiujn la aplikaĵo jam estis informita kiel konfirmitaj.

Tio estas decido pri reakira punkto kaj apartenas al la datumbaza posedanto, ne al agado-revizio. Unue fiksu la toleratan fenestron de datumperdo, elektu la reĝimon, kiu ĝin kontentigas, poste optimumigu ene de tiu limo. Opcioj, kiuj konservas sinkronan protekton, inkluzivas forigi evitindajn konfirmajn vojaĝojn tien kaj reen kie la aplikaĵo tion permesas, ripari mezuritan trafikŝtopiĝon en transporto aŭ konservejo, kaj movi la kopion tiel ke la konfirmo vojaĝu malpli longe. Pezu ilin kontraŭ la daŭreca postulo, kun kiu vi komencis kaj kiu ne ŝanĝiĝis.