რატომ ელოდება თქვენი სინქრონული SQL commit VPN-ის ორმხრივ მოგზაურობას

ჩაწერის შეყოვნება გადახტა მას შემდეგ, რაც რეპლიკა მეორე საიტზე გადავიდა, და გვირაბი ყველაზე ახალი კომპონენტია, ამიტომ ბრალს ის იღებს. გვირაბი უდანაშაულო შეიძლება იყოს: სინქრონული commit-ის მქონე ხელმისაწვდომობის ჯგუფში პირველადი ვერ დაადასტურებს commit-ს, სანამ დისტანციური ლოგის ჩაწერა არ დასრულდება, ამიტომ ყოველი ტრანზაქცია იხდის ორმხრივ მოგზაურობას, რამდენი მეგაბიტიც არ უნდა გადაიტანოს ხაზმა. გამტარუნარიანობა ზომავს ბაიტებს წამში, შეყოვნება ზომავს, რამდენ ხანს გრძელდება ერთი გაცვლა, და commit-ს დასასრულებლად მხოლოდ ერთი პატარა გაცვლა სჭირდება. ერთი რიცხვი წყვეტს კამათს: პატარა ტრანზაქციის commit-ის ხანგრძლივობა, გაზომილი ხელმისაწვდომობის მონაცემთა ბაზაში და შემდეგ ისევ იმავე ინსტანსის ლოკალური ცხრილის წინააღმდეგ.

რას ელოდება პირველადი სინამდვილეში

სინქრონული commit-ის დროს პირველადი იკავებს commit-ის დადასტურებას, სანამ პარტნიორი არ დაადასტურებს, რომ მისი ლოგის ჩანაწერები გამაგრებულია. გამაგრებული ნიშნავს მეორადის ტრანზაქციის ლოგში მდგრად ჩაწერას, და არა მის მონაცემთა გვერდებში ხელახლა გაშვებას. redo შეიძლება წუთებით ჩამორჩეს, პირველადის commit-ს ერთი მილიწამიც რომ არ დაამატოს.

Microsoft-ის დოკუმენტაცია ხელმისაწვდომობის რეჟიმებზე აღწერს ამ ხელის ჩამორთმევას და იმას, რას აკეთებს პლატფორმა, როცა პარტნიორი გამოვარდება. სინქრონულად მონიშნული რეპლიკა ლოდინის წესია და არა მუდმივი დაპირება, რომ ყოველი commit-ისთვის არსებობს ჯანსაღი დისტანციური ასლი. გათიშული გზა ცალკეა განსაზღვრული და ეს მხოლოდ ის არ არის, რომ commit ვერ სრულდება.

ასე რომ, თქვენ მიერ დანახული ლოდინი ჯამია: ლოგის ტრანსპორტირება, დაგეგმვა ორივე ჰოსტზე და დისტანციურ საცავში ჩაწერა. გაჯერებული ლოგის მოცულობის მეორადი ამატებს დროს, რომელსაც არც ერთი სიჩქარის ტესტი არ აჩვენებს. ეს დისკი იშვიათად იზომება, როცა საჩივარი VPN-ს ახსენებს.

გამტარუნარიანობა არ არის ორმხრივი მოგზაურობის შეყოვნება

სიჩქარის ტესტი მოკლედ ატბება გზას და იტყობინება სიჩქარეს. commit ითხოვს უფრო ვიწრო რამეს: რამდენ ხანს სჭირდება პატარა შეტყობინებას მეორე მხარის მიღწევას, შენარჩუნებას და დაბრუნებას. გზის სიგრძე, რიგები და პაკეტების დაკარგვა განსაზღვრავს ამ რიცხვს და არც ერთი მათგანი არ უმჯობესდება, როცა პროვაიდერი ზღვარს აწევს.

ამიტომ «სწრაფმა» გვირაბმა შეიძლება დანახული ჯარიმა დაუმატოს ჩაწერით დატვირთულ სამუშაო დატვირთვას, რომელიც ბევრი პატარა მიმდევრობითი ტრანზაქციისგან შედგება. იგივე ბაიტების ჯამი ათას commit-ზე გაყოფილი ორმხრივ მოგზაურობას ათასჯერ იხდის; ერთი მასობრივი გადაცემა მას ერთხელ იხდის.

სთხოვეთ ქსელის მფლობელს, გაზომოს შეყოვნება და დანაკარგი თავად რეპლიკის მარშრუტზე წარმომადგენლობითი დატვირთვის ქვეშ. ping საოფისე ლეპტოპიდან VPN-ის კარიბჭემდე, ან სიჩქარის ტესტი ახლო კვანძამდე, თითქმის არაფერს მიაკუთვნებს იმ მარშრუტს, რომლითაც ლოგი რეალურად მოძრაობს. მოაწყვეთ, რომ გაზომვის ფანჯარა დაემთხვეს იმ საათებს, როცა ჩაწერა ნელია.

წაიკითხეთ რეპლიკის მდგომარეობა, სანამ რამეს შეცვლით

