ทำไมคอมมิต SQL แบบซิงโครนัสของคุณจึงรอการไปกลับของ VPN

ความหน่วงในการเขียนพุ่งขึ้นหลังจากย้ายรีพลิกาไปยังไซต์ที่สอง และอุโมงค์เป็นองค์ประกอบใหม่ที่สุด จึงตกเป็นผู้รับผิด อุโมงค์อาจบริสุทธิ์ก็ได้: ภายในกลุ่มความพร้อมใช้งานที่ใช้คอมมิตแบบซิงโครนัส ไพรมารีจะยืนยันคอมมิตไม่ได้จนกว่าการเขียนล็อกระยะไกลจะเสร็จสิ้น ทุกธุรกรรมจึงจ่ายค่าไปกลับไม่ว่าลิงก์จะรับส่งได้กี่เมกะบิตก็ตาม ทรูพุตวัดไบต์ต่อวินาที ความหน่วงวัดว่าการแลกเปลี่ยนหนึ่งครั้งใช้เวลานานเท่าใด และคอมมิตต้องการเพียงการแลกเปลี่ยนเล็ก ๆ หนึ่งครั้งเพื่อให้เสร็จ ตัวเลขเดียวตัดสินข้อโต้แย้งได้: ระยะเวลาคอมมิตของธุรกรรมเล็ก ๆ ที่วัดภายในฐานข้อมูลความพร้อมใช้งาน แล้ววัดซ้ำกับตารางภายในเครื่องบนอินสแตนซ์เดียวกัน

สิ่งที่ไพรมารีรออยู่จริง ๆ

ภายใต้คอมมิตแบบซิงโครนัส ไพรมารีจะกักการยืนยันคอมมิตไว้จนกว่าคู่จะยืนยันว่าบันทึกล็อกของตนถูกทำให้คงทนแล้ว คงทนหมายถึงเขียนลงล็อกธุรกรรมของเซคันดารีอย่างถาวร ไม่ใช่เล่นซ้ำลงในหน้าข้อมูล รีดูอาจตามหลังเป็นนาทีโดยไม่เพิ่มแม้แต่หนึ่งมิลลิวินาทีให้กับคอมมิตของไพรมารี

เอกสารของ Microsoft เกี่ยวกับโหมดความพร้อมใช้งาน อธิบายการจับมือนั้นและสิ่งที่แพลตฟอร์มทำเมื่อคู่หลุดออกไป รีพลิกาที่ทำเครื่องหมายว่าซิงโครนัสเป็นกฎเกี่ยวกับการรอ ไม่ใช่คำสัญญาถาวรว่าจะมีสำเนาระยะไกลที่แข็งแรงสำหรับทุกคอมมิต เส้นทางที่ตัดการเชื่อมต่อถูกนิยามแยกต่างหาก และไม่ใช่แค่คอมมิตล้มเหลว

ดังนั้นการรอที่คุณเห็นคือผลรวมของการขนส่งล็อก การจัดตารางบนโฮสต์ทั้งสอง และการเขียนลงที่เก็บระยะไกล เซคันดารีที่มีปริมาณล็อกอิ่มตัวจะเพิ่มเวลาที่ไม่มีการทดสอบความเร็วใดแสดงให้เห็น ดิสก์นั้นแทบไม่เคยถูกวัดเมื่อข้อร้องเรียนระบุถึง VPN

แบนด์วิดท์ไม่ใช่ความหน่วงไปกลับ

การทดสอบความเร็วจะท่วมเส้นทางชั่วครู่และรายงานอัตรา คอมมิตถามสิ่งที่แคบกว่า: ข้อความเล็ก ๆ ใช้เวลานานเท่าใดในการไปถึงอีกฝั่ง ถูกจัดเก็บ และกลับมา ความยาวเส้นทาง คิว และการสูญหายของแพ็กเก็ตเป็นตัวกำหนดตัวเลขนั้น และไม่มีสิ่งใดดีขึ้นเมื่อผู้ให้บริการเพิ่มเพดาน

อุโมงค์ที่ «เร็ว» จึงอาจเพิ่มบทลงโทษที่มองเห็นได้ให้กับภาระงานที่เขียนหนักซึ่งสร้างจากธุรกรรมเล็ก ๆ ต่อเนื่องกันจำนวนมาก ไบต์รวมเท่าเดิมที่แบ่งเป็นหนึ่งพันคอมมิตจ่ายค่าไปกลับหนึ่งพันครั้ง การถ่ายโอนครั้งใหญ่จ่ายเพียงครั้งเดียว

ขอให้เจ้าของเครือข่ายวัดความหน่วงและการสูญหายบนเส้นทางของรีพลิกาเองภายใต้ภาระที่เป็นตัวแทน 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;

ผลลัพธ์แรกแยกการขนส่งล็อกออกจากรีดู log_send_queue_size ที่เพิ่มขึ้นในขณะที่ redo_queue_size ทรงตัวหมายความว่าล็อกยังมาไม่ถึง ตรงกันข้ามหมายความว่ามาแล้วและการเล่นซ้ำตามหลัง มีเพียงกรณีแรกเท่านั้นที่อยู่บนเส้นทางคอมมิต

