การปกป้องข้อมูลและความต่อเนื่องทางธุรกิจ

การจัดการ กำกับดูแล และการทำงานร่วมกันใน Snowflake

Emily Melhuish

Technical Curriculum Developer, Snowflake

ปัญหาความต่อเนื่องทางธุรกิจ

แผนภาพแสดงสามสถานการณ์ความเสี่ยง: การลบข้อมูลโดยไม่ตั้งใจ, ระบบล้มเหลวในภูมิภาค และการจัดเก็บข้อมูลข้ามภูมิภาค พร้อมแนวทางแก้ไขของ Snowflake

นักวิเคราะห์ลบข้อมูลโดยไม่ตั้งใจ — Time Travel จัดการได้
ภูมิภาค Cloud ล้มเหลว ทำให้บัญชีของ Claro ใช้งานไม่ได้ — failover group จัดการได้
ผู้ใช้ใน EU ต้องการข้อมูลที่มีเฉพาะในบัญชี US — replication จัดการได้
ความเสี่ยงที่ต่างกันต้องการเครื่องมือที่ต่างกัน

Time Travel และ Fail-Safe

แผนภาพไทม์ไลน์

Time Travel ช่วยให้คุณกู้คืนข้อมูลกลับสู่สถานะก่อนหน้าได้
ความลึกของช่วงเวลาขึ้นอยู่กับ edition ของคุณ
- Standard: สูงสุด 1 วัน
- Enterprise: สูงสุด 90 วัน
Fail-Safe: บัฟเฟอร์การกู้คืน 7 วันนอกเหนือจากช่วง Time Travel: ต้องติดต่อ Snowflake Support

Zero-Copy Cloning: รูปแบบการใช้งาน

Clone ตารางก่อนดำเนินการ bulk operation ที่มีความเสี่ยง
สำเนาทันที — ไม่มีค่าใช้จ่ายด้านพื้นที่จัดเก็บเมื่อสร้าง
หาก migration ล้มเหลว ให้กู้คืนจาก clone
การเขียนข้อมูลลง clone จะไม่กระทบข้อมูลต้นฉบับ

Zero Copy Cloning

¹ Snowflake Learning Material

Replication คืออะไร?

คัดลอกข้อมูลข้ามขอบเขตบัญชี
แบบ asynchronous — ข้อมูลปลายทางใกล้เคียง real-time แต่ไม่ใช่ live mirror

กรณีการใช้งาน

Screenshot 2026-05-17 at 7.33.30 pm.png

ตัวอย่าง Replication

Replication Groups

แผนภาพกลุ่มการจำลองข้อมูลที่มีสองฐานข้อมูลในบัญชีหลัก US-East พร้อมลูกศรไปยัง read-only replica ในบัญชีรอง EU-West

การสร้าง Replication Group

-- On the primary account
CREATE REPLICATION GROUP claro_replication_group
  OBJECT_TYPES = DATABASES
  ALLOWED_DATABASES = claro_db, claro_users_db
  ALLOWED_ACCOUNTS = claro.eu_west;

-- On the secondary account
CREATE REPLICATION GROUP claro_replication_group
  AS REPLICA OF claro.us_east.claro_replication_group;

-- Trigger a refresh
ALTER REPLICATION GROUP claro_replication_group REFRESH;

Failover Groups: สิ่งที่เพิ่มเติมมา

ต่อยอดจาก replication group โดยเพิ่มคุณสมบัติสำคัญหนึ่งอย่าง
Secondary สามารถเลื่อนขึ้นเป็น primary ได้หาก primary ล้มเหลว
Secondary อยู่ในโหมด read-only เสมอ
Secondary ที่ถูกเลื่อนขึ้นจะกลายเป็น writable และทำหน้าที่เป็นแหล่งข้อมูลหลัก
จำลองออบเจกต์ระดับบัญชีด้วย: ผู้ใช้, role, warehouse, resource monitor

ตัวอย่าง Failover

กลไก Planned Failover และ Failover

Planned Failover - วางแผนล่วงหน้า: primary ลดสถานะ, secondary เลื่อนขึ้น; ไม่สูญเสียข้อมูล
Failover - ไม่ได้วางแผน: primary ไม่พร้อมใช้งาน, secondary เลื่อนขึ้นทันที
การจำลองข้อมูลเป็นแบบ asynchronous — การเปลี่ยนแปลงหลัง refresh ล่าสุดจะไม่อยู่ใน secondary
ความถี่ในการ refresh เป็นการตัดสินใจสำคัญสำหรับการออกแบบ RPO

ตัวอย่าง Failover

มาฝึกกันเลย!

การจัดการ กำกับดูแล และการทำงานร่วมกันใน Snowflake