home

หน้าแรก
 Computer >> คอมพิวเตอร์ >  >> การเขียนโปรแกรม >> Redis

ความสำคัญของการคงอยู่ของฐานข้อมูลและการสำรองข้อมูล

เมื่อเร็วๆ นี้เรามีโอกาสทำงานร่วมกับทีม Cohesity เพื่อตรวจสอบการผสานรวมระหว่าง Helios และ Redis Enterprise ซึ่งเป็นขั้นตอนในการเริ่มต้นใช้งานโปรแกรมพันธมิตรด้านเทคนิคของ Redis Cohesity SmartFiles เป็นบริการที่ทำงานบน Helios ให้มุมมองเดียวและการจัดการข้อมูลที่ไม่มีโครงสร้างทั่วโลก ไม่ว่าข้อมูลจะอยู่ที่ใด ในบริบทของ Redis Enterprise SmartFiles จะแสดงภาพรวมของฐานข้อมูลในมุมมองเดียว

ทำไมเราถึงต้องกังวลกับการคงอยู่และการสำรองข้อมูล? เป็นความจริง:หาก Redis ถูกใช้เป็นแคชและสามารถนำกลับมาใช้ใหม่ได้จากฐานข้อมูลแบ็กเอนด์โดยมีผลกระทบต่อระบบน้อยที่สุด ก็ไม่มีความจำเป็นเช่นกัน ในทางกลับกัน ให้พิจารณาว่าเมื่อใดที่ Redis ถูกใช้เป็นฐานข้อมูลการดำเนินงานเพื่อให้สามารถเข้าถึงข้อมูลที่ช้าได้อย่างรวดเร็ว (เช่น ประวัติการทำธุรกรรม จำนวนสินค้าคงคลัง การค้นหาลูกค้า) ฐานข้อมูล Redis จำเป็นต้องกู้คืนอย่างรวดเร็วจากปัญหาฮาร์ดแวร์หรือแม้แต่การเฟลโอเวอร์ไปยังศูนย์ข้อมูลอื่น

ความคงอยู่

ข้อมูลทั้งหมดในฐานข้อมูล Redis ถูกจัดเก็บและจัดการเฉพาะใน RAM หรือ RAM + Flash Memory (Redis on Flash); มีความเสี่ยงที่จะสูญหายจากกระบวนการหรือความล้มเหลวของเซิร์ฟเวอร์ มีกลยุทธ์หลายอย่างที่สามารถปฏิบัติตามเพื่อลดความเสี่ยงนี้:ฐานข้อมูล High Availability (HA) ที่มีส่วนแบ่งข้อมูลหลักและรอง ฐานข้อมูล Active-Active ที่กระจายตามพื้นที่ และการคงอยู่ของดิสก์ จากมุมมองด้านประสิทธิภาพ มักจะต้องการเปลี่ยนระบบจากชาร์ดฐานข้อมูลหลักไปเป็นชาร์ดฐานข้อมูลรองที่ซิงโครไนซ์ และนี่คือวิธีการทำงานของ Redis Enterprise เฉพาะเมื่อชาร์ดหลักและรองหายไปเท่านั้นคือฐานข้อมูลที่กู้คืนจากดิสก์ ในทำนองเดียวกัน ในกรณีของดาต้าเซ็นเตอร์ล้มเหลว การเฟลโอเวอร์ไปยังฐานข้อมูลแอกทีฟแอกทีฟที่ซิงโครไนซ์ในศูนย์ข้อมูลอื่นจะเร็วกว่าการกู้คืนจากดิสก์

สำหรับคำถามเรื่องการคงอยู่ Redis รองรับไฟล์ต่อท้ายเท่านั้น (AOF) เพื่อความทนทานที่ดีขึ้น แม้ว่าจะต้องใช้ทรัพยากรมากขึ้นและสแน็ปช็อต (RDB) ซึ่งทนทานน้อยกว่าในขณะที่ใช้ทรัพยากรน้อยลง เช่นเดียวกับทุกสิ่ง มีข้อแลกเปลี่ยนที่สามารถสำรวจเพิ่มเติมได้ในเอกสารประกอบของ Redis Enterprise สำหรับวัตถุประสงค์ของบทความนี้ เราจะถือว่าเราต้องการ AOF เพื่อความทนทานที่ดีขึ้น

ความสำคัญของการคงอยู่ของฐานข้อมูลและการสำรองข้อมูล

สำรองข้อมูล

