สวัสดีทุกคนและขอขอบคุณล่วงหน้าสำหรับความช่วยเหลือของคุณ เรากำลังเผชิญกับความท้าทายกับกลุ่มความพร้อมใช้งานของ SQL Server 2017
พื้นหลัง
บริษัท เป็นซอฟต์แวร์ back-end B2B สำหรับการค้าปลีก ประมาณ 500 ฐานข้อมูลผู้เช่ารายเดียวและ 5 ฐานข้อมูลที่ใช้ร่วมกันที่ใช้โดยผู้เช่าทั้งหมด ส่วนใหญ่จะอ่านคุณสมบัติของเวิร์กโหลดและฐานข้อมูลส่วนใหญ่มีกิจกรรมต่ำมาก
เซิร์ฟเวอร์การผลิตจริงที่โฮสต์ที่ co-location เพิ่งได้รับการอัพเกรดจาก SQL Server 2014 Enterprise บน Windows Server 2012 ในการกำหนดค่า SAN / FCI ที่ใช้ร่วมกันไปเป็น SQL Server 2017 Enterprise บน Windows Server 2016 บน 2 socket / 32 core / 768 GB RAM และท้องถิ่น ไดรฟ์ SSD ที่ใช้ AlwaysOn AG การรับส่งข้อมูลของ AG ใช้พอร์ต 10G NIC เฉพาะสำหรับเชื่อมต่อด้วยสายเคเบิล
ความต้องการของพวกเขาคือสำหรับฐานข้อมูลทั้งหมดที่จะล้มเหลวด้วยกันดังนั้นพวกเขาจึงต้องทำให้พวกเขาทั้งหมดใน AG เดียว มันเป็นแบบจำลองซิงโครนัสเดียวที่อ่านไม่ได้บนเซิร์ฟเวอร์ที่เหมือนกัน
เซิร์ฟเวอร์ใหม่เริ่มใช้งานตั้งแต่เดือนมิถุนายน 2561 มีการติดตั้ง CU ล่าสุด (CU7 ในเวลานั้น) และมีการติดตั้งการปรับปรุง windows และระบบทำงานได้ดี ประมาณหนึ่งเดือนต่อมาหลังจากอัปเดตเซิร์ฟเวอร์จาก CU7 เป็น CU9 พวกเขาเริ่มสังเกตเห็นความท้าทายต่อไปนี้ซึ่งแสดงตามลำดับความสำคัญ
เราได้ทำการตรวจสอบเซิร์ฟเวอร์โดยใช้ SQL Sentry และสังเกตว่าไม่มีปัญหาคอขวดทางกายภาพ ตัวชี้วัดสำคัญทั้งหมดดูดี CPU เฉลี่ย 20% โดยทั่วไปแล้ว IO ครั้งน้อยกว่า 1ms, RAM ไม่ได้ใช้อย่างเต็มที่และเครือข่าย <1%
ความท้าทาย
อาการดูเหมือนจะดีขึ้นหลังจากเกิดความล้มเหลว แต่กลับมาภายในสองสามวันโดยไม่คำนึงว่าเซิร์ฟเวอร์ใดเป็นเซิร์ฟเวอร์หลัก - อาการจะเหมือนกันในเซิร์ฟเวอร์ทั้งสอง
หมดเวลาลูกค้าเป็นระยะ ๆ และการเชื่อมต่อล้มเหลวเช่น
... เกิดข้อผิดพลาดขณะสร้างการเชื่อมต่อ ...
หรือ
การหมดเวลาการดำเนินการหมดอายุแล้ว
บางครั้งสิ่งเหล่านี้จะดำเนินต่อไปเป็นเวลานานถึง 40 วินาทีแล้วจึงยุบลง
ธุรกรรมการสำรองข้อมูลบันทึกธุรกรรมใช้เวลา 10X นานกว่าจะเสร็จสมบูรณ์กว่า แต่ก่อน ก่อนหน้านี้ใช้เวลา 2 - 3 นาทีในการสำรองบันทึกของฐานข้อมูลทั้งหมด 500 ตอนนี้ใช้เวลา 15-25 เราได้ตรวจสอบแล้วว่าการสำรองข้อมูลนั้นทำงานได้ดีด้วยปริมาณงานที่ดี อย่างไรก็ตามมีความล่าช้าเล็กน้อยหลังจากการสำรองข้อมูลของบันทึกหนึ่งรายการและก่อนเริ่มต้นการติดตามครั้งถัดไป มันเริ่มต้นต่ำมาก แต่ภายในหนึ่งหรือสองวันถึง 2-3 วินาที คูณด้วย 500 ฐานข้อมูลและมีความแตกต่าง
บางครั้งฐานข้อมูลสุ่มที่ดูเหมือนจะติดอยู่ในสถานะ "ไม่ซิงโครไนซ์" หลังจากเกิดความล้มเหลวด้วยตนเอง วิธีเดียวในการแก้ไขปัญหานี้คือการเริ่มบริการเซิร์ฟเวอร์ SQL บนแบบจำลองรองหรือเพื่อลบและเข้าร่วมฐานข้อมูลเหล่านี้อีกครั้งเพื่อ AG
ปัญหาอื่นที่แนะนำโดย CU10 (และไม่ได้รับการแก้ไขใน CU11): การเชื่อมต่อกับการหมดเวลาสำรองในการบล็อกบน master.sys.database และแม้กระทั่งไม่สามารถใช้การสำรวจวัตถุ SSMS สำหรับแบบจำลองรอง สาเหตุหลักน่าจะเป็นการบล็อกโดย Microsoft SQL Server VSS writer ที่ออกแบบสอบถามต่อไปนี้:
select name, recovery_model_desc, state_desc, CONVERT(integer, is_in_standby), ISNULL(source_database_id,0) from master.sys.databases
ข้อสังเกต
ฉันเชื่อว่าฉันพบปืนสูบบุหรี่ในบันทึกข้อผิดพลาด บันทึกข้อผิดพลาดเต็มไปด้วยข้อความ AG ซึ่งมีข้อความว่า 'ให้ข้อมูลเท่านั้น' แต่ดูเหมือนว่าไม่ใช่เรื่องปกติ แต่อย่างใดและมีความสัมพันธ์อย่างมากกับความถี่ในการเกิดข้อผิดพลาดของแอปพลิเคชัน
ข้อผิดพลาดมีหลายประเภทและมีลำดับดังนี้
DbMgrPartnerCommitPolicy :: SetSyncState: GUID
DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID
การเชื่อมต่อกลุ่มความพร้อมใช้งาน AlwaysOn เชื่อมต่อกับฐานข้อมูลรองสิ้นสุดลงสำหรับฐานข้อมูลหลัก 'XYZ' ในแบบจำลองความพร้อมใช้งาน 'DB' ด้วย ID แบบจำลอง: {GUID} นี่เป็นข้อความให้ข้อมูลเท่านั้น กระทำของผู้ใช้ไม่จำเป็นต้องมี.
การเชื่อมต่อกลุ่มความพร้อมใช้งาน AlwaysOn เชื่อมต่อกับฐานข้อมูลรองที่สร้างขึ้นสำหรับฐานข้อมูลหลัก 'ABC' ในแบบจำลองความพร้อมใช้งาน 'DB' ด้วย ID แบบจำลอง: {GUID} นี่เป็นข้อความให้ข้อมูลเท่านั้น กระทำของผู้ใช้ไม่จำเป็นต้องมี.
บางวันมีคนนับหมื่นคน
บทความนี้กล่าวถึงลำดับของข้อผิดพลาดประเภทเดียวกันใน SQL 2016 และที่นั่นบอกว่ามันผิดปกติ นอกจากนี้ยังอธิบายปรากฏการณ์ 'ไม่ซิงโครไนซ์' หลังจากเกิดความล้มเหลว ปัญหาที่กล่าวถึงสำหรับปี 2559 และได้รับการแก้ไขเมื่อต้นปีใน CU อย่างไรก็ตามเป็นการอ้างอิงที่เกี่ยวข้องเท่านั้นที่ฉันสามารถค้นหาข้อความ 2 ประเภทแรกนอกเหนือจากการอ้างอิงข้อความเริ่มต้นเริ่มต้นอัตโนมัติซึ่งไม่ควรเป็นกรณีที่นี่เนื่องจาก AG ได้จัดตั้งขึ้นแล้ว
นี่คือสรุปข้อผิดพลาดรายวันเมื่อสัปดาห์ที่แล้วสำหรับวันที่มีข้อผิดพลาด> 10K ต่อประเภทในรายการหลัก (รายการที่สองแสดงว่า 'สูญเสียการเชื่อมต่อกับหลัก ... '):
Date Message Type (First 50 characters) Num Errors
10/8/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 61953
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 56812
10/4/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 27951
10/2/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 24158
10/7/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 14904
10/8/2018 Always On Availability Groups connection with seco 13301
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4 11057
10/3/2018 Always On Availability Groups connection with seco 10080
นอกจากนี้เรายังเห็นข้อความ "แปลก ๆ " เช่น:
ฐานข้อมูลกลุ่มความพร้อมใช้งาน "DB" กำลังเปลี่ยนบทบาทจาก "SECONDARY" เป็น "SECONDARY" เนื่องจากเซสชันการมิรเรอร์หรือกลุ่มความพร้อมใช้งานล้มเหลวเนื่องจากการซิงโครไนซ์บทบาท นี่เป็นข้อความให้ข้อมูลเท่านั้น กระทำของผู้ใช้ไม่จำเป็นต้องมี.
... ในบรรดาโฮสต์ของการเปลี่ยนสถานะจาก "SECONDARY" เป็น "RESOLVING"
หลังจาก failover ด้วยตนเองระบบอาจใช้เวลาหลายวันโดยไม่มีข้อความเดียวของประเภทเหล่านี้และในทันทีโดยไม่มีเหตุผลที่ชัดเจนเราจะได้รับหลายพันรายการพร้อมกันซึ่งทำให้เซิร์ฟเวอร์ไม่ตอบสนองและทำให้แอปพลิเคชันไม่ทำงาน หมดเวลาเชื่อมต่อ นี่เป็นข้อผิดพลาดที่สำคัญเนื่องจากแอปพลิเคชันบางตัวไม่มีกลไกการลองใหม่จึงอาจสูญเสียข้อมูล เมื่อมีข้อผิดพลาดเกิดขึ้นการรอต่อไปนี้จะสร้างจรวดประเภทท้องฟ้า นี่แสดงให้เห็นการรอทันทีหลังจาก AG ดูเหมือนจะสูญเสียการเชื่อมต่อกับฐานข้อมูลทั้งหมดในครั้งเดียว:
ประมาณ 30 วินาทีต่อมาทุกอย่างกลับสู่ปกติในแง่ของการรอ แต่ข้อความ AG เก็บน้ำท่วมบันทึกข้อผิดพลาดในอัตราที่แตกต่างกันและในช่วงเวลาที่แตกต่างกันของวันที่ดูเหมือนสุ่มเวลารวมทั้งนอกชั่วโมงเร่งด่วน การเพิ่มเวิร์กโหลดพร้อมกันระหว่างการระเบิดข้อผิดพลาดเหล่านี้ทำให้สิ่งเลวร้ายยิ่งกว่าเดิม หากฐานข้อมูลเพียงไม่กี่ฐานถูกตัดการเชื่อมต่อโดยทั่วไปแล้วจะไม่ทำให้การเชื่อมต่อหมดเวลาเนื่องจากมีการแก้ไขอย่างรวดเร็วเพียงพอในตัวของมันเอง
เราพยายามตรวจสอบว่าเป็น CU9 แน่นอนที่เริ่มต้นปัญหา แต่เราสามารถลดระดับโหนดทั้งสองเป็น CU9 เท่านั้น ความพยายามในการดาวน์เกรดทั้งโหนดเป็น CU8 ส่งผลให้โหนดนั้นค้างอยู่ในสถานะ 'การแก้ไข' ที่แสดงข้อผิดพลาดเดียวกันในบันทึก:
ไม่สามารถอ่านการกำหนดค่าที่คงอยู่ของกลุ่มความพร้อมใช้ตลอดเวลาพร้อมด้วย ID ทรัพยากรที่สอดคล้องกัน '…. การกำหนดค่าที่เก็บไว้จะถูกเขียนโดย SQL Server เวอร์ชันที่สูงกว่าซึ่งโฮสต์การจำลองความพร้อมใช้งานหลัก อัพเกรดอินสแตนซ์ SQL Server เฉพาะที่เพื่ออนุญาตให้เรพลิกาความพร้อมใช้งานในท้องถิ่นกลายเป็นเรพลิคารอง
ซึ่งหมายความว่าเราจะต้องแนะนำเวลาดาวน์เพื่อให้สามารถดาวน์เกรดทั้งสองโหนดเป็น CU8 ในเวลาเดียวกัน สิ่งนี้ยังแสดงให้เห็นว่ามีการปรับปรุงที่สำคัญของ AG ซึ่งอาจอธิบายสิ่งที่เรากำลังประสบอยู่
เราได้ลองปรับ max_worker_threads จากค่าเริ่มต้นเป็น 0 (= 960 ในกล่องของเราตามบทความนี้ ) ค่อยๆสูงถึง 2,000 โดยไม่มีผลกระทบที่สังเกตได้จากข้อผิดพลาด
เราจะทำอย่างไรเพื่อแก้ปัญหาการยกเลิกการเชื่อมต่อ AG มีใครที่ประสบปัญหาคล้ายกันบ้างไหม บุคคลอื่นที่มีฐานข้อมูลจำนวนมากใน AG อาจเห็นข้อความที่คล้ายกันในบันทึกข้อผิดพลาด SQL ที่เริ่มต้นด้วย CU9 หรือ CU8 หรือไม่
ขอบคุณล่วงหน้าสำหรับความช่วยเหลือใด ๆ !