home

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

การรับรองความน่าเชื่อถือของข้อมูล: บทบาทสำคัญของ Database Persistence และ Backups

เราเพิ่งมีโอกาสทำงานกับทีม Cohesity เพื่อตรวจสอบการรวมระหว่าง Helios และ Redis Enterprise เป็นขั้นตอนในการเข้าโปรแกรม Redis Technical Partner Program Cohesity SmartFiles ซึ่งเป็นบริการที่รันบน Helios ให้มุมมองเดียว (single view) และการจัดการข้อมูลไม่มีโครงสร้าง (unstructured data) ทั่วโลก ไม่ว่าข้อมูลจะอยู่ที่ไหน ในบริบทของ Redis Enterprise SmartFiles ให้มุมมองเดียวของ database snapshots

ทำไมเราต้องกังวลเรื่อง persistence และ backup? เป็นจริง: ถ้า Redis ถูกใช้เป็น cache และสามารถ rehydrate จาก backend database ได้ด้วยผลกระทบต่อระบบน้อยที่สุด ไม่จำเป็นต้องมีทั้งสองอย่าง แต่พิจารณาเมื่อ Redis ถูกใช้เป็น operational database เพื่อให้การเข้าถึงข้อมูลช้าทางเร็ว (เช่น transaction history, inventory count, customer lookup) ฐานข้อมูล Redis ต้องสามารถกู้คืนจากปัญหา hardware หรือแม้แต่ failover ไปยัง datacenter อื่นได้อย่างรวดเร็ว

Persistence (ความคงทน)

ข้อมูลทั้งหมดในฐานข้อมูล Redis ถูกจัดเก็บและจัดการอย่างเป็นเอกสิทธิ์ใน RAM หรือ RAM + Flash Memory (Redis on Flash) อยู่ในความเสี่ยงที่จะสูญหายเมื่อ process หรือ server ล้มเหลว มีกลยุทธ์หลายอย่างที่สามารถปฏิบัติตามเพื่อลดความเสี่ยงนี้: High Availability (HA) databases พร้อม primary และ secondary data shards, geo-distributed active-active databases, และโดยสิ้นเชิง disk-based persistence จากมุมมองประสิทธิภาพ มักจะต้องการ failover จาก primary database shard ไปยัง synchronized secondary database shard และนี่คือวิธีที่ Redis Enterprise ทำงาน เฉพาะเมื่อ primary และ secondary shards ทั้งคู่สูญหาย จึงจะ restore จากดิสก์ ทำนองเดียวกัน ในกรณี datacenter failure การ failover ไปยัง synchronized active-active database ใน datacenter อื่นจะเร็วกว่าการกู้คืนจากดิสก์

เรื่อง persistence Redis รองรับ append-only files (AOF) สำหรับ durability ที่ดีกว่า แต่อาจต้องการทรัพยากรมากกว่า และ snapshots (RDB) ซึ่งทนทานน้อยกว่าแต่ต้องการทรัพยากรน้อยกว่า เหมือนทุกอย่าง มี tradeoffs ที่สามารถสำรวจเพิ่มเติมในเอกสาร Redis Enterprise เพื่อวัตถุประสงค์ของบทความนี้ เราจะสมมติว่าเราต้องการ AOF สำหรับ durability ที่ดีกว่า

การรับรองความน่าเชื่อถือของข้อมูล: บทบาทสำคัญของ Database Persistence และ Backups

Backup (การสำรองข้อมูล)

Redis Enterprise พึ่งพา persistence สำหรับการกู้คืนเมื่อ primary และ secondary database shards ทั้งคู่สูญหาย หาก active-active ไม่ได้ใช้ และ rack ที่เก็บฐานข้อมูลพร้อม attached storage หายไป เราจะเหลือแค่การ restore จาก backup ในกรณีของ Redis Enterprise backup เสมอเป็น snapshot ซึ่งเมื่อรวมกับ AOF สำหรับ persistence จะสร้างแพลตฟอร์มข้อมูลที่ทนทานและ durable

นี่คือที่ที่ Cohesity SmartFiles เข้ามามีบทบาท Redis Enterprise ใช้ S3 compatible endpoint ที่ SmartFiles จัดเตรียมไว้สำหรับ managed backups ทั่วทุก cloud ในการตั้งค่า เราใช้ Redis Enterprise REST API ด้วยสมมติฐานดังนี้:

  • $S3_IP ตั้งเป็น Cohesity S3 object store IP address และ $BUCKET ตั้งเป็น bucket name
  • $USER และ $PASS ตั้งเป็น Redis Enterprise admin username และ password ตามลำดับ
  • $ACCESS_KEY และ $SECRET_KEY ตั้งเป็น S3 object store access key และ secret key ตามลำดับ

เปิดใช้งาน database persistence.

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

ตั้งค่า cluster ให้ใช้ S3 object store โดยตั้งค่า S3 URL โปรดสังเกต bucket name ไม่ได้รวมอยู่ใน 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"'}'

ตั้งค่า cluster S3 backup สำหรับ privacy เท่านั้น

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

ตรวจสอบ backup location โปรดสังเกต การตอบกลับเมื่อสำเร็จมีแค่ HTTP 200 OK

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"'}}'

สร้าง backup โปรดสังเกต การตอบกลับเมื่อสำเร็จมีแค่ HTTP 200 OK

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"'}}'

ตั้งค่า recurring backup ทุก 30 นาที โปรดสังเกต การตอบกลับเมื่อสำเร็จมีแค่ HTTP 200 OK

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"'}}'

Final Thoughts (ข้อคิดสุดท้าย)

ในโลกที่ไม่มีเสียดสี (frictionless world) Redis Enterprise ที่ตั้งค่า HA และ Active-Active จะช่วยให้คุณไม่ต้องกังวลเรื่อง persistence และ backups เราไม่ได้อยู่ในโลกแบบนั้น และเราต้องการทั้ง persistence และ backups (พร้อม HA) เมื่อ Redis คาดว่าจะต้องกู้คืนจาก system failures มักเห็น S3 backup endpoint เช่นที่เห็นจาก appliance offerings จาก Dell EMC, NetApp, หรือ Pure Storage โชคดีที่ verified integration กับ Cohesity SmartFiles ทำให้ง่ายต่อการใช้ endpoint นี้ และรวม backups เข้าไปใน operational strategies