ฐานข้อมูลกลุ่มความพร้อมใช้งานของเซิร์ฟเวอร์กระจาย SQL ไม่ซิงค์หลังจากรีบูตเซิร์ฟเวอร์

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

เดือนที่แล้วฉันอัปเกรดเซิร์ฟเวอร์รองระยะไกลจาก SQL Server 2016 เป็น SQL Server 2017 เซิร์ฟเวอร์นี้เป็นส่วนหนึ่งของกลุ่มความพร้อมใช้งานแบบกระจาย (DAG)และกลุ่มความพร้อมใช้งานแยกต่างหาก(AG)หลายกลุ่ม เมื่อเราอัปเกรดเซิร์ฟเวอร์นี้เราไม่ทราบว่าจะเข้าสู่สถานะที่อ่านไม่ได้ดังนั้นในช่วงเดือนที่ผ่านมาเราได้พึ่งพาเซิร์ฟเวอร์หลักเพียงอย่างเดียว

เป็นส่วนหนึ่งของการอัปเกรดที่จะเกิดขึ้นฉันใช้CU 4 patch กับเซิร์ฟเวอร์และทำการบูทใหม่ เมื่อเซิร์ฟเวอร์กลับมาออนไลน์อีกครั้งรองที่เพิ่งได้รับการปรับปรุงแสดงให้เห็นว่า DAGs / AG ทั้งหมดซิงค์กันโดยไม่มีปัญหาใด ๆ

อย่างไรก็ตามตัวละครหลักกำลังแสดงเรื่องราวที่แตกต่างกันมาก มีรายงานว่า

• AG แยกต่างหากกำลังซิงค์โดยไม่มีปัญหาใด ๆ
• แต่ DABs ความได้ในไม่ Synchronzing / ไม่ดีต่อสุขภาพของรัฐ

หลังจากตื่นตระหนกในตอนแรกฉันพยายามทำสิ่งต่าง ๆ ต่อไปนี้เพื่อให้สิ่งต่าง ๆ ซิงโครไนซ์อีกครั้งใน DAG:

• จากหลักฉันหยุดและกลับมาเคลื่อนไหวข้อมูลต่อ สิ่งนี้ไม่ได้เริ่มซิงค์ข้อมูล
• ในครั้งที่สอง (อันที่ฉันเพิ่งแก้ไข) ฉันรันALTER DATABASE [<database] SET HADR RESUME;- ซึ่งรันโดยไม่มีข้อผิดพลาด แต่ไม่ได้ซิงค์ต่อ

ความพยายามครั้งล่าสุดของฉันในการซิงค์ข้อมูลอีกครั้งคือการเข้าสู่ระบบรองและเริ่มบริการ SQL Server ด้วยตนเอง การรีสตาร์ทบริการด้วยตนเองดูเหมือนจะสุดขีดเพราะฉันคาดว่าเซิร์ฟเวอร์ที่รีบูตจะเพียงพอแล้ว

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

ฉันตรวจสอบทั้งบันทึกข้อผิดพลาดของ SQL Server และตัวแสดงเหตุการณ์บนเซิร์ฟเวอร์รองไม่มีอะไรผิดปกติที่ฉันเห็น

โปรดทราบว่านี้ไม่ได้เป็นคำตอบที่ชัดเจน แต่ก็เป็นคำตอบที่ดีที่สุดหลังจากพูดคุยกับTaryn

อย่างไรก็ตามตัวละครหลักกำลังแสดงเรื่องราวที่แตกต่างกันมาก มีการรายงานว่า AG แยกต่างหากกำลังซิงค์โดยไม่มีปัญหาใด ๆ แต่ DAG อยู่ในสถานะไม่ซิงโครไนซ์ / ไม่แข็งแรง