Redis Enterprise อาศัยการคงอยู่สำหรับการกู้คืนเมื่อทั้งชาร์ดฐานข้อมูลหลักและรองหายไป หากไม่ได้ใช้แอ็คทีฟแอ็คทีฟและชั้นวางที่มีฐานข้อมูลพร้อมกับที่เก็บข้อมูลที่แนบมาหายไป เราจะเหลือการกู้คืนจากข้อมูลสำรอง ในกรณีของ Redis Enterprise การสำรองข้อมูลจะเป็นสแน็ปช็อตเสมอ ซึ่งเมื่อใช้ร่วมกับ AOF เพื่อความคงอยู่ จะสร้างแพลตฟอร์มข้อมูลที่ยืดหยุ่นและทนทาน

นี่คือที่มาของ Cohesity SmartFiles Redis Enterprise ใช้จุดปลายที่เข้ากันได้กับ S3 ที่ SmartFiles จัดเตรียมไว้ให้สำหรับการสำรองข้อมูลที่มีการจัดการทั่วทั้งคลาวด์ ในการตั้งค่านี้ เราใช้ Redis Enterprise REST API โดยมีสมมติฐานดังต่อไปนี้:

  • $S3_IP ถูกตั้งค่าเป็นที่อยู่ IP ของที่เก็บอ็อบเจ็กต์ Cohesity S3 และ $BUCKET ถูกตั้งค่าเป็นชื่อบัคเก็ต
  • $USER และ $PASS ถูกกำหนดเป็นชื่อผู้ใช้และรหัสผ่านของผู้ดูแลระบบ Redis Enterprise ตามลำดับ
  • $ACCESS_KEY และ $SECRET_KEY ได้รับการตั้งค่าคีย์การเข้าถึงที่เก็บอ็อบเจ็กต์ S3 และคีย์ลับตามลำดับ

เปิดใช้งานการคงอยู่ของฐานข้อมูล

curl -s -k -u $USER:$PASS -H content-type:application/json -XPUT 
https://localhost:9443/v1/bdbs/1 -d '{"data_persistence": "aof"}'

กำหนดคอนฟิกคลัสเตอร์เพื่อใช้ที่เก็บอ็อบเจ็กต์ S3 โดยการตั้งค่า S3 URL โปรดทราบว่าชื่อที่ฝากข้อมูลไม่รวมอยู่ใน S3 URL

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d '{"s3_url": '\"$S3_IP\"'}'

กำหนดค่าการสำรองข้อมูลคลัสเตอร์ S3 เพื่อความเป็นส่วนตัวเท่านั้น 

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d 
'{"s3_certificate_verification":false}'

ตรวจสอบตำแหน่งสำรอง โปรดทราบว่าคำตอบเดียวสำหรับความสำเร็จคือ HTTP 200 ตกลง

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/actions/validate_backup_location -d 
'{"backup_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "","access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

สร้างข้อมูลสำรอง โปรดทราบว่าคำตอบเดียวสำหรับความสำเร็จคือ HTTP 200 ตกลง

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/1/actions/export -d 
'{"export_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "", "access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

กำหนดค่าการสำรองข้อมูลที่เกิดซ้ำทุกๆ 30 นาที โปรดทราบว่าคำตอบเดียวสำหรับความสำเร็จคือ HTTP 200 ตกลง

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/bdbs/1 -d '{"backup":true, 
"backup_interval":1800, "backup_interval_offset":360, 
"backup_location": {"type": "s3", "bucket_name": '\"$BUCKET\"', 
"subdir": "", "access_key_id": '\"$ACCESS_KEY\"', "secret_access_key": 
'\"$SECRET_KEY\"'}}'

ความคิดสุดท้าย

ในโลกที่ราบรื่น Redis Enterprise ที่กำหนดค่าด้วย HA และ Active-Active ช่วยให้คุณไม่ต้องกังวลเกี่ยวกับการคงอยู่และการสำรองข้อมูล เราไม่ได้อาศัยอยู่ในโลกที่ราบรื่น และเราต้องการทั้งความคงอยู่และการสำรองข้อมูล (พร้อมกับ HA) เมื่อ Redis คาดว่าจะกู้คืนจากความล้มเหลวของระบบ เป็นเรื่องปกติที่จะเห็นปลายทางสำรอง S3 ตามที่อุปกรณ์นำเสนอจาก Dell EMC, NetApp หรือ Pure Storage โชคดีที่การผสานรวมกับ Cohesity SmartFiles ทำให้ง่ายต่อการใช้งานปลายทางนี้และรวมข้อมูลสำรองไว้ในกลยุทธ์การปฏิบัติงาน