Эмне үчүн сиздин синхрондук SQL commit VPNдин барып-кайтуусун күтөт

Реплика экинчи сайтка көчүрүлгөндөн кийин жазуу кечигүүсү секирип кетти, ал эми туннель эң жаңы компонент, ошондуктан күнөө ага жүктөлөт. Туннель күнөөсүз болушу мүмкүн: синхрондук бекітүүсү бар жеткиликтүүлүк тобунун ичинде баштапкы реплика алыскы журнал жазуусу бүтмөйүнчө бекітүүнү тастыктай албайт, ошондуктан ар бир транзакция барып-кайтууну төлөйт, байланыш канча мегабит ташыса да. Өткөрүү жөндөмү секундасына байтты өлчөйт, кечигүү бир алмашуунун канча убакыт алаарын өлчөйт, ал эми бекітүүгө бүтүү үчүн бир гана кичине алмашуу жетиштүү. Бир сан талашты чечет: кичине транзакциянын бекітүү узактыгы, жеткиликтүүлүк маалымат базасынын ичинде жана ошол эле инстанциядагы жергиликтүү таблицага каршы кайра өлчөнгөн.

Баштапкы реплика чындыгында эмнени күтөт

Синхрондук бекітүүдө баштапкы өнөктөш өзүнүн журнал жазуулары катайтылганын тастыктамайынча бекітүү тастыгын кармап турат. Катайтылган экинчинин транзакция журналына туруктуу жазылганын билдирет, анын маалымат барактарында кайра аткарылган эмес. Redo баштапкынын бекітүүсүнө бир миллисекунд кошпостон мүнөттөргө артта кала алат.

Microsoftтин жеткиликтүүлүк режимдери боюнча документтери ошол кол кармоону түшүндүрөт жана өнөктөш чыгып калганда платформа эмне кылаарын сүрөттөйт. Синхрондук деп белгиленген реплика күтүү тууралуу эреже, ар бир бекітүү үчүн соо алыскы көчүрмө бар деген туруктуу убада эмес. Ажыратылган жол өзүнчө аныкталган, жана бул жөн гана бекітүүнүн ишке ашпай калышы эмес.

Ошондуктан сиз көрүп турган күтүү — сумма: журнал ташуу, эки хостто пландоо жана алыскы кампага жазуу. Каныккан журнал көлөмү бар экинчи эч кандай ылдамдык сыноосу көрсөтпөй турган убакытты кошот. Дат VPNди атаганда ошол диск сейрек өлчөнөт.

Өткөрүү жөндөмү барып-кайтуу кечигүүсү эмес

Ылдамдык сыноосу жолду кыска убакытка басып, ылдамдыкты билдирет. Бекітүү тарраак нерсени сурайт: кичине билдирүүнүн аркы тарапка жетиши, сакталышы жана кайтышы канча убакыт алат. Жолдун узундугу, кезек жана пакет жоготуу ошол санды аныктайт, жана провайдер чегин көтөргөндө алардын эч бири жакшырбайт.

Ошондуктан «ылдам» туннель көптөгөн кичине ырааттуу транзакциялардан курулган жазууга оор жүктөмгө көрүнүүчү айып кошуусу мүмкүн. Ошол эле байт суммасы миң бекітүүгө бөлүнсө, барып-кайтууну миң жолу төлөйт; бир жапырт өткөрүү аны бир жолу төлөйт.

Тармак ээсинен өкүлдүк жүктөм астында реплика маршрутунун өзүндө кечигүү менен жоготууну өлчөөнү сураныңыз. Кеңсе ноутбугунан VPN шлюзине ping же жакын түйүнгө ылдамдык сыноосу журнал чындыгында жүргөн маршрутка дээрлик эч нерсе жүктөбөйт. Өлчөө терезеси жазуу жай болгон сааттарга дал келишин камсыз кылыңыз.

Бир нерсени өзгөртүүдөн мурун репликанын абалын окуңуз

Инстанциялар өздөрү тууралуу билдирген нерседен баштаңыз, анткени эки тарап өнөктөштүктүн канчалык соо экени тууралуу макул болбой калышы мүмкүн жана башкаруу панелинин орточо мааниси кайсы кезек кыймылдап жатканын жашырат. Төмөнкү суроолор ар башка суроолорго жооп берет: бири ар бир маалымат базасы боюнча репликация абалын окуйт, экинчиси ар бир репликанын кантип конфигурацияланганын окуйт. Режимге кол тийгизүүдөн мурун экөөнү тең иштетиңиз.

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;

