ในบทความนี้ เราจะแนะนำคู่มือทีละขั้นตอนเกี่ยวกับวิธีติดตั้งและกำหนดค่า Always On Availability Groups บน SQL Server ที่รันบน Windows Server 2019 อภิบัติสถานการณ์การ failover และหัวข้ออื่นๆ ที่เกี่ยวข้อง
Always On Availability Groups ให้ความพร้อมใช้งานสูงใน Microsoft SQL Server Always On ปรากฏในการเปิดตัว MSSQL 2012
คุณสมบัติของ Always On Availability Groups ใน SQL Server
คุณสามารถใช้ SQL Server availability groups สำหรับอะไรได้บ้าง?
- ความพร้อมใช้งานสูงของ MS SQL และการ failover อัตโนมัติ
- การกระจายภาระงานคำขอ SELECT ระหว่างโหนด (โหนดรองอาจอ่านได้)
- การสำรองข้อมูลจากโหนดรอง
- ความซ้ำซ้อนของข้อมูล แต่ละโหนดเก็บสำเนาฐานข้อมูล availability group
Always On พัฒนาบน Windows Server Failover Cluster (WSFC) WSFC ตรวจสอบโหนด availability group และให้การ failover อัตโนมัติ เริ่มจาก MS SQL Server 2017 Always On อาจใช้ โดยไม่ต้องมี WSFC และบนโฮสต์ Linux ได้เช่นกัน เมื่อสร้างคลัสเตอร์บน Linux คุณสามารถใช้ Pacemaker แทน WSFC
Always On พร้อมใช้งานในรุ่น Standard แต่มีข้อจำกัดบางประการ:
- จำกัด 2 โหนด (หลักและรอง)
- โหนดรองไม่สามารถใช้เพื่ออ่านข้อมูลได้
- โหนดรองไม่สามารถใช้สำรองข้อมูล MS SQL ได้
- รองรับเพียง 1 ฐานข้อมูลต่อ availability group
ไม่มีข้อจำกัดในรุ่น Enterprise
คุณสามารถอ่านเกี่ยวกับด้านการออกใบอนุญาต MS SQL Server ที่นี่
มาพิจารณาคำศัพท์
- Always On Availability Group คือชุดของโหนดและฐานข้อมูล
- Replica คืออินสแตนซ์ SQL Server ใน availability group โหนดอาจเป็นหลักหรือรอง แต่ละโหนดอาจมีฐานข้อมูลหนึ่งหรือมากกว่า
Always On พัฒนาบน WSFC โหนด availability group แต่ละตัวต้องเป็นสมาชิกของ Windows failover cluster อินสแตนซ์ SQL Server แต่ละอันสามารถมี availability groups หลายกลุ่ม แต่ละ availability group อาจมีโหนดรองได้สูงสุด 8 ตัว
หากโหนดหลักล้มเหลว คลัสเตอร์จะโหวตเลือกโหนดหลักใหม่ และ Always On จะทำให้หนึ่งในโหนดรองกลายเป็นโหนดหลัก เนื่องจากผู้ใช้เชื่อมต่อกับ Listener (ที่อยู่ IP คลัสเตอร์พิเศษและชื่อ DNS ที่เกี่ยวข้อง) เมื่อทำงานกับ Always On จะสามารถรันคำขอเขียนได้อีกครั้ง Listener ยังรับผิดชอบในการกระจายคำขอ SELECT ระหว่างโหนดรอง
กำหนดค่า Windows Failover Cluster สำหรับ Always On Availability Group
ขั้นแรก เราต้องกำหนดค่าคลัสเตอร์ failover บนโหนดทั้งหมดที่ใช้โดย Always On
นี่คือการกำหนดค่าของฉัน:
- เครื่องเสมือน 2 ตัวที่รัน Windows Server 2019
- 2 อินสแตนซ์ SQL Server 2019 Enterprise
- ชื่อโฮสต์โหนดคือ testnode1 และ testnode2 ชื่ออินสแตนซ์ SQL Server คือ node1 และ node2
เพิ่มบทบาท Failover Clustering โดยใช้ Server Manager หรือติดตั้งผ่าน PowerShell:
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
การติดตั้งเป็นอัตโนมัติ และคุณไม่ต้องกำหนดค่าอะไรเลย รันสแนปอิน Failover Cluster Manager (FailoverClusters.SnapInHelper.msc) และสร้างคลัสเตอร์ใหม่
เพิ่มชื่อโฮสต์ที่คุณต้องการเข้าร่วมคลัสเตอร์ของคุณ
จากนั้นวิซาร์ดเสนอให้ทำการทดสอบบางอย่าง เพื่อทำเช่นนี้ ให้เลือกตัวเลือกแรก
ระบุชื่อคลัสเตอร์ เลือกเครือข่าย และที่อยู่ IP ของคลัสเตอร์ ชื่อคลัสเตอร์จะปรากฏใน DNS อัตโนมัติ คุณไม่ต้องสร้างระเบียน DNS ด้วยตนเอง ในกรณีของฉัน ชื่อคลัสเตอร์คือ ClusterAG
ยกเลิกการเลือกตัวเลือก Add all eligible storage to the cluster เนื่องจากเราสามารถเพิ่มดิสก์ได้ภายหลัง
มีเพียงสองโหนดในคลัสเตอร์ ดังนั้นคุณต้องกำหนด Cluster Quorum Cluster Quorum คือการลงมติ ตัวอย่างเช่น หากหนึ่งในโหนดคลัสเตอร์ไม่พร้อมใช้งาน คลัสเตอร์ต้องตรวจจับว่าโหนดใดออนไลน์จริงและมองเห็นกันได้ Cluster Quorum ให้ความสอดคล้องของคลัสเตอร์ (Cluster → More Actions → Configure Cluster Quorum Settings)
เลือกตัวเลือก quorum witness
จากนั้นเลือกประเภท witness: file share witness
ระบุพาธ UNC ไปยังโฟลเดอร์ที่แชร์ สร้างไดเรกทอรีด้วยตนเอง มันต้องอยู่บนเซิร์ฟเวอร์นอกคลัสเตอร์ failover ของคุณ
เมื่อคุณกำหนดค่าคลัสเตอร์ คุณอาจเห็นข้อผิดพลาดต่อไปนี้:
There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.
น่าจะเป็นว่าบัญชีผู้ใช้ที่คลัสเตอร์รันอยู่ ไม่มีสิทธิ์ NTFS เพื่อเข้าถึงโฟลเดอร์ที่แชร์ โดยค่าเริ่มต้น คลัสเตอร์รันภายใต้บัญชีผู้ใช้ท้องถิ่น คุณสามารถมอบสิทธิ์บนโฟลเดอร์ให้คอมพิวเตอร์คลัสเตอร์ทั้งหมด หรือเปลี่ยนบัญชีสำหรับบริการคลัสเตอร์และมอบสิทธิ์ที่เกี่ยวข้อง
การกำหนดค่า Windows Failover Cluster พื้นฐานเสร็จสิ้น
การกำหนดค่า Always On Availability Group บน MS SQL Server
หลังจากการติดตั้งอินสแตนซ์ SQL Server แบบปกติ คุณสามารถเปิดใช้งานและกำหนดค่า Always On Availability Groups เปิดใช้งานในคุณสมบัติอินสแตนซ์ของ SQL Server Configuration Manager ตามที่คุณเห็นในสกรีนชอต SQL Server ได้ตรวจจับแล้วว่ามันเป็นสมาชิกของคลัสเตอร์ WSFC ติ๊ก Enable Always On Availability Groups และรีสตาร์ทบริการอินสแตนซ์ MSSQL ทำซ้ำสำหรับอินสแตนซ์ที่สอง
เคล็ดลับ ก่อนการกำหนดค่า Always On ตรวจสอบให้แน่ใจว่าบริการ SQL Server ไม่ได้รันภายใต้บัญชีระบบท้องถิ่น แนะนำให้ใช้ Group Managed Service Accounts หรือบัญชีโดเมนทั่วไป มิฉะนั้น คุณจะไม่สามารถทำการกำหนดค่า Always-On ให้เสร็จสมบูรณ์
รัน SQL Server Management Studio เชื่อมต่อกับโฮสต์ของคุณ คลิก Always On High Availability และรัน New Availability Group Wizard
ใน SQL Server Management Studio 18.x สำหรับ SQL Server 2017 และ SQL Server 2019 บางการตั้งค่า Always On ปรากฏขึ้นซึ่งมีให้ใน T-SQL เท่านั้น จึงแนะนำให้ใช้ SSMS เวอร์ชันล่าสุด
ระบุชื่อสำหรับ Always On availability group ของคุณ และเลือก Database Level Health Detection โดยใช้ตัวเลือกนี้ Always On จะสามารถตรวจจับได้เมื่อฐานข้อมูลไม่สุขภาพดี
เลือกฐานข้อมูล SQL Server เพื่อเพิ่มลงใน Always On availability group ของคุณ
คลิก Add Replica และเชื่อมต่อ SQL server ที่สอง ดังนั้นคุณสามารถเพิ่มเซิร์ฟเวอร์ได้สูงสุด 8 ตัว
- Initial Role คือบทบาทโหนดในขณะที่กลุ่มถูกสร้าง อาจเป็น Primary หรือ Secondary
- Automatic Failover – หากฐานข้อมูลไม่พร้อมใช้งาน Always On จะย้ายบทบาทหลักไปยังโหนดอื่น ติ๊กตัวเลือกนี้
- Availability Mode อนุญาตให้เลือก Synchronous Commit หรือ Asynchronous Commit หากคุณเลือกโหมด synchronous ธุรกรรมที่มาถึงโหนดหลักจะถูกส่งไปยังโหนดรองอื่นๆ ทั้งหมดที่มีโหมด synchronous โหนดหลักจะเสร็จสิ้นธุรกรรมหลังจากโหนดอื่นๆ เขียนลงดิสก์แล้ว ดังนั้นการสูญเสียข้อมูลจะถูกกำจัดหากโหนดหลักล้มเหลว ในโหมด asynchronous โหนดหลักเขียนการเปลี่ยนแปลงทันทีโดยไม่รอตอบสนองของโหนดอื่นๆ
- Readable Secondary คือพารามิเตอร์ที่อนุญาตให้รันคำขอ SELECT ต่อโหนดรอง หากค่าเป็น yes ไคลเอ็นต์จะสามารถเข้าถึงแบบอ่านอย่างเดียวได้แม้จะเชื่อมต่อโดยไม่มี
ApplicationIntent=readonly - Required synchronized secondaries to commit คือจำนวนโหนดรองที่ซิงโครไนซ์เพื่อเสร็จสิ้นธุรกรรม ตั้งค่าตามจำนวนโหนด ฉันจะตั้งเป็น 1
อย่าแก้ไขอะไรในแท็บ Endpoint
ในแท็บ Backup Preferences คุณสามารถเลือกได้ว่าจะสำรองข้อมูลจากที่ไหน ทิ้งการตั้งค่าเริ่มต้นไว้: Prefer Secondary
ระบุชื่อ พอร์ต และที่อยู่ IP ของ availability group listener
ทิ้งการตั้งค่า Read-Only Routing ไว้เป็นเดิม
เลือกประเภทการซิงโครไนซ์โหนด ฉันทิ้กตัวเลือกแรก (Automatic seeding) ไว้
จากนั้นการตั้งค่าของคุณต้องผ่านการตรวจสอบ หากไม่มีข้อผิดพลาด คลิก Finish เพื่อนำไปใช้
ในกรณีของฉัน การทดสอบทั้งหมดผ่าน แต่ในขั้นตอน Results หลังการติดตั้ง วิซาร์ดแสดงข้อผิดพลาดในการสร้าง availability group listener ข้อผิดพลาด EVENTID 1194 ปรากฏในล็อกเหตุการณ์คลัสเตอร์:
Cluster network name resource failed to create its associated computer object in the domain.
หมายความว่าคลัสเตอร์ไม่มีสิทธียงพอที่จะสร้าง listener เอกสารระบุว่าการมอบสิทธิ์ในการสร้างออบเจ็กต์ประเภทคอมพิวเตอร์ให้กับออบเจ็กต์คลัสเตอร์ของคุณเพียงพอแล้ว ง่ายกว่าที่จะทำได้โดยการมอบสิทธิ์ใน AD (หรือรูปแบบรวดเร็วแต่ไม่ปลอดภัยคือเพิ่มออบเจ็กต์ CLUSTERAG$ เข้ากลุ่ม Domain Admins ชั่วคราว)
เมื่อวินิจฉัยปัญหา Always-On และประสิทธิภาพ SQL ต่ำใน availability group คุณควรศึกษาล็อกคลัสเตอร์ Windows อย่างละเอียด นอกจากการใช้เครื่องมือวินิจฉัย SQL Server มาตรฐาน
เนื่องจากฉันสร้าง availability group แล้ว แต่ไม่ได้สร้าง listener ฉันเพิ่มมันด้วยตนเอง เปิดเมนูบริบทสำหรับ availability group ของคุณและคลิก Add Listener
ระบุที่อยู่ IP, พอร์ต และชื่อ DNS ของ listener
ตรวจสอบให้แน่ใจว่า Listener ปรากฏในส่วน Availability Group Listeners ของ Always On group ของคุณ
ดังนั้น คุณได้ทำการกำหนดค่าพื้นฐานของ availability group Always On เสร็จสิ้น
SQL Server Always On: การตรวจสอบการทำงาน & Failover
มาดู Availability Group Dashboard (Show Dashboard)
มัน OK กลุ่มถูกสร้างและทำงาน
มาลองทำให้ node2 กลายเป็นอินสแตนซ์หลักด้วยตนเอง คลิกขวาที่ availability group และเลือก Failover
สังเกตค่าใน Failover Readiness No data loss หมายความว่าไม่มีข้อมูลสูญหาย
เชื่อมต่อกับ node2
คลิก Finish
ตรวจสอบให้แน่ใจว่า node2 กลายเป็นโหนดหลัก (Primary Instance) ใน availability group
ตรวจสอบให้แน่ใจว่า listener ทำงานอย่างถูกต้อง ระบุชื่อ DNS ของ listener และพอร์ตคั่นด้วยคอมมาใน SSMS: ag1-listener-1,1445
รันคำขอ SQL insert, select และ update เรียบง่ายไปยังฐานข้อมูลของคุณ
จากนั้นตรวจสอบการ failover อัตโนมัติของโหนดหลัก เพียง kill กระบวนการ sqlservr.exe บน TESTNODE2
ตรวจสอบสถานะ availability group บนโหนดที่เหลือ: TESTNODE1\NODE1
คลัสเตอร์ได้เปลี่ยนสถานะ testnode1\node1 เป็น primary อัตโนมัติ เนื่องจาก testnode2\node2 ไม่พร้อมใช้งาน
ตรวจสอบสถานะ listener เนื่องจากไคลเอ็นต์จะใช้มันเพื่อเชื่อมต่อ
ในกรณีของฉัน ฉันเชื่อมต่อกับ listener สำเร็จ แต่เมื่อพยายามเข้าถึงฐานข้อมูล ได้ข้อผิดพลาดนี้:
Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.
ข้อผิดพลาดปรากฏเนื่องจากตัวเลือก Required synchronized secondaries to commit เนื่องจากเราตั้งค่าเป็น 1 ตอนกำหนดค่า Always On ไม่อนุญาตให้เชื่อมต่อกับฐานข้อมูล เนื่องจากเรามีโหนดหลักเพียงตัวเดียวเหลืออยู่
ตั้งค่าเป็น 0 และลองรันคำขออีกครั้ง
Testnode1 รักษาสถานะ Primary instance ไว้ ในขณะที่ testnode2 กลายเป็นโหนดรอง ข้อมูลที่เราเปลี่ยนบน testnode1 เมื่อ testnode2 ปิดอยู่ ซิงโครไนซ์สำเร็จหลังจากคอมพิวเตอร์เปิดใช้งาน
ดังนั้น เราได้ตรวจสอบแล้วว่าทุกอย่างทำงานถูกต้องและข้อมูลจะพร้อมใช้งานสำหรับอ่าน/เขียนในกรณีของความล้มเหลวรุนแรง
คุณสามารถกำหนดค่า Always On availability groups ได้อย่างง่ายดาย หากคุณต้องการสร้างโซลูชัน failover ベース于 SQL Server availability groups จะจัดการได้ดี
