ทำไม VPN ที่เร็วก็ยังทำให้การคอมมิต SQL แบบซิงโครนัสช้าลง

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

เริ่มจากชนิดการรอ บนไพรมารี

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

เรียงลำดับภาระงานตามความถี่ของการคอมมิตก่อนสรุปสิ่งใดเกี่ยวกับลิงก์

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

ติดตามการตอบรับไปจนถึงเซคันดารี

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

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

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;

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

วัดเส้นทาง ไม่ใช่วัดลิงก์

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

รักษาความปลอดภัยของการรับส่งฐานข้อมูลและการควบคุมการเข้าถึงให้ครบถ้วนขณะวัด การวัดเส้นทางไม่เคยเป็นเหตุผลในการข้ามสิ่งเหล่านี้

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

โหมดอะซิงโครนัสเปลี่ยนอะไรจริงๆ

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

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

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