ผลลัพธ์ที่สองยืนยันว่ารีพลิกาใดถูกกำหนดค่าตามที่คุณคิดจริง ๆ เพราะโหมดที่เปลี่ยนไประหว่างเหตุการณ์ก่อนหน้ามักจะยังคงถูกเปลี่ยนและไม่มีเอกสารกำกับ อ่านแถวที่คุณสนใจแทนค่าเริ่มต้นของกลุ่ม availability_mode_desc และ failover_mode_desc เป็นรายรีพลิกา secondary_lag_seconds มีอยู่เฉพาะใน SQL Server 2016 และใหม่กว่า ดังนั้นบิลด์เก่าจะเหลือให้คุณเพียงคอลัมน์คิวส่งและรีดู

จากนั้นวัดการเขียนที่เป็นตัวแทนแทนการเชื่อถือค่าเฉลี่ยบนแดชบอร์ด รันบล็อกด้านล่างในฐานข้อมูลความพร้อมใช้งาน แล้วรันอีกครั้งกับรูปทรงตารางเดียวกันในฐานข้อมูลนอกกลุ่มบนอินสแตนซ์เดียวกัน ช่องว่างระหว่างสองระยะเวลาคือราคาหยาบ ๆ ของล็อกระยะไกล และในการโต้แย้งกับทีมเครือข่ายมันยืนได้ดีกว่ากราฟมาก หลังจากนั้นเปลี่ยนตัวแปรทีละตัว ไม่เช่นนั้นช่องว่างจะไม่มีความหมายอีก

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;

คอมมิตแบบอะซิงโครนัสซื้ออะไร และแลกอะไร

ด้วยคอมมิตแบบอะซิงโครนัส ไพรมารีจะหยุดรอการยืนยันการทำให้คงทนระยะไกล การไปกลับจึงออกจากเส้นทางคอมมิต ความหน่วงของคอมมิตลดลงและเซคันดารีมีอิสระที่จะตามหลังในปริมาณที่ไม่มีใครควบคุม นั่นคือการแก้ไขที่แท้จริงสำหรับการรอและการเปลี่ยนแปลงที่แท้จริงของคำสัญญา

ราคาคือการตัดสินใจเรื่องจุดกู้คืน หากไพรมารีตายก่อนที่ล็อกของมันจะไปถึงเป้าหมายเฟลโอเวอร์ที่คุณใช้ได้จริง การย้ายบริการไปยังสำเนาอะซิงโครนัสจะทิ้งธุรกรรมที่แอปพลิเคชันรายงานว่าได้คอมมิตแล้ว ไม่มีกล่องโต้ตอบการกำหนดค่าใดนำเสนอเช่นนั้น เพราะมันเป็นคำถามทางธุรกิจเรื่องการสูญเสียที่ยอมรับได้ ไม่ใช่การตั้งค่าประสิทธิภาพ เขียนหน้าต่างการสูญเสียที่ยอมรับได้ก่อนเหตุการณ์ ไม่ใช่ระหว่างนั้น

ตกลงโหมดกับเจ้าของข้อมูลเป็นลายลักษณ์อักษร พร้อมขั้นตอนเฟลโอเวอร์สำหรับกรณีที่เป้าหมายที่ต้องการไม่พร้อมใช้งาน ซิงโครนัสในเอกสารออกแบบไม่ใช่คู่มือปฏิบัติการ และอะซิงโครนัสไม่ใช่ใบอนุญาตให้หยุดเฝ้าดูคิว

เลือกวิธีแก้ไขที่คุณปกป้องได้ในภายหลัง

มีสี่ทางเลือกที่ซื่อสัตย์ ตัดการไปกลับของคอมมิตที่หลีกเลี่ยงได้ในจุดที่ความหมายของแอปพลิเคชันอนุญาตให้จัดกลุ่ม แก้ปัญหาคอขวดของการขนส่งหรือที่เก็บที่คุณวัดแล้ว ซึ่งอาจหมายถึงปริมาณล็อกที่เร็วกว่าบนเซคันดารีแทนท่อที่ใหญ่กว่า ย้ายรีพลิกาให้ใกล้ขึ้นเพื่อให้การไปกลับหดลง หรือผ่อนนโยบายการป้องกันและยอมรับหน้าต่างการสูญเสียที่กว้างขึ้น แต่ละทางซื้อความหน่วงด้วยการจ่ายสิ่งอื่น และทางที่สี่จ่ายความทนทาน ระบุค่าใช้จ่ายก่อนเลือก

ตัดสินใจโดยมีเป้าหมายความหน่วงของภาระงานและข้อกำหนดความทนทานอยู่ตรงหน้าพร้อมกัน เพราะการปรับแต่งอย่างหนึ่งจะจ่ายอีกอย่างเงียบ ๆ จากนั้นรันธุรกรรมเดิมที่คุณวัดก่อนการเปลี่ยนแปลงอีกครั้ง วิธีแก้ไขที่ไม่สามารถขยับตัวเลขนั้นได้คือการเดาที่สวมตั๋วเปลี่ยนแปลง

เก็บบันทึกการอ่านก่อนและหลังไว้ในบันทึกการเปลี่ยนแปลง ไม่เช่นนั้นคนถัดไปที่เห็นการเขียนช้า ๆ จะทำการสอบสวนซ้ำตั้งแต่ต้นและเริ่มโทษอุโมงค์อีกครั้ง