หากฐานข้อมูลและ AG ของแต่ละบุคคลที่อยู่ภายใต้การกระจาย ag บอกว่าพวกเขามีสุขภาพดีและการประสานมีโอกาสที่ดีนี่เป็นเพียงอาการสะอึกในแดชบอร์ด DMVs และ / หรือ SSMS เนื่องจากไม่มีสิ่งใดใน errorlog เพื่อแนะนำแบบจำลองที่ไม่ได้เชื่อมต่อหรืออยู่ในสถานะที่ไม่ได้เชื่อมต่อ

น่าเสียดายที่ปัญหานี้ได้รับการแก้ไขมันยากที่จะบอกว่ามันคืออะไร ... แต่ในอนาคตหากเกิดขึ้นกับใครบางคน:

• ตรวจสอบsys.dm_hadr_database_replica_statesในทุกกลุ่มที่กำลังมองหาสิ่งที่ไม่ดีต่อสุขภาพ หากทุกอย่างแสดงว่าเป็นไปได้ว่า DMV ยังไม่ได้อัปเดต
• ถ้ามันไม่แข็งแรงตรวจสอบ errorlog / DMVs สำหรับปัญหาการเชื่อมต่อ (เช่นไม่สามารถเชื่อมต่อกับผู้ส่ง / หลักทั่วโลก)
• คำตอบของแดนกล่าวถึงปัญหาที่อาจเกิดขึ้นจากการเริ่มทำงานของฐานข้อมูล - แต่ในกรณีนี้ไม่สามารถอ่านอินสแตนซ์ได้เพื่อที่ว่าส่วนใหญ่จะไม่เป็นปัญหา แต่อาจเป็นในกรณีของคุณ
• หากฐานข้อมูลสามารถอ่านได้ให้ทดสอบการสูบบุหรี่ด้วยตาราง / จำลองหรือ ...
• ขยายเซสชันกิจกรรมโดยใช้รายการช่อง DEBUG sqlserver.hadr_dump_log_blockหรือsqlserver.hadr_apply_log_blockเพื่อดูว่ารองกำลังรับ / ใช้บล็อกบันทึกหรือ ...
• วัตถุ Perfmon SQLServer:Database Replica\Log Bytes Received/sec

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

อย่างไรก็ตามหากไม่เป็นเช่นนั้นเราจะต้องทำการตรวจสอบเพิ่มเติมซึ่งอยู่นอกขอบเขตของคำตอบ

ฉันจะคำนำทั้งหมดนี้กับข้อแม้ที่ฉันไม่มี DAG ใด ๆ ในการผลิต โดยพื้นฐานแล้วแม้ว่าคำแนะนำนี้ควรใช้ระหว่างทั้ง AG และ DAG

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

การปิดกั้นของ AG ทำซ้ำ SPID

โดยทั่วไปแล้วจะเกิดขึ้นกับรองที่อ่านได้เท่านั้น หากต้องการตรวจสอบให้เรียกใช้สิ่งต่อไปนี้:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

หากมีการปิดกั้นDB STARTUPSPID ใด ๆ คุณจะต้องฆ่าพวกเขาก่อนที่ผู้เล่นสำรองจะสามารถเล่นต่อได้ ฉันขอแนะนำให้ตรวจสอบการปิดกั้น SPID ล่วงหน้าเพื่อลองหาสาเหตุ (โดยปกติจะเป็นรายงานที่ใช้เวลานาน)

หากท่านต้องการข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้มีบทความดีดี (รวมถึงการตรวจสอบสำหรับประเภทของพฤติกรรมการใช้ XES นี้) ที่นี่

ตรวจสอบ DMV

หากการเคลื่อนย้ายข้อมูลถูกระงับคุณสามารถอ้างถึง DMVs เพื่อรับข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุการระงับ รันสิ่งต่อไปนี้:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

บทความ BOLอธิบาย suspend_reason ต่อไปเพียงเล็กน้อย

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

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

การปรับปรุง: กำหนดค่า SESSION_TIMEOUT สำหรับแบบจำลองกลุ่มความพร้อมใช้งานแจกจ่ายใน SQL Server 2016 และ 2017