დაიწყეთ იმით, რასაც ინსტანსები საკუთარ თავზე იტყობინებიან, რადგან ორი მხარე შეიძლება არ დაეთანხმოს, რამდენად ჯანსაღია პარტნიორობა და დაშბორდის საშუალო მალავს, რომელი რიგი მოძრაობს. ქვემოთ მოცემული მოთხოვნები სხვადასხვა კითხვას პასუხობს: ერთი კითხულობს რეპლიკაციის მდგომარეობას თითოეული ბაზისთვის, მეორე კითხულობს, როგორ არის კონფიგურირებული თითოეული რეპლიკა. გაუშვით ორივე, სანამ რეჟიმს შეეხებით.

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 ბრტყელი რჩება, ნიშნავს, რომ ლოგი არ მოსულა; პირიქით ნიშნავს, რომ ის მოვიდა და გამეორება ჩამორჩება. მხოლოდ პირველი შემთხვევა ზის commit-ის გზაზე.

მეორე შედეგი ადასტურებს, რომელი რეპლიკები არიან რეალურად კონფიგურირებული ისე, როგორც თქვენ ვარაუდობთ, რადგან ადრინდელი ინციდენტის დროს შეცვლილი რეჟიმი ჩვეულებრივ შეცვლილი და არადოკუმენტირებული რჩება. წაიკითხეთ ის სტრიქონი, რომელიც გაინტერესებთ, ჯგუფის ნაგულისხმევის ნაცვლად: 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;

რას ყიდულობს ასინქრონული commit და რა ღირს

ასინქრონული commit-ით პირველადი წყვეტს დისტანციური გამაგრების დადასტურების ლოდინს, ამიტომ ორმხრივი მოგზაურობა ტოვებს commit-ის გზას. commit-ის შეყოვნება ეცემა და მეორადი თავისუფალია ჩამორჩეს იმ რაოდენობით, რომელსაც არავინ აკონტროლებს. ეს ნამდვილი შესწორებაა ლოდინისთვის და ნამდვილი ცვლილება დაპირებაში.

ფასი აღდგენის წერტილის გადაწყვეტილებაა. თუ პირველადი მოკვდება მანამ, სანამ მისი ლოგი მიაღწევს მარცხზე გადართვის იმ სამიზნეს, რომელსაც ნამდვილად გამოიყენებთ, სერვისის ასინქრონულ ასლზე გადატანა ყრის იმ ტრანზაქციებს, რომლებიც აპლიკაციამ უკვე commit-ად გამოაცხადა. არც ერთი კონფიგურაციის დიალოგი ასე არ წარმოადგენს მას, რადგან ეს მისაღები დანაკარგის ბიზნეს კითხვაა და არა წარმადობის პარამეტრი. ჩაწერეთ ასატანი დანაკარგის ფანჯარა ინციდენტამდე და არა მის დროს.

შეთანხმდით რეჟიმზე მონაცემების მფლობელთან წერილობით, ერთად მარცხზე გადართვის პროცედურასთან იმ შემთხვევისთვის, როცა სასურველი სამიზნე მიუწვდომელია. დიზაინის დოკუმენტში სინქრონული ოპერაციული სახელმძღვანელო არ არის და ასინქრონული რიგებზე დაკვირვების შეწყვეტის ლიცენზია არ არის.

აირჩიეთ შესწორება, რომლის დაცვაც შემდეგ შეგიძლიათ

არსებობს ოთხი პატიოსანი ვარიანტი. მოჭერით თავიდან აცილებადი commit-ის ორმხრივი მოგზაურობები იქ, სადაც აპლიკაციის სემანტიკა პარტიულ დამუშავებას იძლევა; შეაკეთეთ თქვენ მიერ გაზომილი ტრანსპორტის ან საცავის ბოთლის ყელი, რაც შეიძლება ნიშნავდეს უფრო სწრაფ ლოგის მოცულობას მეორადზე და არა უფრო დიდ მილს; მიაახლოვეთ რეპლიკა, რომ ორმხრივი მოგზაურობა შემცირდეს; ან შეასუსტეთ დაცვის პოლიტიკა და მიიღეთ უფრო ფართო დანაკარგის ფანჯარა. თითოეული ყიდულობს შეყოვნებას სხვა რამის დახარჯვით და მეოთხე ხარჯავს გამძლეობას. დაასახელეთ ხარჯი, სანამ აირჩევთ.

გადაწყვიტეთ, როცა სამუშაო დატვირთვის შეყოვნების მიზანი და მისი გამძლეობის მოთხოვნა ერთდროულად თქვენ წინაშეა, რადგან ერთის ოპტიმიზაცია ჩუმად ხარჯავს მეორეს. შემდეგ ისევ გაუშვით იგივე ტრანზაქცია, რომელიც შეცვლამდე გაზომეთ. შესწორება, რომელსაც ეს რიცხვი ვერ აამოძრავებს, ცვლილების ბილეთიანი ვარაუდია.

შეინახეთ ჩვენებები ცვლილებამდე და შემდეგ ცვლილების ჩანაწერში. თორემ შემდეგი ადამიანი, რომელიც ნელ ჩაწერას დაინახავს, გამოძიებას თავიდან იმეორებს და ისევ გვირაბის დადანაშაულებით იწყებს.