ปัจจุบันมีเทคโนโลยีกู้คืนระบบจากภัยพิบัติ (DR) จำนวนมากในอุตสาหกรรม ได้แก่ การมิเรอร์ฐานข้อมูล การใช้คลัสเตอร์ และโซลูชันการจำลองข้อมูล อย่างไรก็ตาม การส่งลอจเป็นวิธีที่ง่ายกว่า กำหนดค่าและดูแลรักษาง่ายกว่า บทความนี้จะกล่าวถึงขั้นตอนการกู้คืนระบบ SQL Server โดยใช้การส่งลอจ
โซลูชันการกู้คืนภัยพิบัติด้วยการจัดส่งบันทึก
การจัดส่งบันทึกจะรักษาการสำรองข้อมลไว้ที่เซิร์ฟเวอร์รองเป็นหลัก และเมื่อจำเป็นสามารถให้เซิร์ฟเวอร์รองทำหน้าที่แทนเซิร์ฟเวอร์หลักได้ เพื่อเพิ่มความสามารถในการใช้งานฐานข้อมูลโดยรวม กล่าวคือ เมื่อฐานข้อมูลหลักไม่สามารถใช้งานได้เนื่องจากเกิดภัยพิบัติ คุณสามารถเปิดใช้งานฐานข้อมูลรองได้ด้วยตนเองเพื่อดำเนินการให้บริการต่อไป
ในการกำหนดค่าการส่งข้อมูลบันทึกสำหรับฐานข้อมูล SQL Server จะสร้างงานตัวแทนสามงานต่อไปนี้เพื่อทำให้การปฏิบัติงานสำรอง คัดลอก และกู้คืนเป็นอัตโนมัติ
งานแรกจะรันบนอินสแตนซ์หลัก มันจะสำรองข้อมูลบันทึกธุรกรรมจากฐานข้อมูลหลัก
งานที่สองทำงานบนเซิร์ฟเวอร์สำรอง โดยมันจะคัดลอกรูปแบบการสำรองข้อมูลจากเซิร์ฟเวอร์หลักไปยังเซิร์ฟเวอร์สำรอง
งานที่สามยังทำงานบนเซิร์ฟเวอร์รองด้วย มันจะกู้คืนสำรองบันทึกและอัปเดตรายการบันทึกในฐานข้อมูลรอง
ข้อพิจารณาก่อนการกำหนดค่าการจัดส่งบันทึกใน SQL Server
แม้ว่าการตั้งค่าการจัดส่งบันทึกจะไม่ใช่เรื่องยาก แต่ควรพิจารณาหลายประการก่อนการนำไปใช้งาน
การป้องกันในระดับฐานข้อมูล หากคุณต้องการเพียงแค่ปกป้องฐานข้อมูลจำนวนน้อยในกรณีเกิดภัยพิบัติ ระดับนี้ถือว่าเพียงพอ อย่างไรก็ตาม หากคุณต้องการสำรองฐานข้อมูลหลายชุดในระดับอินสแตนซ์ของ SQL Server โซลูชันการจัดส่งลอกราคาเดี่ยวจะไม่เพียงพอ
การสลับเซิร์ฟเวอร์รองด้วยตนเอง การจัดส่งล็อกเพียงอย่างเดียวไม่สามารถทำการสลับจากเซิร์ฟเวอร์หลักไปยังเซิร์ฟเวอร์รองได้อัตโนมัติ คุณต้องนำฐานข้อมูลรองกลับมาใช้งานออนไลน์ด้วยตนเอง
การกำหนดค่าการเข้าสู่ระบบ SQL ด้วยตนเอง การเข้าสู่ระบบ SQL จะไม่ถูกถ่ายโอนโดยอัตโนมัติจากเซิร์ฟเวอร์หลักไปยังเซิร์ฟเวอร์รอง คุณจำเป็นต้องถ่ายโอนข้อมูลประจำตัวการเข้าสู่ระบบจากอินสแตนซ์ของเซิร์ฟเวอร์หลักไปยังอินสแตนซ์ของเซิร์ฟเวอร์รองเพื่อให้การเข้าสู่ระบบตรงกัน นอกจากนี้ คุณมักจะต้องสร้างแผนการบำรุงรักษาต่างๆ เซิร์ฟเวอร์ที่เชื่อมโยง และแพ็คเกจ SSIS (SQL Server Integration Services) บนเซิร์ฟเวอร์รองด้วยตนเอง
ความเสี่ยงต่อการสูญหายของข้อมูล โดยทั่วไป เมื่อฐานข้อมูลหลักไม่สามารถใช้งานได้ จะสามารถกู้คืนได้เพียงสำรองบันทึกธุรกรรม ครั้งสุดท้ายเท่านั้น ซึ่งหมายความว่า ธุรกรรมใดๆ ที่เกิดขึ้นหลังจากที่มีการสำรองบันทึกครั้งสุดท้ายส่งไปยังเซิร์ฟเวอร์รองจะสูญหายไป ตัวอย่างเช่น หากเซิร์ฟเวอร์หลักล้มเหลวในเวลา 09.00 น. และการสำรองข้อมูลล่าสุดที่ถูกคัดลอกไปยังอินสแตนซ์เซิร์ฟเวอร์รอง B เกิดขึ้นเมื่อเวลา 08.45 น. ข้อมูลทั้งหมดตั้งแต่ 08.45 น. ถึง 09.00 น. จะสูญหายไป
การจัดส่งบันทึกรีเวิร์ส สิ่งนี้มีประโยชน์เมื่อเปลี่ยนบทบาทของเซิร์ฟเวอร์โดยไม่ต้องสำรองข้อมูลฐานข้อมูลทั้งหมด ตัวอย่างเช่น หากคุณมีการสำรองข้อมูลขนาดใหญ่และจำเป็นต้องถ่ายโอนข้อมูลจากเซิร์ฟเวอร์รองไปยังเซิร์ฟเวอร์หลักระยะไกล การคัดลอกข้อมูลสำรองทั้งหมดอาจใช้เวลานาน
การตั้งค่าและการใช้งานการจัดส่งบันทึกทำอย่างไร?
โดยทั่วไป กระบวนการในการตั้งค่าการส่งข้อมูลล็อกสามารถแบ่งออกเป็นสองขั้นตอนที่แตกต่างกัน
ขั้นตอนที่ 1 เริ่มต้นฐานข้อมูลบนเซิร์ฟเวอร์รอง
สมมติว่าเรามีฐานข้อมูลสองฐานบนอินสแตนซ์เซิร์ฟเวอร์หลัก และเราจำเป็นต้องส่งลอจสำหรับ TestDB1 ไปยังเซิร์ฟเวอร์รองที่เริ่มต้นไม่มีฐานข้อมูลใดๆ สิ่งสำคัญที่ต้องทราบคือ เพื่อตั้งค่าการจัดส่งลอจ ฐานข้อมูลจะต้องอยู่ในโหมดกู้คืนแบบ FULL หรือ BULK-LOGGED หากฐานข้อมูลอยู่ในโหมดกู้คืนแบบ SIMPLE การจัดส่งลอจจะล้มเหลว เนื่องจากการสำรองข้อมูลลอจธุรกรรมจะไม่สามารถใช้งานได้
1. ก่อนอื่น เราต้องทำการสำรองข้อมูลฐานข้อมูลทั้งหมดและสำรองบันทึกธุรกรรม คุณสามารถรันคำถาม T-SQL ต่อไปนี้เพื่อสร้างการสำรองแบบ "เต็ม" และการสำรอง "บันทึกธุรกรรม":
backup database TestDB1 to disk = 'c:\backup\TestDB1.bak'
backup log TestDB1 to disk = 'c:\backup\TestDB1.bak'
2. จากนั้น ให้กู้คืนข้อมูลสำรองบนเซิร์ฟเวอร์สำรอง
3. ในอินเตอร์เฟซ กู้คืนฐานข้อมูล ให้เลือก อุปกรณ์ เป็นแหล่งที่มาของข้อมูล แล้วคลิกไอคอนของมัน
4. ในกล่องโต้ตอบ เลือกอุปกรณ์สำรองข้อมูล ให้คลิก เพิ่ม
5. เลือกไฟล์สำรองที่ต้องการกู้คืนแล้วคลิก ตกลง
6. ดำเนินการกู้คืนข้อมูลสำรองของ TestDB1
7. คลิก เลือกหน้า แล้วไปที่ ไฟล์ เพื่อแก้ไขตำแหน่งของไฟล์ฐานข้อมูลทางกายภาพหากจำเป็น
8. จากนั้นคลิก ตัวเลือก ที่ด้านซ้าย บนหน้า ตัวเลือก ให้เลือก กู้คืนพร้อมโหมดสแตนบาย จากรายการแบบหล่นลงของ สถานะการกู้คืน โปรดทราบว่าการเลือก กู้คืนพร้อมโหมดสแตนบาย จะทำให้ฐานข้อมูลอยู่ในสถานะอ่านเท่านั้น หากคุณเลือก กู้คืนโดยไม่กู้คืน ฐานข้อมูลจะไม่สามารถเข้าถึงได้
9. หลังจากเลือกสถานะการกู้คืนที่เหมาะสมแล้ว ให้คลิก ตกลง เพื่อให้แน่ใจว่าการคืนค่าสำเร็จ ซึ่งจะทำการคืนค่า TestDB1 โหมดสแตนด์บาย (อ่านอย่างเดียว) บนอินสแตนซ์เซิร์ฟเวอร์รอง
ณ จุดนี้ ฐานข้อมูลได้ถูกเริ่มต้นบนเซิร์ฟเวอร์รองเป็นที่เรียบร้อยแล้ว
ขั้นตอนที่ 2 เปิดใช้งานฐานข้อมูลหลัก
1. คลิกขวาที่ TestDB1 บนอินสแตนซ์เซิร์ฟเวอร์หลัก แล้วคลิก คุณสมบัติ
2. เลือก เปิดใช้งานฐานข้อมูลนี้เป็นฐานข้อมูลหลักในการกำหนดค่าการจัดส่งบันทึก
โดยค่าเริ่มต้น ระบบจะสำรองข้อมูลบันทึกธุรกรรมทุกๆ 15 นาที อย่างไรก็ตาม ในบางครั้งไฟล์บันทึกธุรกรรมอาจมีขนาดใหญ่เกินไปจนไม่สามารถคัดลอกและกู้คืนภายในระยะเวลาที่กำหนดได้ เพื่อแก้ปัญหานี้ คุณจำเป็นต้องจัดกำหนดการสำรองข้อมูลเพิ่มเติม คลิก การตั้งค่าการสำรองข้อมูล ระบุตำแหน่งไฟล์สำรองในอินเทอร์เฟซการตั้งค่าการสำรองข้อมูลบันทึกธุรกรรม จากนั้นคลิก กำหนดเวลา และเปลี่ยนความถี่ในการสำรองให้ทำงานทุกๆ 1-2 นาที
3. คลิก เพิ่ม เพื่อตั้งค่าฐานข้อมูลสำรอง ระบบจะแจ้งให้คุณเชื่อมต่อกับอินสแตนซ์ของเซิร์ฟเวอร์สำรอง
4. ตามที่ได้ตั้งค่าไว้ในขั้นตอนที่ 1 ในอินเตอร์เฟซ การตั้งค่าฐานข้อมูลรอง ให้เลือก ไม่ ฐานข้อมูลรองถูกเริ่มต้นแล้ว
5. ดำเนินการคัดลอกไฟล์โดยระบุตำแหน่งโฟลเดอร์สำรองข้อมูลของเซิร์ฟเวอร์สำรอง ตั้งความถี่ในการสำรองข้อมูล แล้วคลิกตกลง
6. ในอินเทอร์เฟซ กู้คืนบันทึกธุรกรรม ตั้งสถานะฐานข้อมูลเป็น โหมดสแตนด์บาย และเลือกช่อง ตัดการเชื่อมต่อผู้ใช้ในฐานข้อมูลเมื่อกู้คืนข้อมูลสำรอง หลังจากตั้งค่าช่วงเวลาสำรองข้อมูลแล้ว ให้คลิกตกลง
7. ในการเพิ่มอินสแตนซ์เซิร์ฟเวอร์รองและฐานข้อมูล ให้คลิก ตกลง เพื่อสร้างงานตัวแทน SQL Server
ภายใต้ SQL Server Agent บนเซิร์ฟเวอร์หลัก คุณจะพบงานสำรองข้อมูลบันทึกธุรกรรม
ภายใต้ SQL Server Agent บนเซิร์ฟเวอร์รอง คุณจะพบงานที่สร้างขึ้นใหม่สองงาน งานหนึ่งสำหรับคัดลอกการสำรองข้อมูลบันทึกธุรกรรมจากฐานข้อมูลหลัก และอีกงานหนึ่งสำหรับกู้คืนข้อมูลการสำรองบันทึกธุรกรรมลงในฐานข้อมูลรอง
8. ณ จุดนี้ การแก้ปัญหาการกู้คืนข้อมูลจากภัยพิบัติด้วยการส่งลอจ์กําลังได้รับการตั้งค่าอย่างสมบูรณ์แล้ว หากฐานข้อมูลหลักเกิดขัดข้อง คุณสามารถทําให้ฐานข้อมูลรองออนไลน์ได้ทันที นอกจากนี้ คุณยังสามารถเรียกใช้คําสอบถามต่อไปนี้เพื่อยืนยันว่าฐานข้อมูลรองได้ออกจากโหมดสแตนด์บายแล้ว:
Select * from Products
RESTORE DATABASE TestDB1 WITH RECOVERY
9. เมื่อคุณรีเฟรชฐานข้อมูล คุณจะเห็นว่า TestDB1 บนเซิร์ฟเวอร์รองกำลังทำงานอยู่
กลยุทธ์การป้องกันข้อมูลที่ครอบคลุมมากขึ้นสำหรับ SQL Server
แม้จะมีการใช้งานโซลูชันการกู้คืนภัยพิบัติ เช่น การส่งข้อมูลล็อก แต่ธุรกิจมักต้องการกลยุทธ์การป้องกันข้อมูลที่ครอบคลุมและมีประสิทธิภาพมากกว่า Vinchin Backup & Recovery มีโซลูชันการสำรองข้อมูลและการกู้คืนอัตโนมัติที่ออกแบบมาโดยเฉพาะสำหรับเครื่องเสมือนและฐานข้อมูลอย่าง SQL Server รองรับการสำรองข้อมูลแบบเต็มรูปแบบ แบบส่วนเพิ่ม และแบบแตกต่าง โดยใช้เทคโนโลยีการลดข้อมูลซ้ำและการบีบอัดข้อมูลในตัว ช่วยลดการใช้พื้นที่จัดเก็บข้อมูลและเวลาการสำรองข้อมูลอย่างมีนัยสำคัญ
นอกจากนี้ โซลูชันการสำรองข้อมูลของ Vinchin ยังช่วยลดความจำเป็นในการแทรกแซงด้วยตนเองที่ซับซ้อน โดยสามารถปกป้องฐานข้อมูลอัตโนมัติ พร้อมรองรับการโยกย้ายข้ามแพลตฟอร์มและการจัดเก็บข้อมูลบนคลาวด์ ในกรณีที่ SQL Server เกิดข้อผิดพลาด Vinchin จะช่วยให้ผู้ดูแลระบบกู้คืนฐานข้อมูลได้อย่างรวดเร็ว ป้องกันการสูญหายของข้อมูลและการหยุดทำงานที่ยาวนาน จึงให้การรับประกันการกู้คืนจากภัยพิบัติที่ครอบคลุมมากยิ่งขึ้นสำหรับองค์กร
ในการสร้างงานสำรองข้อมูลฐานข้อมูล SQL Server โปรดไปที่หน้า การสำรองข้อมูลทางกายภาพ > การสำรองข้อมูลฐานข้อมูล > การสำรองข้อมูล
1. เลือกฐานข้อมูลที่ต้องการสำรองข้อมูล
2. เลือกโหนดสำรองที่คุณต้องการให้ประมวลผลและจัดเก็บข้อมูลสำรอง
3. ตั้งค่ากลยุทธ์การสำรองข้อมูลตามความต้องการของคุณ
4. ตรวจสอบและยืนยันการตั้งค่า
คลิกที่ปุ่มด้านล่างเพื่อทดลองใช้งานฟรี 60 วันของ Vinchin เพื่อสัมผัสประสบการณ์โซลูชันสำรองและกู้คืนข้อมูลที่มีประสิทธิภาพและน่าเชื่อถือ
คำถามที่พบบ่อยเกี่ยวกับการกู้คืนจากภัยพิบัติของ SQL Server
1. ความแตกต่างระหว่าง High Availability (HA) และ Disaster Recovery (DR) คืออะไร?
HA ช่วยลดเวลาหยุดทำงานให้น้อยที่สุดโดยใช้เทคโนโลยีอย่างการทำคลัสเตอร์แบบล้มเหลว กลุ่มความพร้อมใช้งานเสมอ หรือการมิเรอร์ฐานข้อมูล ในขณะที่ DR มุ่งเน้นไปที่การ กู้คืนการให้บริการหลังจากเกิดความล้มเหลวร้ายแรง ซึ่งมักเกี่ยวข้องกับการสำรองข้อมูลไว้นอกสถานที่หรือศูนย์ข้อมูลสำรอง
2. SQL Server Failover Cluster Instance (FCI) คืออะไร และช่วยในการกู้คืนภัยพิบัติได้อย่างไร?
FCI เป็นโซลูชันสำหรับความพร้อมใช้งานสูง ซึ่งใช้ Windows Server Failover Clustering (WSFC) เพื่อให้เกิดการสลับอัตโนมัติในระดับอินสแตนซ์ของ SQL Server จำเป็นต้องมีพื้นที่จัดเก็บข้อมูลร่วมกัน (SAN, Storage Spaces Direct หรือโซลูชันบนคลาวด์) เหมาะอย่างยิ่งสำหรับการใช้งานภายในสถานที่เพื่อความพร้อมใช้งานสูง แต่ไม่ใช่โซลูชันสำรองข้อมูลเพียงอย่างเดียว เนื่องจากไม่สามารถป้องกันความล้มเหลวที่เกิดขึ้นทั้งไซต์ได้
ข้อสรุป
การจัดส่งล็อกเป็นโซลูชันกู้คืนภัยพิบัติที่มีความประหยัด มีประสิทธิภาพ และเรียบง่ายสำหรับ SQL Server ซึ่งถือเป็นทางเลือกที่เหมาะสมสำหรับการกู้คืนภัยพิบัติในระดับฐานข้อมูล อย่างไรก็ตาม สำหรับการกู้คืนภัยพิบัติในระดับอินสแตนซ์ ควรพิจารณาเทคนิคอื่นๆ เช่น การสะท้อนฐานข้อมูล หรือกลุ่มคลัสเตอร์สลับการทำงาน นอกจากนี้ การจัดส่งล็อกอาจทำให้เกิดการสูญเสียข้อมูลได้ หากคุณจำเป็นต้องกู้คืนข้อมูลที่ถูกลบหรือไม่สามารถเข้าถึงได้จากฐานข้อมูล SQL ที่เสียหาย ควรพิจารณาใช้เครื่องมือกู้คืน SQL มืออาชีพ
