กรณีที่สงสัยของ HADR_SYNC_COMMIT รออยู่

เรากำลังสังเกตเห็นรูปแบบที่น่าสนใจสำหรับการHADR_SYNC_COMMITรอคอยในสภาพแวดล้อมของเรา เรามีแบบจำลองสามแบบ หนึ่งหลักรองหนึ่งซิงค์รองและหนึ่ง async รองในดาต้าเซ็นเตอร์และเราเพิ่งเพิ่มแบบจำลองASYNCอีกสามรายการในดาต้าเซ็นเตอร์อีกอัน (ห่างกันประมาณ 2400 ไมล์)

นับตั้งแต่เราเริ่มสังเกตเห็นการเพิ่มขึ้นอย่างมากของการHADR_SYNC_COMMITรอคอย เมื่อเราดูเซสชันที่ใช้งานอยู่เราจะเห็นCOMMIT TRANSACTIONข้อความค้นหามากมายที่รอการจำลอง SYNC

จากภาพหน้าจอเราสามารถเห็นได้อย่างชัดเจนว่ามีการHADR_SYNC_COMMITรอคอยในวันที่ 29 มิถุนายนและในที่สุดเราก็ลดลง 'สอง' ของสาม async แบบจำลองในดาต้าเซ็นเตอร์ระยะไกลในช่วงเที่ยงวันที่ 1 กรกฎาคม ที่ลดลงเวลารออย่างมากพร้อมกับมัน

สิ่งที่เราตรวจสอบแล้ว - บันทึกการส่งคิว, ทำซ้ำคิว, เวลาเพิ่มความแข็งครั้งล่าสุดและเวลาส่งมอบครั้งสุดท้ายบนเรพลิคาระยะไกล เรามีธุรกรรมเล็ก ๆ ต่อเนื่องในช่วงเวลาทำการดังนั้นคิวการส่งจึงค่อนข้างเล็กในเวลาที่กำหนด (ที่ใดก็ได้ระหว่าง 60KB และ 1MB)
รีโมตรีโมตเกือบจะซิงค์กันแล้วมีความแตกต่างกันเล็กน้อยระหว่างเวลาการส่งข้อมูลครั้งล่าสุดและเวลาการทำให้แข็งครั้งสุดท้ายสำหรับบุคคลใด ๆ ในแบบจำลอง

ไพพ์เน็ตเวิร์กคือ 10G และเราปรับเปลี่ยนขนาดบัฟเฟอร์การส่งจาก 256 megs เป็น 2 gigs ซึ่งสร้างขึ้นภายใต้สมมติฐานว่าเน็ตเวิร์กวางแพ็กเก็ตและส่งสัญญาณอีกครั้ง วิธีที่ดูเหมือนจะไม่ช่วยมากทั้ง

ดังนั้นฉันสงสัยว่าแบบจำลองASYNCเกี่ยวข้องกับการHADR_SYNC_COMMITรอคอยอย่างไร แบบจำลองSYNCไม่ควรขึ้นอยู่กับการรอประเภทนี้เพียงลำพังฉันหายไปไหน

ก่อนอื่นคำอธิบายของเหตุการณ์รอที่คำถามของคุณเกี่ยวข้องคือ:

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

https://msdn.microsoft.com/en-us/library/ms179984.aspx

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

ที่มา: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

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

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

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO