SQL Server 2017 ที่มีฐานข้อมูล 500 - AG บ่อยครั้งตัดการเชื่อมต่อตั้งแต่ CU9


15

สวัสดีทุกคนและขอขอบคุณล่วงหน้าสำหรับความช่วยเหลือของคุณ เรากำลังเผชิญกับความท้าทายกับกลุ่มความพร้อมใช้งานของ 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%

ความท้าทาย

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

  1. หมดเวลาลูกค้าเป็นระยะ ๆ และการเชื่อมต่อล้มเหลวเช่น

    ... เกิดข้อผิดพลาดขณะสร้างการเชื่อมต่อ ...

    หรือ

    การหมดเวลาการดำเนินการหมดอายุแล้ว

    บางครั้งสิ่งเหล่านี้จะดำเนินต่อไปเป็นเวลานานถึง 40 วินาทีแล้วจึงยุบลง

  2. ธุรกรรมการสำรองข้อมูลบันทึกธุรกรรมใช้เวลา 10X นานกว่าจะเสร็จสมบูรณ์กว่า แต่ก่อน ก่อนหน้านี้ใช้เวลา 2 - 3 นาทีในการสำรองบันทึกของฐานข้อมูลทั้งหมด 500 ตอนนี้ใช้เวลา 15-25 เราได้ตรวจสอบแล้วว่าการสำรองข้อมูลนั้นทำงานได้ดีด้วยปริมาณงานที่ดี อย่างไรก็ตามมีความล่าช้าเล็กน้อยหลังจากการสำรองข้อมูลของบันทึกหนึ่งรายการและก่อนเริ่มต้นการติดตามครั้งถัดไป มันเริ่มต้นต่ำมาก แต่ภายในหนึ่งหรือสองวันถึง 2-3 วินาที คูณด้วย 500 ฐานข้อมูลและมีความแตกต่าง

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

  4. ปัญหาอื่นที่แนะนำโดย 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 ดูเหมือนจะสูญเสียการเชื่อมต่อกับฐานข้อมูลทั้งหมดในครั้งเดียว:

รอเมื่อเกิดข้อผิดพลาด 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 หรือไม่

ขอบคุณล่วงหน้าสำหรับความช่วยเหลือใด ๆ !

คำตอบ:


9

ปรับปรุง:

  1. การยกเลิกการเชื่อมต่อของกลุ่มความพร้อมใช้งานประจำได้รับการยืนยันว่าเป็นความถดถอยที่ CU9 นำมาใช้และจะได้รับการแก้ไขหลังจากการติดตั้ง CU12
  2. ปัญหาการบล็อกในเรพลิการองได้รับการยืนยันว่าเป็นปัญหาเกี่ยวกับการอัปเดตรหัสตัวเขียน VSS ที่นำมาใช้ใน CU10 หวังว่าจะได้รับการแก้ไขใน CU 13 การแก้ปัญหาชั่วคราวคือการแทนที่ DLLs ตัวเขียน VSS ด้วย DLL Pre-CU10 ด้วยตนเอง ...

    BEGIN RANT-SACTION;

    น่าเสียดายที่ Microsoft ดูเหมือนจะล้มเหลวซ้ำ ๆ ในการตรวจสอบคุณภาพไม่เพียง แต่อัพเดท Windows 10 เท่านั้น แต่ยังมีซอฟต์แวร์ที่มีความสำคัญต่อองค์กรเช่น SQL Server ด้วย

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

    COMMIT RANT-SACTION;

2

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


2
สวัสดี @Gonzalo และขอบคุณสำหรับคำแนะนำ เราได้ครอบคลุมมุมการตั้งค่า max_worker_threads แล้วแม้ว่าเราจะไม่พบข้อผิดพลาดเช่น "ไม่มีเธรดผู้ปฏิบัติงานให้บริการ" ซึ่งเป็นเรื่องปกติในกรณีที่มีเธรดไม่เพียงพอ ค่าเริ่มต้นสำหรับกล่องของเรานั้นน้อยกว่า 1k เธรดเรายกมันขึ้นเป็น 2K โดยไม่กระทบกับข้อผิดพลาด เรารวบรวมตัวชี้วัดเธรดของผู้ปฏิบัติงานและพวกเขาเฉลี่ยประมาณ 1500 รวมถึงเธรด AG ซึ่งไม่นับรวมสูงสุด ดังนั้นเราจึงอยู่ไกลจากขีด จำกัด เธรด
SQLRaptor
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.