ข้อมูลเบื้องต้นเกี่ยวกับฐานข้อมูล Tencent Cloud TDSSQL: การสำรองและกู้คืนสถาปัตยกรรมระดับองค์กร
เพื่อนๆที่เคยเล่นเซิร์ฟเวอร์คลาวด์และ MySQL แบบโอเพนซอร์สควรทราบว่าฐานข้อมูลแบบสแตนด์อโลนมักจะดีมากในการฝึกฝนแต่เมื่อพูดถึงอีคอมเมิร์ซระดับองค์กรการเงินหรือสถานการณ์ทางธุรกิจที่เกิดขึ้นพร้อมกันสูงสถาปัตยกรรมแบบสแตนด์อโลนจะพังทลายสิ่งที่องค์กรต้องการจริงๆคือฐานข้อมูลแบบกระจายที่มีความหลากหลายสม่ำเสมอและทนต่อภัยพิบัติโดยอัตโนมัติ
ของเทนเซ็นต์คลาวด์
TDSSQL
นี่คือสิ่งที่ออกมาเป็นฐานข้อมูลแบบกระจายระดับองค์กรที่พัฒนาขึ้นเองของ Tencent ซึ่งไม่เพียงแต่เข้ากันได้อย่างสมบูรณ์แบบกับประสิทธิภาพของ MySQL แต่ยังมีสถาปัตยกรรมแบบกระจายที่ด้านล่างวันนี้เราจะไม่พูดถึงทฤษฎี PPT ที่คลุมเครือเหล่านั้นแต่ตัดตรงจากจุดเจ็บปวดหลักและจะพาคุณไปเจาะเส้นเลือดใหญ่ของฐานข้อมูลระดับองค์กร-
สำรองและกู้คืน
。
ขั้นตอนแรก: ทำลายชั้นล่างสุดทำความเข้าใจสถาปัตยกรรมสามชั้นระดับองค์กรของ TDSSQL
ก่อนดำเนินการ (การสำรองข้อมูลและการกู้คืน) คุณต้องเข้าใจโครงสร้างร่างกายของ TDSQL ก่อนมิฉะนั้นคุณจะตาบอดว่าไฟล์สำรองถูกเก็บไว้ที่ไหนและจะกู้คืนได้อย่างไรสถาปัตยกรรมแบบกระจายของ TDSSQL ส่วนใหญ่ประกอบด้วยส่วนประกอบหลักสามส่วน:
Proxy (ชั้นเกตเวย์): มันเป็นประตูเมื่อไคลเอนต์และแอปเชื่อมต่อกับฐานข้อมูลพวกเขาเชื่อมต่อกับพร็อกซี Proxy รับผิดชอบในการแจกจ่ายคำขอความละเอียด SQL และการกำหนดเส้นทางมันทำให้คุณรู้สึกเหมือนยังคงใช้ MySQL แบบสแตนด์อโลนธรรมดา
Shard/DB (ชั้นเก็บข้อมูล): นี่คือสถานที่ที่คุณสามารถทำงานและจัดเก็บข้อมูลได้จริง TDSSQL ระดับองค์กรมักใช้สถาปัตยกรรมที่มีความพร้อมใช้งานสูง "หนึ่งหลักและสองสแตนด์บาย" โหนดหลัก (Master) ถูกวางสายและการจำลองแบบ Multi-Sync จะช่วยให้มั่นใจได้ว่าข้อมูลจะไม่สูญหายและโหนดสแตนด์บายจะอยู่ด้านบนโดยอัตโนมัติในไม่กี่วินาที
ZooKeeper/Scheduler (การจัดการการจัดตารางเวลาชั้น): มันเป็นสมองรับผิดชอบในการตรวจสอบสถานะของโหนดทั้งหมดแจกจ่ายการกำหนดค่าและเริ่มต้นคำสั่งสำรอง
"การสำรองข้อมูล" ที่เรากำลังพูดถึงในวันนี้คือกระบวนการที่ฝ่ายบริหารออกคำแนะนำไปยังชั้นจัดเก็บข้อมูลบรรจุข้อมูลและคายข้อมูลไปยังที่เก็บข้อมูลออฟไลน์อย่างปลอดภัย (โดยปกติจะเป็นที่เก็บข้อมูลอ็อบเจ็กต์ Tencent Cloud COS)
ขั้นตอนที่สอง: การต่อสู้จริงของการสำรองข้อมูลเต็มระดับองค์กรและส่วนเพิ่ม
ในสภาพแวดล้อมการผลิตขององค์กรกลยุทธ์การสำรองข้อมูลโดยทั่วไปคือ:
การสำรองข้อมูลแบบเรียลไทม์แบบเรียลไทม์ (Binlog)
。
การสำรองข้อมูลทั้งหมด: โดยปกติจะส่งออกข้อมูลทางกายภาพทั้งหมดในช่วงที่ธุรกิจมีน้อย (เช่น2:00-4:00น. ในตอนเช้า)
การสำรองข้อมูลส่วนเพิ่ม: การสำรองข้อมูล Binlog แบบต่อเนื่องตลอด24ชั่วโมงด้วยการรวมกันของทั้งสองคุณสามารถกู้คืนฐานข้อมูลให้เป็นสถานะของวินาทีใดก็ได้ในช่วง30วันที่ผ่านมา (PITR การกู้คืนตามจุดเวลา)
1.กลยุทธ์การกำหนดค่าคอนโซลอัตโนมัติ (การไหลแบบไร้กังวล)
ลงชื่อเข้าใช้ Tencent Cloud Console และค้นหาเพื่อเข้าสู่ "ฐานข้อมูลแบบกระจาย TDSSQL"
ในรายการตัวอย่างคลิกที่รหัสอินสแตนซ์ของคุณเมนูด้านซ้ายเพื่อค้นหา "การกู้คืนการสำรองข้อมูล"-> "การตั้งค่าการสำรองข้อมูล"
ข้อกำหนดการกำหนดค่าเชิงกลยุทธ์: ระยะเวลาการสำรองข้อมูลเต็มรูปแบบ: แนะนำให้ใช้สภาพแวดล้อมการผลิตขององค์กรอย่างน้อยสัปดาห์ละสองครั้ง (เช่นวันจันทร์
ในเช้าตรู่ของวันพฤหัสบดี) ธุรกิจหลักที่มีการเปลี่ยนแปลงข้อมูลอย่างมากแนะนำวันละครั้งจำนวนวันสำรอง: โดยทั่วไปกำหนดไว้ที่30วันและข้อกำหนดการปฏิบัติตามข้อกำหนดระดับการเงินมักใช้เวลา180วันหรือนานกว่านั้นหน้าต่างเวลาสำรองข้อมูลอัตโนมัติ: คุณต้องเดินโซเซไปยังจุดสูงสุดของธุรกิจและเลือกตอนเช้าตรู่
2.บรรทัดคำสั่งด้วยตนเองเรียกการสำรองข้อมูลเต็มรูปแบบ (ฉุกเฉินสตรีม)
บางครั้งคุณสมบัติใหม่ที่สำคัญจะออกในเวลา15.00น. และโครงสร้างตารางฐานข้อมูล (DDL) จะต้องได้รับการแก้ไขเพื่อป้องกันการโรลโอเวอร์คุณต้องสำรองข้อมูลด้วยตนเองหนึ่งครั้งก่อนที่จะเผยแพร่
ใน TDSSQL โหนดการจัดการ (สถานีจัดการกระต่ายสีแดงหรือผ่าน API/CLI) คุณสามารถดำเนินการต่อไปนี้ตรรกะการสำรองข้อมูลด้วยตนเอง:
แบช
# ตัวอย่าง: เรียกใช้คำสั่งคอมโพเนนต์สำรองผ่านเครื่องมือ tdsql
Tdsql_backup -- instance_id = tdsql-abc12345 -- backup_method = snapshot -- type = full
ในขณะนี้คอมโพเนนต์สำรอง (Backup) ในพื้นหลังจะไปที่โหนดสแตนด์บายโดยตรง (เพื่อป้องกันไม่ให้ส่งผลกระทบต่อประสิทธิภาพของโหนดหลัก) เพื่อรวบรวมสแนปชอตทางกายภาพและอัปโหลดแบบอะซิงโครนัสไปยังที่เก็บข้อมูลแบบเย็นของ Tencent Cloud
ขั้นตอนที่สาม: การต่อสู้ฟื้นฟูที่น่าตื่นเต้น (สองสถานการณ์ภัยพิบัติ)
ไม่ว่าการสำรองข้อมูลจะดีเพียงใดการกู้คืนจะไม่เท่ากับศูนย์เราจำลองสถานการณ์ภัยพิบัติสองสถานการณ์ที่ทำให้การดำเนินงานและการบำรุงรักษาและการพัฒนาความดันโลหิตเพิ่มสูงขึ้นโดยตรง
สถานการณ์ที่1: พบ ransomware หรือความเสียหายของฮาร์ดแวร์ไลบรารีทั้งหมด (ทั้งไลบรารีถูกส่งกลับ)
ในขณะนี้ไลบรารีการผลิตของคุณถูกทิ้งอย่างสมบูรณ์และคุณต้องหาเวอร์ชันประวัติศาสตร์ที่ดีเพื่อ "คืนชีพจากความตาย"
ขั้นตอนการปฏิบัติ:
ตัดแหล่งน้ำ: บล็อกคำขอเขียนทั้งหมดสำหรับแอปพลิเคชันภายนอกในกลุ่มความปลอดภัยหรือชั้น Proxy ทันทีเพื่อป้องกันมลพิษทุติยภูมิ
เริ่มกระบวนการส่งคืนไฟล์: ในคอนโซล TDSSQL คลิก "Backup and Restore"-> "Example Backup" เลือก "อินสแตนซ์ใหม่สำหรับการย้อนกลับ" (อย่าเขียนทับอินสแตนซ์การผลิตเดิมโดยตรง! แนวทางมาตรฐานขององค์กรคือการย้อนกลับไปที่ "อินสแตนซ์ใหม่ชั่วคราว" ก่อนจากนั้นจึงตัดการเข้าชมหลังจากตรวจสอบแล้ว) เลือกจุดเวลาในการย้อนกลับ: แม่นยำจนถึงช่วงเวลาที่คุณต้องการกู้คืน (ตัวอย่างเช่น2026-05-29 14:00:00)
ตรรกะการทำงานเบื้องหลัง: ในขณะนี้ตัวกำหนดตารางเวลาของ TDSSQL จะไปที่ COS เพื่อดาวน์โหลดข้อมูลสำรองทั้งหมดในตอนเช้าตรู่ที่ใกล้ที่สุด14นาฬิกาคลายการบีบอัดและกู้คืนไปยังเครื่องใหม่จากนั้นเล่นซ้ำ (Replay) การเพิ่มขึ้นของ Binlog ทั้งหมดตั้งแต่เช้าตรู่ถึง14:00น. บันทึก.
ตรวจสอบและตัดกระแส: ไม่กี่นาทีถึงสิบนาทีต่อมาตัวอย่างใหม่พร้อมนักพัฒนาเข้าไปตรวจสอบข้อมูลและหลังจากยืนยันว่าถูกต้องแล้วให้แก้ไขการเชื่อมต่อฐานข้อมูล (ที่อยู่ VIP/Proxy) ในการกำหนดค่าแอปพลิเคชันชี้ไปที่อินสแตนซ์ใหม่และเว็บไซต์จะเปิดอีกครั้ง
ฉากที่2: เพื่อนร่วมทีมหมูจับมือและดำเนินการ
DELETE FROM table;
ไม่ได้เพิ่มเงื่อนไขที่ (บางตารางย้อนกลับ)
ฉากแบบนี้ปวดหัวที่สุด99% ของข้อมูลในฐานข้อมูลทั้งหมดถูกต้องมีเพียงตารางหลักนี้เท่านั้นที่ถูกลบโดยไม่ได้ตั้งใจหากคุณทำไฟล์ย้อนกลับของห้องสมุดทั้งหมดหมายความว่าวันนี้
คำสั่งซื้อใหม่ทั้งหมดที่สร้างโดยลูกค้ารายอื่นจะถูกลบ
แผนการต่อสู้ที่ดีที่สุด: วิธีการสกัดระดับตาราง
TDSSQL เองไม่แนะนำให้คุณมีส่วนร่วมโดยตรงในการครอบคลุมบางส่วนในอินสแตนซ์การผลิตขั้นตอนการปฏิบัติงานมาตรฐานที่ปลอดภัยมีดังนี้:
ไลบรารีชั่วคราวสำหรับการส่งคืนไฟล์: ตามวิธีการของสถานการณ์ที่1ให้ส่งคืนฐานข้อมูลไปยังสถานะ "1นาทีก่อนการทำงานผิดพลาด" เพื่อสร้างอินสแตนซ์ชั่วคราว
ส่งออกตารางเดียว: เชื่อมต่ออินสแตนซ์ชั่วคราวนี้ด้วยเครื่องมือ mysqldump และส่งออกตารางที่ถูกลบโดยไม่ได้ตั้งใจแยกต่างหาก: ห้องสมุดชั่วคราว Bashmysqldump -h IP -u admin -p -- tables my_lase damaged_table > /root/recovered_table.sql
นำเข้าไลบรารีการผลิต: ตรวจสอบไฟล์ recovered_table.sql เพื่อให้แน่ใจว่าข้อมูลสะอาดเชื่อมต่อกับฐานข้อมูลสภาพแวดล้อมการผลิตจริงและเทไฟล์ SQL นี้เพื่อให้ได้การซ่อมแซมจุดคงที่ที่แม่นยำ: ไลบรารีการผลิต Bashmysql -h IP -u admin -p my_data </root/recovered_table.sql
การดำเนินการ "ขโมยคานและเปลี่ยนเสา" แบบนี้ไม่เพียงแต่บันทึกข้อมูลที่ถูกลบเท่านั้นแต่ยังช่วยให้มั่นใจได้ว่าธุรกิจออนไลน์อื่นๆจะไม่หยุดชะงัก
ขั้นตอนที่สี่: ประวัติการหลีกเลี่ยงเลือดและน้ำตาของการรักษาความปลอดภัยฐานข้อมูลระดับองค์กร
อย่างแน่นอนอย่าทำการสำรองข้อมูลเชิงตรรกะ (เช่น mysqldump) บนโหนดหลัก (Master) การทำงานพร้อมกันสูงสิ่งนี้จะทำให้ตารางล็อคห้องสมุดหลักหรือ CPU ทะยานขึ้นทำให้เกิดอุบัติเหตุออนไลน์โดยตรงการสำรองข้อมูลอัตโนมัติของ TDSSQL จะดำเนินการโดยค่าเริ่มต้นที่โหนดสแตนด์บายหากคุณต้องการนำข้อมูลด้วยตนเองโปรดจดจำ IP ของโหนดที่เตรียมไว้
ทำ "แบบฝึกหัดการกู้คืนระบบ" เป็นประจำ: ไฟล์สำรองของหลายบริษัทอยู่ในระบบคลาวด์และดูเหมือนจะถูกสร้างขึ้นทุกวันด้วยเหตุนี้จึงพบว่าไฟล์สำรองเสียหายเมื่อไฟล์ถูกส่งคืนองค์กรต่างๆกำหนดให้ทุกไตรมาสหรือครึ่งปีต้องนำไฟล์สำรองออกและทำการฝึกซ้อมการกู้คืนในสภาพแวดล้อมการทดสอบเพื่อให้แน่ใจว่าข้อมูลสามารถทำงานได้ตลอดเวลา
ใช้ประโยชน์จากความสม่ำเสมอที่แข็งแกร่ง: เมื่อซื้ออินสแตนซ์ TDSSQL อย่าลืมตรวจสอบว่าเปิด "การซิงโครไนซ์ความสอดคล้องที่แข็งแกร่ง" หรือไม่เฉพาะในกรณีที่มีความสอดคล้องกันอย่างมากการสลับหลักและการสำรองข้อมูลและการสำรองข้อมูลจะสามารถบรรลุ RPO = 0ที่แท้จริง (การสูญเสียข้อมูลเป็นศูนย์)
สรุป
เมื่อเผชิญกับความปลอดภัยของข้อมูลระดับองค์กรความบังเอิญใดๆก็คือการขุดหลุมสำหรับตัวคุณเองสถาปัตยกรรมสามชั้นและกลไกการย้อนกลับอัตโนมัติของ Tencent Cloud TDSSQL ได้ห่อหุ้มลอจิกแบบกระจายพื้นฐานที่ซับซ้อนในฐานะสถาปนิกหรือการดำเนินงานและการบำรุงรักษาสิ่งที่คุณต้องทำคือ
กำหนดกลยุทธ์การสำรองข้อมูลเก็บบันทึกหลักและใช้กระบวนการเส้นสีแดงของ "การย้อนกลับไปยังไลบรารีชั่วคราวและการตรวจสอบซ้ำ" อย่างเคร่งครัด
。หากคุณมีอาหารอยู่ในมืออย่าตกใจในใจแม้ว่าคุณจะเผชิญกับภัยพิบัติด้านข้อมูลที่รุนแรงคุณสามารถทำให้ระบบมีชีวิตใหม่ได้ภายในครึ่งชั่วโมงในขณะที่พูดคุยและหัวเราะ