Биринчи натыйжа журнал ташууну redoдон бөлөт. log_send_queue_size өсүп, redo_queue_size тегиз турса, журнал келген эмес; тескерисинче болсо, ал келген жана кайра ойнотуу артта калган. Бекітүү жолунда биринчи учур гана отурат.

Экинчи натыйжа кайсы репликалар чындыгында сиз божомолдогондой конфигурацияланганын тастыктайт, анткени мурунку окуя учурунда өзгөртүлгөн режим өзгөртүлгөн жана документтелбеген бойдон калат. Топтун демейки маанисинин ордуна сизди кызыктырган сапты окуңуз: availability_mode_desc жана failover_mode_desc ар бир реплика үчүн. secondary_lag_seconds SQL Server 2016 жана андан кийинкилерде гана бар, ошондуктан эски курулуш сизге жөнөтүү кезеги жана redo мамычаларын гана калтырат.

Андан кийин башкаруу панелинин орточо маанисине ишенүүнүн ордуна өкүлдүк жазууну өлчөңүз. Төмөнкү блокту жеткиликтүүлүк маалымат базасында иштетиңиз, андан кийин аны ошол эле инстанциядагы топтон тышкаркы маалымат базасындагы ошол эле таблица формасына каршы кайра иштетиңиз. Эки узактыктын ортосундагы айырма алыскы журналдын одоно баасы, жана тармак командасы менен талашта ал графиктен алда канча жакшы турат. Андан кийин бир убакта бир өзгөрмөнү өзгөртүңүз, антпесе айырма маанисин жоготот.

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;

Асинхрондук бекітүү эмнени сатып алат жана канча турат

Асинхрондук бекітүүдө баштапкы алыскы катайтуунун тастыгын күтүүнү токтотот, ошондуктан барып-кайтуу бекітүү жолунан чыгат. Бекітүү кечигүүсү төмөндөйт жана экинчи эч ким көзөмөлдөбөгөн өлчөмдө артта калууга эркин. Бул күтүүнүн чыныгы оңдоосу жана убададагы чыныгы өзгөрүү.

Баа — калыбына келтирүү чекити тууралуу чечим. Эгер баштапкы өзүнүн журналы чындыгында колдоно алган бузулууга өтүү максатына жетпей өлсө, кызматты асинхрондук көчүрмөгө жылдыруу колдонмо буга чейин бекітілген деп билдирген транзакцияларды таштайт. Эч бир конфигурация диалогу муну ошондой көрсөтпөйт, анткени бул кабыл алынуучу жоготуу тууралуу ишкердик суроо, аткарымдуулук параметри эмес. Чыдалган жоготуу терезесин окуядан мурун жазыңыз, анын учурунда эмес.

Режимди маалымат ээси менен жазуу жүзүндө макулдашыңыз, артык көрүлгөн максат жеткиликсиз болгон учур үчүн бузулууга өтүү процедурасы менен бирге. Долбоор документиндеги синхрондук — операциялык нускама эмес, ал эми асинхрондук — кезектерди байкоону токтотууга лицензия эмес.

Кийин коргой алган оңдоону тандаңыз

Төрт ак ниеттүү вариант бар. Колдонмонун семантикасы топтоштурууга жол берген жерде болтурбоого боло турган бекітүү барып-кайтууларын кыскартыңыз; өлчөнгөн ташуу же кампа тоскоолдугун оңдоңуз, бул экинчиде чоңураак түтүктүн ордуна ылдамыраак журнал көлөмүн билдириши мүмкүн; барып-кайтуу азайышы үчүн репликаны жакындатыңыз; же коргоо саясатын бошоп, кененирээк жоготуу терезесин кабыл алыңыз. Ар бири кечигүүнү башка нерсени коротуп сатып алат, ал эми төртүнчүсү туруктуулукту коротот. Тандоодон мурун чыгымды атаңыз.

Жумуш жүктөмүнүн кечигүү максаты менен анын туруктуулук талабын бир убакта алдыңызда кармап чечим кабыл алыңыз, анткени бирин оптималдаштыруу экинчисин үнсүз коротот. Андан кийин өзгөртүүгө чейин өлчөгөн ошол транзакцияны кайра иштетиңиз. Бул санды кыймылдата албаган оңдоо — өзгөртүү билетин кийген божомол.

Өзгөртүү жазуусунда мурунку жана кийинки көрсөткүчтөрдү сактаңыз. Антпесе жай жазууну көргөн кийинки адам иликтөөнү башынан кайталап, дагы туннелди күнөөлөөдөн баштайт.