คําแนะนําการกู้คืนจากภัยพิบัติเฉพาะสําหรับประสบการณ์การใช้งาน

เอกสารนี้ให้คําแนะนําเฉพาะประสบการณ์สําหรับการกู้คืนข้อมูล Fabric ของคุณในกรณีที่เกิดภัยพิบัติในภูมิภาค

สถานการณ์ตัวอย่าง

ส่วนคําแนะนําหลายส่วนในเอกสารนี้ใช้ต่อไปนี้ amp สถานการณ์สมมติเพื่อวัตถุประสงค์ในการอธิบายและภาพประกอบ อ้างอิงกลับไปยังสถานการณ์นี้ตามความจําเป็น

สมมติว่าคุณมีความจุ C1 ในภูมิภาค A ที่มีพื้นที่ทํางาน W1 หากคุณ เปิดการกู้คืนจากภัยพิบัติ สําหรับความจุ C1 ข้อมูล OneLake จะถูกจําลองแบบไปยังการสํารองข้อมูลในภูมิภาค B หากภูมิภาค A ประสบปัญหาการหยุดชะงัก บริการ Fabric ใน C1 จะเปลี่ยนเป็นภูมิภาค B

หมายเหตุ

คําแนะนําการกู้คืนนี้ใช้เฉพาะเมื่อภูมิภาคหลักมีภูมิภาครองที่จับคู่กับ Azure และ Fabric ได้รับการสนับสนุนในภูมิภาคที่จับคู่

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

นี่คือแผนการกู้คืนทั่วไป:

1. สร้างความจุ Fabric ใหม่ C2 ในภูมิภาคใหม่

2. สร้างพื้นที่ทํางาน W2 ใหม่ใน C2 รวมถึงรายการที่สอดคล้องกันด้วยชื่อเดียวกับใน C1 W1.

3. คัดลอกข้อมูลจาก C1 ที่ถูกขัดจังหวะ W1 ถึง C2 W2.

4. ทําตามคําแนะนําเฉพาะสําหรับแต่ละคอมโพเนนต์เพื่อคืนค่ารายการไปยังฟังก์ชันแบบเต็ม

แผนการกู้คืนนี้ถือว่าภูมิภาคบ้านของผู้เช่ายังคงใช้งานได้ หากภูมิภาคหลักของผู้เช่าประสบปัญหาการหยุดทํางาน ขั้นตอนที่ระบุไว้ในเอกสารนี้จะขึ้นอยู่กับการกู้คืน ซึ่ง Microsoft จะต้องเริ่มต้นและดําเนินการให้เสร็จสมบูรณ์ก่อน

แผนการกู้คืนเฉพาะประสบการณ์

ส่วนต่อไปนี้ให้คําแนะนําทีละขั้นตอนสําหรับประสบการณ์การใช้งาน Fabric แต่ละรายการเพื่อช่วยลูกค้าตลอดกระบวนการกู้คืน

วิศวกรรมข้อมูล

คู่มือนี้จะแนะนําคุณเกี่ยวกับขั้นตอนการกู้คืนสําหรับการวิศวกรข้อมูลประสบการณ์การใช้งาน ครอบคลุมทั้งเลคเฮ้าส์ สมุดบันทึก และข้อกําหนดงาน Spark

เลคเฮ้าส์

เลคเฮ้าส์จากภูมิภาคเดิมยังคงไม่มีให้บริการสําหรับลูกค้า ในการกู้คืนเลคเฮ้าส์ ลูกค้าสามารถสร้างใหม่ในพื้นที่ทํางาน C2 ได้ W2. เราขอแนะนําให้ใช้สองวิธีในการกู้คืนเลคเฮ้าส์:

วิธี 1: ใช้สคริปต์แบบกําหนดเองเพื่อคัดลอกตารางและไฟล์ของ Lakehouse Delta

ลูกค้าสามารถสร้างเลคเฮ้าส์ใหม่โดยใช้สคริปต์ Scala แบบกําหนดเอง

1. สร้างเลคเฮ้าส์ (ตัวอย่างเช่น LH1) ในพื้นที่ทํางาน C2 ที่สร้างขึ้นใหม่ W2.

2. สร้างสมุดบันทึกใหม่ในพื้นที่ทํางาน C2 W2.

3. หากต้องการกู้คืนตารางและไฟล์จากเลคเฮาส์ดั้งเดิม ให้อ้างถึงข้อมูลที่มีเส้นทาง OneLake เช่น abfss (ดู การเชื่อมต่อกับ Microsoft OneLake) คุณสามารถใช้ตัวอย่างโค้ดต่อไปนี้ (ดู บทนําสู่ Microsoft Spark Utilities) ในสมุดบันทึกเพื่อรับเส้นทาง ABFS ของไฟล์และตารางจากเลคเฮาส์ดั้งเดิม (แทนที่ C1 W1 ที่มีชื่อพื้นที่ทํางานจริง)

   notebookutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. ใช้ตัวอย่างโค้ดต่อไปนี้เพื่อคัดลอกตารางและไฟล์ไปยัง lakehouse ที่สร้างขึ้นใหม่

   1. สําหรับตาราง Delta คุณจะต้องคัดลอกตารางทีละครั้งเพื่อกู้คืนในเลคเฮ้าส์ใหม่ ในกรณีของไฟล์ Lakehouse คุณสามารถคัดลอกโครงสร้างไฟล์ที่สมบูรณ์ด้วยโฟลเดอร์พื้นฐานทั้งหมดด้วยการดําเนินการเพียงครั้งเดียว

   2. ติดต่อทีมสนับสนุนสําหรับการประทับเวลาของการเฟลโอเวอร์ที่จําเป็นในสคริปต์

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. เมื่อคุณเรียกใช้สคริปต์ ตารางจะปรากฏในเลคเฮาส์ใหม่

วิธีที่ 2: ใช้ Azure Storage Explorer เพื่อคัดลอกไฟล์และตาราง

เมื่อต้องการกู้คืนเฉพาะไฟล์หรือตาราง Lakehouse ที่เฉพาะเจาะจงจากเลคเฮาส์เดิม ให้ใช้ Azure Storage Explorer อ้างถึง รวม OneLake กับ Azure Storage Explorer สําหรับขั้นตอนโดยละเอียด สําหรับขนาดข้อมูลขนาดใหญ่ ให้ใช้วิธี 1

หมายเหตุ

สองวิธีการที่อธิบายไว้ข้างต้นกู้คืนทั้งเมตาดาต้าและข้อมูลสําหรับตารางที่จัดรูปแบบแบบ Delta เนื่องจากเมตาดาต้านั้นอยู่ในตําแหน่งร่วมและเก็บข้อมูลไว้ใน OneLake สําหรับตารางที่ไม่ใช่รูปแบบเดลต้า (เช่น CSV, Parquet ฯลฯ) ที่สร้างขึ้นโดยใช้สคริปต์/คําสั่ง Spark Data Definition Language (DDL) ผู้ใช้มีหน้าที่รับผิดชอบในการบํารุงรักษาและเรียกใช้สคริปต์/คําสั่ง Spark DDL อีกครั้งเพื่อกู้คืน

การกู้คืน Fabric มุมมองทะเลสาบที่เป็นรูปธรรม

มุมมองทะเลสาบที่เป็นรูปธรรมจากภูมิภาคเดิมยังคงไม่พร้อมใช้งานสําหรับลูกค้าหลังจากการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด กําหนดการรีเฟรชและประวัติการดําเนินการจะไม่ถูกจําลองแบบไปยังภูมิภาครอง หากต้องการกู้คืน ให้ทําตามขั้นตอนต่อไปนี้หลังจากกู้คืนข้อมูล Lakehouse แล้ว

• กู้คืนตาราง Lakehouse โดยใช้แนวทางที่ 1 หรือแนวทางที่ 2 ที่อธิบายไว้ข้างต้น คัดลอกเฉพาะตารางต้นฉบับ
• กู้คืนสมุดบันทึกที่มีคําจํากัดความ MLV ของคุณ อ้างถึงส่วน Notebook สําหรับขั้นตอนการกู้คืน
• เรียกใช้สมุดบันทึกที่กู้คืนเพื่อสร้าง MLV ใหม่ใน Lakehouse ใหม่ สําหรับข้อมูลเกี่ยวกับการสร้าง MLV โปรดดู สร้าง Lake View ที่เป็นรูปธรรม หากมีการคัดลอก MLV ในขั้นตอนก่อนหน้านี้ด้วย ให้เรียกใช้ CREATE OR REPLACE ขณะสร้างใหม่
• สร้างกําหนดการรีเฟรช MLV ใหม่ด้วยตนเองในพื้นที่ทํางานใหม่ ประวัติกําหนดการและเมตริกการดําเนินการไม่สามารถกู้คืนได้
• หาก MLV ของคุณฟีดโมเดลหรือรายงานเชิงความหมาย ให้ตรวจสอบและอัปเดตการอ้างอิง Lakehouse ID และ Dataset ID ตามต้องการ เชื่อมต่อรายงานกับแบบจําลองความหมายที่อัปเดตอีกครั้งและตรวจสอบความใหม่ของข้อมูล

เคล็ดลับ

เมื่อต้องการลดการเปลี่ยนแปลงโค้ดเมื่อเรียกใช้สมุดบันทึกหลังการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด ให้ใช้ชื่อพื้นที่ทํางานและชื่อ Lakehouse เดียวกันในภูมิภาคใหม่ (โดยเฉพาะอย่างยิ่งเมื่อใช้ชื่อพื้นที่ทํางานหรือชื่อ Lakehouse ในแบบแผนการตั้งชื่อ) กําหนดการรีเฟรช ประวัติการดําเนินการ และเมตริกการดําเนินงานเริ่มต้นใหม่ในภูมิภาคที่กู้คืน วางแผนสําหรับช่วงเวลาพื้นฐานเมื่อสร้างเกณฑ์การตรวจสอบใหม่

โน้ตบุ๊ก

โน้ตบุ๊กจากภูมิภาคหลักยังคงไม่พร้อมใช้งานสําหรับลูกค้า และโค้ดในสมุดบันทึกจะไม่ถูกจําลองแบบไปยังภูมิภาครอง ในการกู้คืนรหัสสมุดบันทึกในภูมิภาคใหม่ มีสองวิธีในการกู้คืนเนื้อหารหัสสมุดบันทึก

วิธี 1: ความซ้ําซ้อนที่จัดการโดยผู้ใช้ด้วยการรวม Git (ในการแสดงตัวอย่างสาธารณะ)

วิธีที่ดีที่สุดในการทําให้ง่ายและรวดเร็วคือการใช้การรวม Fabric Git จากนั้นซิงโครไนซ์โน้ตบุ๊กของคุณกับที่เก็บ ADO ของคุณ หลังจากที่บริการล้มเหลวในภูมิภาคอื่น คุณสามารถใช้ repo เพื่อสร้างสมุดบันทึกในพื้นที่ทํางานใหม่ที่คุณสร้างขึ้น

1. กําหนดค่า Git Integration สําหรับพื้นที่ทํางานของคุณ และเลือก เชื่อมต่อและซิงค์ ด้วย ADO repo

   

   รูปต่อไปนี้แสดงสมุดบันทึกที่ซิงค์

   

2. กู้คืนสมุดบันทึกจากที่เก็บ ADO

   1. ในพื้นที่ทํางานที่สร้างขึ้นใหม่ ให้เชื่อมต่อกับที่เก็บ Azure ADO ของคุณอีกครั้ง

      

   2. เลือกปุ่มตัวควบคุมแหล่งข้อมูล จากนั้นเลือกสาขาที่เกี่ยวข้องของ repo จากนั้นเลือก อัปเดตทั้งหมด สมุดบันทึกต้นฉบับจะปรากฏขึ้น

      

      

   3. ถ้าสมุดบันทึกต้นฉบับมีเลคเฮ้าส์ค่าเริ่มต้น ผู้ใช้สามารถอ้างอิงไปยัง ส่วนของ เลคเฮ้าส์เพื่อกู้คืน lakehouse และเชื่อมต่อเลคเฮ้าส์ที่กู้คืนใหม่ไปยังสมุดบันทึกที่กู้คืนมาใหม่

      

   4. การรวม Git ไม่สนับสนุนการซิงค์ไฟล์ โฟลเดอร์ หรือสแนปช็อตของสมุดบันทึกในตัวสํารวจทรัพยากรของสมุดบันทึก

      1. ถ้าสมุดบันทึกต้นฉบับมีไฟล์ในตัวสํารวจทรัพยากรของสมุดบันทึก:

         1. ตรวจสอบให้แน่ใจว่าได้บันทึกแฟ้มหรือโฟลเดอร์ลงในดิสก์ภายในเครื่องหรือในที่อื่น

         2. อัปโหลดไฟล์จากดิสก์ภายในเครื่องหรือไดรฟ์คลาวด์ไปยังสมุดบันทึกที่กู้คืนอีกครั้ง

      2. ถ้าสมุดบันทึกต้นฉบับมีสแนปช็อตสมุดบันทึก ให้บันทึกสแนปช็อตสมุดบันทึกไปยังระบบควบคุมเวอร์ชันของคุณเองหรือดิสก์ภายในเครื่อง

         

         

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการรวม Git ดู บทนําสู่การรวม Git

วิธี 2: การสํารองเนื้อหาโค้ดด้วยตนเอง

ถ้าคุณไม่ได้ใช้วิธีการรวม Git คุณสามารถบันทึกเวอร์ชันล่าสุดของโค้ด ของคุณ ไฟล์ในตัวสํารวจทรัพยากร และสแนปช็อตของสมุดบันทึกในระบบควบคุมเวอร์ชันเช่น Git และกู้คืนเนื้อหาสมุดบันทึกด้วยตนเองหลังจากเกิดความเสียหาย:

1. ใช้คุณลักษณะ "นําเข้าสมุดบันทึก" เพื่อนําเข้ารหัสสมุดบันทึกที่คุณต้องการกู้คืน

   

2. หลังจากนําเข้า ให้ไปยังพื้นที่ทํางานที่คุณต้องการ (ตัวอย่างเช่น "C2 W2") เพื่อเข้าถึง

3. ถ้าสมุดบันทึกต้นฉบับมีเลคเฮ้าส์ตามค่าเริ่มต้น โปรดดูที่ ส่วนของเลคเฮ้าส์ จากนั้นเชื่อมต่อ lakehouse ที่กู้คืนมาใหม่ (ที่มีเนื้อหาเดียวกันกับ lakehouse เดิม) กับสมุดบันทึกที่กู้คืนมาใหม่

4. ถ้าสมุดบันทึกต้นฉบับมีแฟ้มหรือโฟลเดอร์ใน resource explorer ให้อัปโหลดแฟ้มหรือโฟลเดอร์ที่บันทึกไว้ในระบบควบคุมรุ่นของผู้ใช้อีกครั้ง

ข้อกําหนดงาน Spark

ข้อกําหนดงาน Spark (SJD) จากภูมิภาคหลักยังคงไม่พร้อมใช้งานสําหรับลูกค้า และไฟล์ข้อกําหนดหลักและไฟล์อ้างอิงในสมุดบันทึกจะถูกจําลองไปยังภูมิภาครองผ่าน OneLake หากคุณต้องการกู้คืน SJD ในภูมิภาคใหม่คุณสามารถทําตามขั้นตอนด้วยตนเองที่อธิบายไว้ด้านล่างเพื่อกู้คืน SJD การวิ่งในอดีตของ SJD จะไม่ได้รับการกู้คืน

คุณสามารถกู้คืนรายการ SJD ได้โดยการคัดลอกโค้ดจากภูมิภาคเดิมโดยใช้ Azure Storage Explorer และเชื่อมต่อการอ้างอิง Lakehouse อีกครั้งด้วยตนเองหลังจากเกิดภัยพิบัติ

1. สร้างรายการ SJD ใหม่ (ตัวอย่างเช่น SJD1) ในพื้นที่ทํางานใหม่ C2 W2 ที่มีการตั้งค่าและการกําหนดค่าเดียวกันกับรายการ SJD เดิม (ตัวอย่างเช่น ภาษา สภาพแวดล้อม และอื่น ๆ)

2. ใช้ Azure Storage Explorer เพื่อคัดลอก Libs, Main และ Snapshots จากรายการ SJD ต้นฉบับไปยังรายการ SJD ใหม่

   

3. เนื้อหาโค้ดจะปรากฏใน SJD ที่สร้างขึ้นใหม่ คุณจะต้องเพิ่มการอ้างอิงของเลคเฮาส์ที่กู้คืนใหม่ด้วยตนเองไปยังงาน (ดูขั้นตอนการกู้คืนของ Lakehouse) ผู้ใช้จะต้องใส่อาร์กิวเมนต์บรรทัดคําสั่งเดิมใหม่ด้วยตนเอง

   

ตอนนี้คุณสามารถเรียกใช้หรือกําหนดเวลา SJD ที่กู้คืนมาใหม่ของคุณได้

สําหรับรายละเอียดเกี่ยวกับ Azure Storage Explorer โปรดดู รวม OneLake กับ Azure Storage Explorer

GraphQL

รายการ GraphQL จากภูมิภาคหลักไม่พร้อมใช้งานหลังจากเกิดภัยพิบัติระดับภูมิภาค และข้อกําหนดและการกําหนดค่า GraphQL จะไม่ถูกจําลองแบบไปยังภูมิภาครอง หากต้องการกู้คืน GraphQL ในภูมิภาคใหม่ ให้ใช้วิธีใดวิธีหนึ่งต่อไปนี้

วิธี 1: ความซ้ําซ้อนที่จัดการโดยผู้ใช้ด้วยการรวม Git (ในการแสดงตัวอย่างสาธารณะ)

วิธีที่ดีที่สุดในการทําให้กระบวนการนี้ง่ายและรวดเร็วคือการใช้การรวม Fabric Git จากนั้นซิงโครไนซ์ GraphQL ของคุณกับที่เก็บ ADO ของคุณ หลังจากที่บริการล้มเหลวไปยังภูมิภาคอื่นคุณสามารถใช้ที่เก็บเพื่อสร้าง GraphQL ใหม่ในพื้นที่ทํางานใหม่ที่คุณสร้างขึ้น

1. สร้างพื้นที่ทํางานใหม่ในความจุและภูมิภาคเป้าหมาย

2. กู้คืนแหล่งข้อมูลที่ขึ้นต่อกันทั้งหมด เช่น ฐานข้อมูล Lakehouse, Warehouse หรือ SQL โดยทําตามขั้นตอนการกู้คืนที่เกี่ยวข้อง

3. อัปเดตข้อกําหนด GraphQL เพื่อชี้ไปยังทรัพยากรที่กู้คืนใหม่โดยการปรับเปลี่ยนการอ้างอิงเฉพาะสภาพแวดล้อม เช่น รหัสพื้นที่ทํางานต้นทาง รหัสสิ่งประดิษฐ์ต้นทาง และรายละเอียดการเชื่อมต่อ ขั้นตอนนี้ช่วยให้มั่นใจได้ถึงการผูกที่ถูกต้องในเวลาการปรับใช้

4. ปรับใช้สิ่งประดิษฐ์ GraphQL ใหม่จากที่เก็บ Git ไปยังพื้นที่ทํางานใหม่ ขั้นตอนนี้จะสร้างโครงสร้าง API และการตั้งค่าคอนฟิกใหม่โดยใช้ข้อกําหนดที่อัปเดต

5. ใช้การตั้งค่าสิ่งประดิษฐ์อีกครั้ง รวมถึงบทบาท การควบคุมการเข้าถึง และการกําหนดค่าการรับรองความถูกต้อง

6. ใช้การอ้างอิงปลายทางอีกครั้งโดยอัปเดตแอปพลิเคชันหรือการผสานรวมเพื่อใช้ตําแหน่งข้อมูล GraphQL ที่สร้างขึ้นใหม่

7. อัปเดตไปป์ไลน์การปรับใช้ที่มีอยู่ซึ่งชี้ไปที่พื้นที่ทํางานเก่าเพื่ออ้างอิงพื้นที่ทํางานที่สร้างขึ้นใหม่

8. ตรวจสอบฟังก์ชันการทํางานแบบ end-to-end ของ API

แนวทางที่ 2: แนวทางด้วยตนเอง

หากคุณไม่ใช้วิธีการรวม Git คุณสามารถใช้วิธีการด้วยตนเองต่อไปนี้เพื่อกู้คืน GraphQL

1. สร้างพื้นที่ทํางานใหม่ในความจุและภูมิภาคเป้าหมาย

2. กู้คืนแหล่งข้อมูลที่ขึ้นต่อกันทั้งหมด เช่น ฐานข้อมูล Lakehouse, Warehouse หรือ SQL

3. สร้าง GraphQL API ใหม่ด้วยตนเองในพื้นที่ทํางานใหม่ รวมถึงข้อกําหนด Schema การเชื่อมต่อแหล่งข้อมูล และความสัมพันธ์

4. ใช้การตั้งค่าสิ่งประดิษฐ์อีกครั้ง รวมถึงบทบาท การควบคุมการเข้าถึง และการกําหนดค่าการรับรองความถูกต้อง

5. ใช้การอ้างอิงปลายทางอีกครั้งโดยอัปเดตแอปพลิเคชันหรือการผสานรวมเพื่อใช้ตําแหน่งข้อมูล GraphQL ที่สร้างขึ้นใหม่

6. อัปเดตไปป์ไลน์การปรับใช้ที่มีอยู่ซึ่งชี้ไปที่พื้นที่ทํางานเก่าเพื่ออ้างอิงพื้นที่ทํางานที่สร้างขึ้นใหม่

7. ตรวจสอบฟังก์ชันการทํางานแบบ end-to-end ของ API

ข้อควรพิจารณาที่สำคัญ

1. GraphQL อาศัยการพึ่งพาภายนอก (เช่น Lakehouse, Warehouse และ SQL) ซึ่งคุณต้องกู้คืนก่อนการปรับใช้ GraphQL

2. คําจํากัดความ GraphQL API รวมถึงการอ้างอิงเฉพาะสภาพแวดล้อม (เช่น sourceWorkspaceId และ sourceItemId) เมื่อกู้คืนในภูมิภาคใหม่ การอ้างอิงเหล่านี้อาจไม่ถูกต้อง อัปเดตให้ชี้ไปที่ทรัพยากรที่เตรียมใช้งานใหม่

3. ไม่รับประกันการผูกแหล่งข้อมูลใหม่โดยอัตโนมัติในสถานการณ์การกู้คืนจากภัยพิบัติ โดยเฉพาะอย่างยิ่งเมื่อใช้ข้อมูลประจําตัวที่บันทึกไว้หรือการเชื่อมต่อข้ามพื้นที่ทํางาน

4. การตั้งค่าสิ่งประดิษฐ์อื่นๆ เช่น การตรวจสอบ การอนุญาต RBAC การวิปัสสนา และอื่นๆ จะไม่ส่งต่อหลังจากการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด คุณต้องสร้างการตั้งค่าเหล่านี้ใหม่ในภูมิภาคใหม่

การอ้างอิง

• ภาพรวมของการรวม Fabric Git - Microsoft Fabric | Microsoft เรียนรู้

• ไปป์ไลน์การควบคุมแหล่งที่มาและการปรับใช้ใน API สําหรับ GraphQL - Microsoft Fabric | GraphQL Microsoft เรียนรู้ 

วิทยาศาสตร์ข้อมูล

คู่มือนี้จะแนะนําคุณเกี่ยวกับขั้นตอนการกู้คืนสําหรับประสบการณ์ด้านวิทยาศาสตร์ข้อมูล ครอบคลุมถึงแบบจําลอง ML และการทดลอง

แบบจําลอง ML และการทดลอง

รายการวิทยาศาสตร์ข้อมูลจากภูมิภาคหลักยังคงไม่พร้อมใช้งานสําหรับลูกค้าและเนื้อหาและเมตาดาต้าในแบบจําลอง ML และการทดลองจะไม่ถูกทําซ้ําไปยังภูมิภาครอง หากต้องการกู้คืนอย่างสมบูรณ์ในภูมิภาคใหม่ ให้บันทึกเนื้อหาโค้ดในระบบควบคุมเวอร์ชัน (เช่น Git) และเรียกใช้เนื้อหาของโค้ดด้วยตนเองหลังจากเกิดภัยพิบัติ

1. กู้คืนสมุดบันทึก โปรดดูขั้นตอนการกู้คืนสมุดบันทึก

2. การกําหนดค่า เมตริกการเรียกใช้ในอดีตและเมตาดาต้าจะไม่ถูกทําซ้ําไปยังภูมิภาคที่จับคู่ไว้ คุณจะต้องรีรันแต่ละเวอร์ชันของรหัสวิทยาศาสตร์ข้อมูลของคุณเพื่อกู้คืนแบบจําลอง ML และการทดลองหลังจากเกิดภัยพิบัติ

คลังข้อมูล

คู่มือนี้จะแนะนําคุณตลอดขั้นตอนการกู้คืนสําหรับประสบการณ์ คลังข้อมูล ครอบคลุมคลังสินค้า

คลังสินค้า

คลังสินค้าจากภูมิภาคเดิมยังคงไม่พร้อมใช้งานสําหรับลูกค้า เมื่อต้องการกู้คืนคลังสินค้า ให้ใช้สองขั้นตอนต่อไปนี้

1. สร้างเลคเฮาส์ระหว่างกลางใหม่ในพื้นที่ทํางาน C2 W2 สําหรับข้อมูลที่คุณจะคัดลอกมาจากคลังสินค้าเดิม

2. เติมข้อมูลตารางเดลต้าของคลังสินค้าโดยใช้ประโยชน์จาก Warehouse Explorer และความสามารถ T-SQL (ดู ตารางในคลังข้อมูลใน Microsoft Fabric)

หมายเหตุ

ขอแนะนําให้คุณเก็บโค้ด Warehouse (schema, table, view, stored procedure, function definitions และ security code) ที่มีการกําหนดเวอร์ชันและบันทึกในตําแหน่งที่ตั้งที่ปลอดภัย (เช่น Git) ตามแนวทางปฏิบัติด้านการพัฒนาของคุณ

การนําเข้าข้อมูลผ่านรหัสเลคเฮ้าส์และ T-SQL

ในพื้นที่ทํางาน C2 ที่สร้างขึ้นใหม่ W2:

1. สร้างเลคเฮาส์ระหว่างกลาง "LH2" ใน C2 W2.

2. กู้คืนตาราง Delta ในเลคเฮ้าส์ระหว่างกาลจากคลังสินค้าเดิมโดยทําตามขั้นตอนการกู้คืนของ Lakehouse

3. สร้างคลังสินค้าใหม่ "WH2" ใน C2 W2.

4. เชื่อมต่อเลคเฮ้าส์ระหว่างกลางในตัวสํารวจคลังสินค้าของคุณ

5. T-SQL จริงที่ใช้สําหรับการนําเข้าอาจแตกต่างกันไป ขึ้นอยู่กับวิธีการที่คุณกําลังปรับใช้ข้อกําหนดตารางก่อนที่จะนําเข้าข้อมูล คุณสามารถใช้วิธีแทรกลงในเลือกลงในหรือสร้างตารางเป็นเลือกในการกู้คืนตารางคลังสินค้าจาก lakehouses เพิ่มเติมในตัวอย่าง เราจะใช้ INSERT ลงใน flavor (ถ้าคุณใช้รหัสด้านล่าง ให้แทนที่ตัวอย่างด้วยชื่อตารางและคอลัมน์จริง)

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. สุดท้าย ให้เปลี่ยน สายอักขระการเชื่อมต่อ ในแอปพลิเคชันโดยใช้คลังสินค้า Fabric ของคุณ

หมายเหตุ

สําหรับลูกค้าที่ต้องการการกู้คืนจากภัยพิบัติข้ามภูมิภาคและความต่อเนื่องทางธุรกิจแบบอัตโนมัติเต็มรูปแบบ เราขอแนะนําให้เก็บการตั้งค่า Fabric Warehouse สองรายการไว้ในภูมิภาค Fabric ที่แยกจากกัน และรักษาความเท่าเทียมกันของโค้ดและข้อมูลโดยการปรับใช้และการนําเข้าข้อมูลไปยังทั้งสองไซต์เป็นประจํา

ฐานข้อมูลที่มิเรอร์

ฐานข้อมูลมิเรอร์จากภูมิภาคหลักยังคงไม่พร้อมใช้งานสําหรับลูกค้าและการตั้งค่าจะไม่ถูกทําซ้ําไปยังภูมิภาครอง หากต้องการกู้คืนในกรณีที่ภูมิภาคล้มเหลว คุณต้องสร้างฐานข้อมูลที่มิเรอร์ของคุณในพื้นที่ทํางานอื่นจากภูมิภาคอื่น

คลังข้อมูล

สินค้าจากโรงงานข้อมูลจากภูมิภาคหลักยังคงไม่พร้อมใช้งานสําหรับลูกค้า และการตั้งค่าและการกําหนดค่าในไปป์ไลน์หรือรายการกระแสข้อมูล gen2 จะไม่ถูกจําลองแบบไปยังภูมิภาครอง หากต้องการกู้คืนรายการเหล่านี้ในกรณีที่ภูมิภาคล้มเหลว คุณจะต้องสร้างรายการการรวมข้อมูลของคุณในพื้นที่ทํางานอื่นจากภูมิภาคอื่นอีกครั้ง ส่วนต่อไปนี้แสดงรายละเอียด

กระแสข้อมูล รุ่น 2

หากคุณต้องการกู้คืนรายการ Dataflow Gen2 ในภูมิภาคใหม่คุณต้องส่งออกไฟล์ PQT ไปยังระบบควบคุมเวอร์ชันเช่น Git จากนั้นกู้คืนเนื้อหา Dataflow Gen2 ด้วยตนเองหลังจากเกิดภัยพิบัติ

1. จากรายการกระแสข้อมูล Gen2 ของคุณ ในแท็บ หน้าแรก ของตัวแก้ไข Power Query ให้เลือก ส่งออกเทมเพลต

   

2. ในกล่องโต้ตอบ ส่งออกเทมเพลต ให้ป้อนชื่อ (จําเป็น) และคําอธิบาย (ไม่บังคับ) สําหรับเทมเพลตนี้ เมื่อดำเนินการเสร็จสิ้น เลือก ตกลง

   

3. หลังจากเกิดภัยพิบัติ ให้สร้างรายการ Dataflow Gen2 ใหม่ในพื้นที่ทํางานใหม่ "C2 W2"

4. จากบานหน้าต่างมุมมองปัจจุบันของตัวแก้ไข Power Query ให้เลือก นําเข้าจากเทมเพลต Power Query

   

5. ในกล่องโต้ตอบ เปิด ให้เรียกดูโฟลเดอร์ดาวน์โหลดเริ่มต้นของคุณ และเลือก ไฟล์ .pqt ที่คุณบันทึกไว้ในขั้นตอนก่อนหน้า จากนั้นเลือก เปิด

6. จากนั้นเทมเพลตจะถูกนําเข้าลงในรายการ Dataflow Gen2 ใหม่ของคุณ

คุณลักษณะบันทึกเป็นกระแสข้อมูลไม่ได้รับการสนับสนุนในกรณีที่มีการกู้คืนจากความเสียหาย

Pipelines

ลูกค้าไม่สามารถเข้าถึงไปป์ไลน์ได้ในกรณีที่เกิดภัยพิบัติระดับภูมิภาค และการตั้งค่าคอนฟิกจะไม่ถูกจําลองแบบไปยังภูมิภาคที่จับคู่ เราขอแนะนําให้สร้างไปป์ไลน์ที่สําคัญของคุณในพื้นที่ทํางานหลายแห่งในภูมิภาคต่างๆ

คัดลอกงาน

ผู้ใช้ CopyJob ต้องปฏิบัติตามมาตรการเชิงรุกเพื่อป้องกันภัยพิบัติในภูมิภาค วิธีการต่อไปนี้ทําให้มั่นใจได้ว่าหลังจากเกิดภัยพิบัติในภูมิภาค CopyJobs ของผู้ใช้จะยังคงพร้อมใช้งาน

ความซ้ําซ้อนที่ผู้ใช้จัดการด้วยการรวม Git (ในการแสดงตัวอย่างสาธารณะ)

วิธีที่ดีที่สุดในการทําให้กระบวนการนี้ง่ายและรวดเร็วคือการใช้การรวม Fabric Git จากนั้นซิงโครไนซ์ CopyJob ของคุณกับที่เก็บ ADO ของคุณ หลังจากที่บริการล้มเหลวในภูมิภาคอื่น คุณสามารถใช้ที่เก็บเพื่อสร้าง CopyJob ในพื้นที่ทํางานใหม่ที่คุณสร้างขึ้น

1. กําหนดค่า Git Integration ของพื้นที่ทํางานและเลือก เชื่อมต่อและซิงค์ ด้วย ADO repo

   

   รูปภาพต่อไปนี้แสดง CopyJob ที่ซิงค์

   

2. กู้คืน CopyJob จาก ADO repo

   1. ในพื้นที่ทํางานที่สร้างขึ้นใหม่ ให้เชื่อมต่อและซิงค์กับที่เก็บ Azure ADO ของคุณอีกครั้ง รายการ Fabric ทั้งหมดในที่เก็บนี้จะถูกดาวน์โหลดไปยังพื้นที่ทํางานใหม่ของคุณโดยอัตโนมัติ

      

   2. หาก CopyJob ต้นฉบับใช้เลคเฮ้าส์ ผู้ใช้สามารถดูส่วน Lakehouse กู้คืนของเลคเฮ้าส์และเชื่อมต่อ CopyJob ที่กู้คืนใหม่กับเลคเฮ้าส์ที่กู้คืนมาใหม่

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการรวม Git ดู บทนําสู่การรวม Git

งานกระแสอากาศ Apache

ผู้ใช้ Apache Airflow Job in Fabric ต้องดําเนินมาตรการเชิงรุกเพื่อป้องกันภัยพิบัติในภูมิภาค

เราขอแนะนําให้จัดการความซ้ําซ้อนด้วยการรวม Fabric Git ขั้นแรก ให้ซิงโครไนซ์งาน Airflow ของคุณกับที่เก็บ ADO ของคุณ หากบริการล้มเหลวไปยังภูมิภาคอื่น คุณสามารถใช้ที่เก็บเพื่อสร้างงาน Airflow ใหม่ในพื้นที่ทํางานใหม่ที่คุณสร้างขึ้น

นี่คือขั้นตอนในการบรรลุเป้าหมายนี้:

1. กําหนดค่าการรวม Git ของพื้นที่ทํางานของคุณ และเลือก "เชื่อมต่อและซิงค์" กับที่เก็บ ADO

2. หลังจากนั้น คุณจะเห็นงาน Airflow ของคุณถูกซิงค์กับที่เก็บ ADO ของคุณแล้ว

3. หากคุณต้องการกู้คืนงาน Airflow จากที่เก็บ ADO ให้สร้างพื้นที่ทํางานใหม่ เชื่อมต่อ และซิงค์กับที่เก็บ Azure ADO ของคุณอีกครั้ง รายการ Fabric ทั้งหมด รวมถึง Airflow ในที่เก็บนี้จะถูกดาวน์โหลดไปยังพื้นที่ทํางานใหม่ของคุณโดยอัตโนมัติ

ระบบอัจฉฉริยะในเวลาจริง

คู่มือนี้จะแนะนําคุณผ่านขั้นตอนการกู้คืนสําหรับประสบการณ์ Real-Time Intelligence ซึ่งครอบคลุมฐานข้อมูล KQL/คิวรีและเหตุการณ์สตรีม

Activator

รายการ Activator จากภูมิภาคหลักยังคงไม่พร้อมใช้งานสําหรับลูกค้า และข้อกําหนดทริกเกอร์ Activator จะไม่ถูกจําลองแบบไปยังภูมิภาครอง ผู้ใช้ Activator ต้องดําเนินการเชิงรุกเพื่อเตรียมพร้อมสําหรับการกู้คืนจากภัยพิบัติในระดับภูมิภาค

เพื่อให้แน่ใจว่าคุณสามารถกู้คืนรายการ Activator ได้ในกรณีที่เกิดภัยพิบัติระดับภูมิภาค ให้ตั้งค่าการรวม Fabric Git เพื่อสํารองข้อกําหนดทริกเกอร์และกู้คืนในพื้นที่ทํางานในภูมิภาคอื่น

1. กําหนดค่าการรวม Fabric Git สําหรับพื้นที่ทํางานที่มีรายการ Activator ของคุณ และซิงโครไนซ์ข้อกําหนดทริกเกอร์ของคุณกับที่เก็บ Git ของคุณ
2. รักษาคําจํากัดความทริกเกอร์ Activator ของคุณและซิงค์อย่างสม่ําเสมอ
3. ในระหว่างการกู้คืน ให้สร้างพื้นที่ทํางานใหม่ในภูมิภาคเป้าหมาย (C2. W2) เชื่อมต่อกับที่เก็บเดียวกัน และซิงค์เพื่อกู้คืนคําจํากัดความของทริกเกอร์
4. กําหนดค่าใหม่และตรวจสอบความถูกต้องของแหล่งข้อมูล Activator และการขึ้นต่อกันทั้งหมดในพื้นที่ทํางานใหม่

หมายเหตุ

กระบวนการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาดของ Fabric มาตรฐานใช้ไม่ได้กับรายการ Activator การกู้คืนจะจํากัดเฉพาะการสํารองข้อมูลตาม Git และการกู้คืนคําจํากัดความทริกเกอร์

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการรวม Git ดู บทนําสู่การรวม Git

โมเดลกราฟ/ชุดคิวรี

รายการแบบจําลองกราฟและชุดคิวรีกราฟจากภูมิภาคหลักยังคงไม่พร้อมใช้งานสําหรับลูกค้า และรายการเหล่านี้จะไม่ถูกจําลองแบบไปยังภูมิภาครอง เมื่อต้องการกู้คืน สร้างหรือใช้ความจุในภูมิภาคอื่น และสร้างรายการ Graph Model และ Graph Queryset ใหม่ที่นั่น

1. สร้างหรือใช้ความจุ Fabric ที่มีอยู่ในภูมิภาคอื่นที่ไม่ได้รับผลกระทบจากภัยพิบัติ

2. สร้างพื้นที่ทํางานใหม่หรือใช้พื้นที่ทํางานที่มีอยู่ในความจุนั้น

3. สร้างรายการแบบจําลองกราฟใหม่ในพื้นที่ทํางานรอง (อ้างอิงในขั้นตอนที่ 2) กําหนดค่าคําจํากัดความของโมเดลใหม่ รวมถึงโหนด ขอบ ฯลฯ เพื่อให้ตรงกับโมเดลกราฟดั้งเดิม

4. หากเลคเฮาส์เดิมอยู่ในภูมิภาคที่ล้มเหลว ให้กู้คืนก่อนโดยทําตามส่วนเลคเฮาส์

5. เชื่อมต่อเลคเฮาส์เป็นแหล่งข้อมูล OneLake สําหรับรายการแบบจําลองกราฟที่สร้างขึ้นใหม่ ใช้เลคเฮาส์ที่กู้คืนมาหากอยู่ในภูมิภาคที่ล้มเหลว หรือเชื่อมต่อกับเลคเฮาส์ที่มีอยู่อีกครั้งหากยังคงมีอยู่

6. กําหนดค่ากําหนดการโหลดข้อมูลหรือการเชื่อมต่อใหม่สําหรับแบบจําลองกราฟในพื้นที่ทํางานใหม่

7. สร้างรายการ Graph Queryset ใหม่ในพื้นที่ทํางานรอง ป้อนคิวรีและการกําหนดค่าคิวรีที่บันทึกไว้จากชุดคิวรีกราฟเดิมอีกครั้งด้วยตนเอง

ฐานข้อมูล KQL/ชุดคิวรี

ผู้ใช้ฐานข้อมูล/ชุดคิวรี KQL ต้องดําเนินการมาตรการเชิงรุกเพื่อป้องกันภัยพิบัติในภูมิภาค วิธีการต่อไปนี้ทําให้มั่นใจได้ว่าในกรณีที่เกิดภัยพิบัติระดับภูมิภาค ข้อมูลในชุดข้อมูลคิวรีของฐานข้อมูล KQL ของคุณจะยังคงปลอดภัยและสามารถเข้าถึงได้

ใช้ขั้นตอนต่อไปนี้เพื่อรับประกันโซลูชันการกู้คืนจากภัยพิบัติที่มีประสิทธิภาพสําหรับฐานข้อมูล KQL และชุดคิวรี

1. สร้างฐานข้อมูล KQL อิสระ: กําหนดค่าฐานข้อมูล/ชุดคิวรี KQL อิสระตั้งแต่สองฐานข้อมูลขึ้นไปบนความจุ Fabric เฉพาะ ควรตั้งค่าสิ่งเหล่านี้ในภูมิภาค Azure สองภูมิภาคที่แตกต่างกัน (ควรเป็นภูมิภาคที่จับคู่กับ Azure) เพื่อเพิ่มความยืดหยุ่นสูงสุด

2. กิจกรรมการจัดการจําลองแบบ: การดําเนินการจัดการใด ๆ ที่เกิดขึ้นในฐานข้อมูล KQL หนึ่งควรสะท้อนในอีกด้านหนึ่ง ซึ่งทําให้แน่ใจว่ายังคงมีการซิงค์ฐานข้อมูลทั้งสอง กิจกรรมหลักที่จะทําซ้ําประกอบด้วย:

   • ตาราง: ตรวจสอบให้แน่ใจว่าโครงสร้างตารางและข้อกําหนด Schema สอดคล้องกันทั่วทั้งฐานข้อมูล

   • การแมป: ทําซ้ําการทําแผนที่ที่จําเป็น ตรวจสอบให้แน่ใจว่าแหล่งข้อมูลและปลายทางจัดแนวได้อย่างถูกต้อง

   • นโยบาย: ตรวจสอบให้แน่ใจว่าทั้งสองฐานข้อมูลมีการเก็บรักษาข้อมูล การเข้าถึง และนโยบายที่เกี่ยวข้องอื่น ๆ ที่คล้ายกัน

3. จัดการการรับรองความถูกต้องและการอนุญาต: สําหรับแต่ละแบบจําลอง ให้ตั้งค่าสิทธิ์ที่จําเป็น ตรวจสอบให้แน่ใจว่ามีการกําหนดระดับการอนุญาตที่เหมาะสมอนุญาตให้เข้าถึงบุคลากรที่จําเป็นในขณะที่รักษามาตรฐานความปลอดภัย

4. การนําเข้าข้อมูลแบบขนาน: เพื่อให้ข้อมูลสอดคล้องและพร้อมในหลายภูมิภาค ให้โหลดชุดข้อมูลเดียวกันลงในฐานข้อมูล KQL แต่ละฐานข้อมูลในเวลาเดียวกันกับที่คุณนําเข้า

เหตุการณ์สตรีม

สตรีมเหตุการณ์เป็นสถานที่ส่วนกลางในแพลตฟอร์ม Fabric สําหรับการจับภาพ แปลง และกําหนดเส้นทางเหตุการณ์แบบเรียลไทม์ไปยังปลายทางต่างๆ (เช่น เลคเฮาส์ ฐานข้อมูล/ชุดคิวรี KQL) ด้วยประสบการณ์แบบไม่ใช้โค้ด ตราบใดที่ปลายทางได้รับการสนับสนุนจากการกู้คืนจากภัยพิบัติ กระแสข้อมูลจะไม่สูญเสียข้อมูล ดังนั้น ลูกค้าควรใช้ความสามารถในการกู้คืนจากภัยพิบัติของระบบปลายทางเหล่านั้นเพื่อรับประกันความพร้อมใช้งานของข้อมูล

ลูกค้ายังสามารถบรรลุความซ้ําซ้อนทางภูมิศาสตร์ได้ด้วยการปรับใช้ปริมาณงาน Eventstream ที่เหมือนกันในภูมิภาค Azure หลายแห่ง ซึ่งเป็นส่วนหนึ่งของกลยุทธ์ที่ใช้งานอยู่/ใช้งานอยู่หลายไซต์ ด้วยวิธีการที่ใช้งานอยู่/ใช้งานอยู่ในหลายไซต์ ลูกค้าสามารถเข้าถึงปริมาณงานของพวกเขาในภูมิภาคใด ๆ ที่ปรับใช้ได้ วิธีการนี้เป็นวิธีการที่ซับซ้อนและมีราคาแพงที่สุดในการกู้คืนความเสียหาย แต่สามารถลดเวลาการกู้คืนให้ใกล้เคียงกับศูนย์ในสถานการณ์ส่วนใหญ่ ลูกค้าสามารถ

1. สร้างแบบจําลองของแหล่งข้อมูลของพวกเขาในภูมิภาคต่าง ๆ

2. สร้างรายการเหตุการณ์ในภูมิภาคที่สอดคล้องกัน

3. เชื่อมต่อรายการใหม่เหล่านี้กับแหล่งข้อมูลที่เหมือนกัน

4. เพิ่มปลายทางที่เหมือนกันสําหรับแต่ละกระแสข้อมูลในภูมิภาคต่าง ๆ

เหตุการณ์ทางธุรกิจ เหตุการณ์ Fabric และเหตุการณ์ Azure

แม้ว่าเหตุการณ์ทางธุรกิจ เหตุการณ์ Fabric และเหตุการณ์ Azure จะใช้โครงสร้างพื้นฐานฮับ Real-Time เดียวกันใน Microsoft Fabric แต่ก็มีที่มา พฤติกรรม และข้อกําหนดในการกู้คืนที่แตกต่างกันซึ่งต้องเข้าใจก่อนวางแผนสําหรับการกู้คืนจากภัยพิบัติ:

• เหตุการณ์ Fabric คือการสมัครใช้งานเหตุการณ์ที่ตอบสนองต่อกิจกรรมที่สร้างโดยทรัพยากร Fabric เอง รวมถึงการเปลี่ยนแปลงวงจรชีวิตของรายการพื้นที่ทํางาน (เช่น การสร้าง การอัปเดต หรือการลบเลคเฮาส์ สมุดบันทึก หรือคลังสินค้า) การดําเนินการงาน (เช่น การเรียกใช้ไปป์ไลน์หรือการดําเนินการสมุดบันทึก) และการดําเนินการไฟล์และโฟลเดอร์ OneLake การสมัครสมาชิกเหล่านี้เป็นแบบพุชและชั่วคราว การสมัครใช้งานจะไม่ถูกจําลองแบบไปยังภูมิภาครอง

• Azure Events คือการสมัครใช้งานเหตุการณ์สําหรับกิจกรรมที่สร้างโดยบัญชี Azure Blob Storage ทรัพยากร Azure เหล่านี้มีอยู่โดยไม่ขึ้นกับความจุหรือภูมิภาคของ Fabric แม้ว่าทรัพยากร Azure Blob Storage เองอาจยังคงพร้อมใช้งานในระหว่างการหยุดทํางานของภูมิภาค Fabric แต่การสมัครใช้งานที่กําหนดค่า Real-Time ในฮับจะไม่ถูกจําลองแบบไปยังภูมิภาครอง และต้องสร้างขึ้นใหม่

• เหตุการณ์ทางธุรกิจเป็นความสามารถที่แตกต่างใน Fabric Real-Time Intelligence ที่ช่วยให้ทีมสามารถกําหนด เผยแพร่ และดําเนินการกับสัญญาณทางธุรกิจที่มีความหมายได้ เหตุการณ์ทางธุรกิจถูกสร้างขึ้นจากภายใน Fabric ผ่าน Activator, สมุดบันทึก Spark หรือฟังก์ชันข้อมูลผู้ใช้ จากนั้นเผยแพร่ไปยังฮับ Real-Time ที่ผู้บริโภคปลายทาง เช่น Activator, Eventhouse หรือ Power Automate สามารถตอบสนองต่อเหตุการณ์เหล่านั้นได้ สคีมาเหตุการณ์ถูกควบคุมจากส่วนกลางผ่าน Schema Registry Eventhouse จะจัดเก็บเหตุการณ์ทางธุรกิจที่เผยแพร่ทั้งหมดโดยอัตโนมัติ ดังนั้นการกู้คืนจึงส่งผลโดยตรงต่อความพร้อมใช้งานของประวัติเหตุการณ์ทางธุรกิจ ไม่มีการกําหนดค่าผู้เผยแพร่หรือผู้บริโภค คําจํากัดความ Schema หรือการสมัครใช้งานถูกจําลองแบบไปยังภูมิภาครอง

ใช้ขั้นตอนต่อไปนี้เพื่อคืนค่าเหตุการณ์ทางธุรกิจ เหตุการณ์ Fabric และเหตุการณ์ Azure ในพื้นที่ทํางานใหม่ในภูมิภาคการกู้คืน

สําหรับกิจกรรมทางธุรกิจ:

1. สร้างเหตุการณ์ทางธุรกิจที่ผู้เผยแพร่และผู้บริโภคใช้ใหม่โดยทําตามบทความ สร้างเหตุการณ์ทางธุรกิจใน Fabric Real-Time Hub ในระหว่างการสร้างเหตุการณ์ทางธุรกิจ คุณสร้างทรัพยากรชุด Schema เหตุการณ์ ทรัพยากร Eventhouse เป็นทางเลือกขึ้นอยู่กับสถานการณ์

2. สร้างรายการ publisher ที่สร้างเหตุการณ์ทางธุรกิจ เช่น สมุดบันทึก Spark หรือฟังก์ชันข้อมูลผู้ใช้ ในพื้นที่ทํางานใหม่โดยทําตามบทความของ publisher: ใช้ User Data Function เป็น Business Events Publisher, ใช้ Activator เป็น Business Events Publisher, ใช้ Notebook เป็น Business Events Publisher และใช้ Eventstream เป็น Business Events Publisher

3. สร้างการสมัครใช้งานของผู้บริโภคใหม่ในฮับ Real-Time (ตัวอย่างเช่น กฎ Activator ทริกเกอร์สมุดบันทึก หรือโฟลว์ Power Automate) ที่เดิมตอบสนองต่อเหตุการณ์ทางธุรกิจในภูมิภาคที่ได้รับผลกระทบโดยทําตามบทความ Eventhouse และ Real-Time Dashboard Integration กับเหตุการณ์ทางธุรกิจ และ ใช้เหตุการณ์ทางธุรกิจจาก Activator

4. ตรวจสอบว่าเหตุการณ์กําลังไหลแบบ end-to-end โดยตรวจสอบว่าการสมัครใช้งานทํางานอยู่ และข้อมูลกําลังมาถึงปลายทางที่คาดไว้ในภูมิภาคการกู้คืน

สําหรับกิจกรรม Fabric:

1. สร้างการสมัครใช้งานใหม่ในฮับ Real-Time โดยชี้ไปที่รายการพื้นที่ทํางาน งาน หรือเส้นทาง OneLake ที่ถูกคืนค่าในภูมิภาคการกู้คืนโดยทําตามบทความ สํารวจเหตุการณ์ Fabric ในฮับ Fabric Real-Time

2. ตรวจสอบว่าเหตุการณ์กําลังไหลแบบ end-to-end โดยตรวจสอบว่าการสมัครใช้งานทํางานอยู่ และข้อมูลกําลังมาถึงปลายทางที่คาดไว้ในภูมิภาคการกู้คืน

สําหรับเหตุการณ์ Azure:

1. บัญชี Azure Blob Storage ไม่ได้รับผลกระทบจากการหยุดทํางานระดับภูมิภาคของ Fabric สร้างการสมัครใช้งานเหตุการณ์ใหม่ในฮับ Real-Time ที่ชี้ไปยังบัญชี Azure Blob Storage เดียวกันโดยทําตามบทความตั้งค่าการแจ้งเตือนเกี่ยวกับเหตุการณ์ Azure Blob Storage ในฮับ Real-Time

2. ตรวจสอบว่าเหตุการณ์กําลังไหลแบบ end-to-end โดยตรวจสอบว่าการสมัครใช้งานทํางานอยู่ และข้อมูลกําลังมาถึงปลายทางที่คาดไว้ในภูมิภาคการกู้คืน

หมายเหตุ

ประวัติเหตุการณ์สําหรับงานกิจกรรมทางธุรกิจจะขึ้นอยู่กับการกู้คืนของงานกิจกรรม เหตุการณ์ทางธุรกิจ เหตุการณ์ Fabric และเหตุการณ์ Azure เป็นแบบพุชและชั่วคราว ดังนั้นจึงไม่มีข้อมูลเหตุการณ์ในอดีตที่สามารถกู้คืนได้สําหรับชนิดเหล่านั้น เฉพาะเหตุการณ์ที่เกิดขึ้นหลังจากการกู้คืนเสร็จสมบูรณ์เท่านั้นที่จะพร้อมใช้งานในภูมิภาคใหม่

แผนที่

ลูกค้ายังคงใช้รายการแผนที่จากภูมิภาคหลักไม่พร้อมใช้งาน และรายการแผนที่จะไม่ถูกจําลองแบบไปยังภูมิภาครอง

หากคุณต้องการกู้คืนรายการแผนที่เมื่อเกิดภัยพิบัติ ให้ตั้งค่า Fabric การรวม Git และ synchronize รายการแผนที่ของคุณกับที่เก็บ Git ของคุณ

ในระหว่างการกู้คืน หลังจากตั้งค่าภูมิภาค/ความจุใหม่ใน Fabric แล้ว คุณสามารถใช้ที่เก็บเพื่อสร้างรายการ แผนที่ ใหม่ในพื้นที่ทํางานใหม่ที่คุณสร้างขึ้น เนื่องจากพื้นที่ทํางานใหม่ว่างเปล่า Git sync จะรับเนื้อหาจากที่เก็บไปยังพื้นที่ทํางานที่ว่างเปล่า ขั้นตอนนี้ทําให้รายการแผนที่กลับมามีชีวิตอีกครั้ง

หมายเหตุ

หากรายการแผนที่เดิมมีการกําหนดค่าชุดคิวรีเลคเฮาส์หรือ KQL โปรดดู ส่วนเลคเฮาส์ และ ส่วนชุดคิวรี KQL เพื่อกู้คืนก่อน หลังจากจัดการการพึ่งพาเหล่านั้นแล้ว ให้เชื่อมต่อเลคเฮาส์ที่เพิ่งกู้คืนและชุดคิวรีกับรายการแผนที่ที่เพิ่งกู้คืน

ภววิทยา

ผู้ใช้ออนโทโลยีต้องดําเนินการเชิงรุกเพื่อเตรียมพร้อมสําหรับการกู้คืนจากภัยพิบัติในระดับภูมิภาค แนวทางที่อธิบายไว้ด้านล่างช่วยให้มั่นใจได้ว่าหลังจากเกิดภัยพิบัติในระดับภูมิภาค Ontology ของคุณยังคงสามารถกู้คืนได้และสามารถกู้คืนได้อย่างรวดเร็ว

วิธีที่ง่ายและเร็วที่สุดในการเปิดใช้งานการกู้คืนคือการใช้การรวม Fabric Git และซิงโครไนซ์ Ontology ของคุณกับที่เก็บ Azure DevOps (ADO) หากบริการล้มเหลวไปยังภูมิภาคอื่น คุณสามารถใช้ที่เก็บนี้เพื่อสร้าง Ontology ใหม่ในพื้นที่ทํางานที่สร้างขึ้นใหม่

รายการ Ontology ในภูมิภาคหลักไม่พร้อมใช้งานสําหรับลูกค้าหลังจากเกิดภัยพิบัติระดับภูมิภาค และรายการ Ontology จะไม่ถูกจําลองแบบไปยังภูมิภาครอง

เมื่อต้องการกู้คืนรายการ Ontology ในระหว่างภัยพิบัติ ให้กําหนดค่า Fabric Git integration และ synchronize รายการ Ontology กับที่เก็บ ADO ของคุณล่วงหน้า

ในระหว่างการกู้คืน เมื่อตั้งค่าภูมิภาคและความจุใหม่ใน Fabric แล้ว คุณสามารถใช้ที่เก็บเพื่อสร้างรายการ Ontology ใหม่ในพื้นที่ทํางานใหม่ได้ เนื่องจากพื้นที่ทํางานใหม่ว่างเปล่า Git sync จะดึงเนื้อหาจากที่เก็บไปยังพื้นที่ทํางาน ซึ่งจะกู้คืนรายการ Ontology ได้อย่างมีประสิทธิภาพ

หมายเหตุ

หากรายการ Ontology ดั้งเดิมมีการกําหนดค่าเลคเฮาส์ โปรดดู ส่วนเลคเฮาส์ เพื่อกู้คืนเลคเฮาส์ก่อน หลังจากดูแลการพึ่งพาเหล่านั้นแล้ว ให้เชื่อมต่อเลคเฮาส์ที่เพิ่งกู้คืนใหม่กับรายการ Ontology ที่เพิ่งกู้คืน

แผน

บทความนี้อธิบายขั้นตอนการกู้คืนสําหรับประสบการณ์แผนใน IQ โดยสรุปขั้นตอนที่จําเป็นในการคืนค่าส่วนประกอบหลัก รวมถึงการวางแผน PowerTable ข่าวกรอง InfoBridge และสินทรัพย์ข้อมูลที่เกี่ยวข้อง

การรวม Git เพื่อกู้คืนรายการแผน

วิธีการที่ต้องการคือการซิงโครไนส์รายการแผนทั้งหมดกับที่เก็บ Azure DevOps (ADO) หรือ GitHub โดยใช้การรวม Fabric Git หลังจากการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด ให้ใช้ที่เก็บเพื่อคืนค่ารายการในพื้นที่ทํางานใหม่

ก่อนภัยพิบัติ (ขั้นตอนเชิงรุก):

1. ในพื้นที่ทํางาน W1 ไปที่ การตั้งค่าพื้นที่ทํางาน และกําหนดค่าการรวม Git

2. เลือกเชื่อมต่อและซิงค์กับที่เก็บ ADO หรือ GitHub ของคุณ

3. เลือกรายการแผนที่จะอัปโหลดไปยังที่เก็บ แล้วเลือก ยอมรับ

   

4. ยืนยันว่าสถานะ Git ของรายการแผนเป็น ซิงค์แล้ว

5. สร้างวินัยการคอมมิต - คอมมิตหลังจากการเปลี่ยนแปลงที่สําคัญทุกครั้งในคําจํากัดความของแผน เพื่อให้ที่เก็บสะท้อนถึงสถานะล่าสุดเสมอ

ขั้นตอนการกู้คืน:

1. สร้างพื้นที่ทํางาน W2 ใหม่ภายในความจุ C2 ในภูมิภาคที่สมบูรณ์

2. ในพื้นที่ทํางาน W2 ไปที่ การตั้งค่าพื้นที่ทํางาน และเชื่อมต่อกับที่เก็บ ADO/GitHub เดียวกันอีกครั้ง

3. เลือก ตัวควบคุมแหล่งข้อมูล เลือกสาขาที่เก็บที่เกี่ยวข้อง แล้วเลือก อัปเดตทั้งหมด รายการแผนทั้งหมดจะถูกดาวน์โหลดไปยัง W2

สำคัญ

เฉพาะโครงสร้างและการตั้งค่าแผ่นงานการวางแผนเท่านั้นที่จะถูกกู้คืนโดยใช้การรวม Git ข้อมูลที่ป้อนในแผ่นงานการวางแผน เช่น ค่าอินพุต บันทึกย่อ และข้อคิดเห็นจะไม่ถูกคืนค่าโดยอัตโนมัติ ต้องมีการกู้คืน Fabric SQL ข้อมูลแบบจําลองความหมายยังต้องกู้คืนแยกต่างหาก

ส่วนประกอบต่อไปนี้จะได้รับการกู้คืนหลังจากการกู้คืน:

• แผ่นงาน PowerTable: การตั้งค่าตารางต้นฉบับ, การกําหนดค่าคอลัมน์, การเข้าถึงแถว, คุณสมบัติวิชวล (เค้าโครง, รูปแบบ และอื่นๆ), การระบุแถว, การตั้งค่าข้อคิดเห็น, มิติที่เปลี่ยนแปลงอย่างช้าๆ (SCD), การอนุมัติ, ระบบอัตโนมัติ และฟอร์ม
• เอกสารการวางแผน: คุณสมบัติของแผ่นงาน (การจัดรูปแบบ การจัดรูปแบบตามเงื่อนไข และอื่นๆ) การตั้งค่าข้อคิดเห็น การตั้งค่าการเขียนกลับ คอลัมน์การป้อนข้อมูล แถวการป้อนข้อมูล สถานการณ์ และบุ๊กมาร์ก
• อินโฟบริดจ์: แหล่งข้อมูล InfoBridge, คิวรี InfoBridge, ขั้นตอนการแปลง, ปลายทางการเขียนกลับ, การตั้งค่าการเขียนกลับ, การแม็ปคิวรีที่เชื่อมโยง, กลุ่มคิวรี, คุณสมบัติวิชวล (ผสมผสาน) รายการเหล่านี้ไม่สามารถกู้คืนได้: แหล่งข้อมูลแบบไฟล์ (CSV, Excel) แผ่นงานข้ามปริมาณงานที่ใช้แหล่งข้อมูลแบบไฟล์
• หน่วยสืบราชการลับ: แผนภูมิและเมทริกซ์ทั้งหมด

การคืนค่า Fabric SQL สําหรับแผน

ข้อมูลที่ป้อนในแผ่นงานการวางแผน ตารางที่ใช้ใน PowerTable และข้อมูลการเขียนกลับจะถูกเก็บไว้ในฐานข้อมูล SQL และต้องได้รับการพิจารณาเป็นส่วนหนึ่งของกลยุทธ์การกู้คืนจากภัยพิบัติของคุณ เมื่อต้องการกู้คืนฐานข้อมูล SQL ให้ดูที่ส่วนฐานข้อมูล SQL

• กู้คืนข้อมูลเมตาของแผน: แต่ละรายการแผนเชื่อมโยงกับฐานข้อมูล __fabric_plan_sys ที่เก็บข้อมูลเมตาสําหรับคุณลักษณะการวางแผน รวมถึงข้อคิดเห็น สถานการณ์ การป้อนข้อมูล และการกําหนดค่าการเขียนกลับ ฐานข้อมูล __fabric_plan_sys จะไม่ถูกคืนค่าโดยอัตโนมัติ และต้องกู้คืนอย่างชัดเจน

• กู้คืนฐานข้อมูลการเขียนกลับ: หากแผนของคุณใช้ปลายทางการเขียนกลับของ SQL คุณต้องกู้คืนฐานข้อมูลที่เกี่ยวข้องด้วยตนเองด้วย ปลายทางการเขียนกลับ SQL ที่กําหนดค่าไว้จะไม่ถูกคืนค่าโดยอัตโนมัติ

• คืนค่าตารางที่ใช้ใน PowerTable: ตารางใดๆ ที่สร้างขึ้นโดยใช้ PowerTable จะถูกเก็บไว้ในฐานข้อมูล Fabric SQL คุณต้องกู้คืนตารางเหล่านี้ในระหว่าง DR

ตัวแทนปฏิบัติการ

ผู้ใช้ตัวแทนปฏิบัติการควรดําเนินการเชิงรุกเพื่อเตรียมพร้อมสําหรับการกู้คืนจากภัยพิบัติระดับภูมิภาค การปฏิบัติตามแนวทางที่อธิบายไว้ในส่วนนี้จะช่วยให้แน่ใจว่าตัวแทนของคุณสามารถกู้คืนได้อย่างรวดเร็วหลังจากการหยุดทํางานในภูมิภาค

ใช้การรวม Fabric Git เพื่อซิงโครไนซ์พื้นที่ทํางานของคุณกับที่เก็บ วิธีการนี้ช่วยให้คุณสามารถสร้างการกําหนดค่าตัวแทนใหม่ในพื้นที่ทํางานใหม่หากบริการล้มเหลวไปยังภูมิภาคอื่น

ไอเท็มตัวแทนปฏิบัติการในภูมิภาคหลักไม่พร้อมใช้งานในระหว่างภัยพิบัติระดับภูมิภาค การกําหนดค่าตัวแทน แบบจําลองพฤติกรรม และบันทึกกิจกรรมจะไม่ถูกจําลองแบบไปยังภูมิภาครอง การดําเนินการที่กําลังดําเนินการ เซสชันการแชทที่ใช้งานอยู่ และเหตุการณ์ที่นําเข้าก่อนหน้านี้ในช่วงเวลาที่เกิดภัยพิบัติก็สูญหายไปเช่นกัน

เพื่อเตรียมพร้อมสําหรับการกู้คืน ให้กําหนดค่าการรวม Fabric Git และซิงโครไนส์รายการตัวแทนของคุณกับที่เก็บ ADO ของคุณก่อนเกิดภัยพิบัติ

เมื่อกู้คืน ให้ตั้งค่าภูมิภาคและความจุใหม่ของคุณใน Fabric จากนั้นใช้ที่เก็บที่ซิงโครไนซ์เพื่อคืนค่าการกําหนดค่าตัวแทนไปยังพื้นที่ทํางานใหม่ การซิงค์ Git จะดึงเนื้อหาที่เก็บไว้จากที่เก็บไปยังพื้นที่ทํางานที่ว่างเปล่า

เมื่อคืนค่าการกําหนดค่าแล้ว ให้ยืนยันว่าฐานข้อมูล Eventhouse (KQL) ที่อ้างอิงหรือแหล่งข้อมูลเฉพาะภูมิภาคสามารถเข้าถึงได้ในภูมิภาคใหม่ อัปเดตการอ้างอิงปลายทางในการกําหนดค่าตัวแทนตามต้องการ สุดท้าย รีสตาร์ทตัวแทนของคุณและให้ผู้ใช้เริ่มเซสชันการแชทใหม่ การสนทนาก่อนหน้านี้จะกลับมาสนทนาต่อไม่ได้

ฐานข้อมูลธุรกรรม

คู่มือนี้อธิบายขั้นตอนการกู้คืนสําหรับประสบการณ์ฐานข้อมูลธุรกรรม

ฐานข้อมูล SQL

ผู้ใช้ฐานข้อมูล SQL สามารถใช้มาตรการเชิงรุกเพื่อส่งออกข้อมูลของตนเป็นระยะ และใช้ข้อมูลที่ส่งออกเพื่อสร้างฐานข้อมูลใหม่ในพื้นที่ทํางานใหม่เมื่อจําเป็น

สิ่งนี้สามารถทําได้โดยใช้เครื่องมือ SqlPackage CLI ที่ให้การเคลื่อนย้ายฐานข้อมูลและอํานวยความสะดวกในการปรับใช้ฐานข้อมูล

1. ใช้เครื่องมือ SqlPackage เพื่อส่งออกฐานข้อมูลไปยัง .bacpac ไฟล์ ดู ส่งออกฐานข้อมูลด้วย SqlPackage สําหรับรายละเอียดเพิ่มเติม
2. เก็บแฟ้ม .bacpac ไว้ในตําแหน่งที่ตั้งที่ปลอดภัยซึ่งอยู่ในภูมิภาคที่แตกต่างจากฐานข้อมูล ตัวอย่าง ได้แก่ การจัดเก็บไฟล์ .bacpac ใน Lakehouse ที่อยู่ในภูมิภาคอื่น โดยใช้บัญชี Azure Storage ที่ซ้ําซ้อนทางภูมิศาสตร์ หรือการใช้สื่อจัดเก็บข้อมูลที่ปลอดภัยอื่นที่อยู่ในภูมิภาคอื่น
3. ถ้าฐานข้อมูลและภูมิภาค SQL ไม่พร้อมใช้งาน คุณสามารถใช้ไฟล์กับ .bacpac SqlPackage เพื่อสร้างฐานข้อมูลใหม่ในพื้นที่ทํางานในภูมิภาคใหม่ – พื้นที่ทํางาน C2 W2 ในภูมิภาค B ตามที่อธิบายไว้ในสถานการณ์สมมติข้างต้น ทําตามขั้นตอนโดยละเอียดใน นําเข้าฐานข้อมูลด้วย SqlPackage เพื่อสร้างฐานข้อมูลใหม่ด้วยไฟล์ของคุณ.bacpac

ฐานข้อมูลที่สร้างขึ้นใหม่เป็นฐานข้อมูลอิสระจากฐานข้อมูลเดิม และสะท้อนถึงสถานะของข้อมูล ณ เวลาที่ดําเนินการส่งออก

ข้อควรพิจารณาเกี่ยวกับความล้มเหลว

ฐานข้อมูลที่สร้างขึ้นใหม่เป็นฐานข้อมูลอิสระ ข้อมูลที่เพิ่มลงในฐานข้อมูลที่สร้างขึ้นใหม่จะไม่แสดงในฐานข้อมูลเดิม ถ้าคุณวางแผนที่จะล้มเหลวไปยังฐานข้อมูลเดิมเมื่อรีเจี้ยนโฮมพร้อมใช้งาน คุณจะต้องพิจารณากระทบยอดข้อมูลจากฐานข้อมูลที่สร้างขึ้นใหม่ไปยังฐานข้อมูลต้นฉบับด้วยตนเอง

แพลตฟอร์ม

แพลตฟอร์มหมายถึงบริการและสถาปัตยกรรมที่ใช้ร่วมกันพื้นฐานที่ใช้กับปริมาณงานทั้งหมด ส่วนนี้จะแนะนําคุณเกี่ยวกับขั้นตอนการกู้คืนสําหรับประสบการณ์ที่ใช้ร่วมกัน ครอบคลุมไลบรารีตัวแปร

ไลบรารีตัวแปร

ไลบรารีตัวแปร Microsoft Fabric ช่วยให้นักพัฒนาสามารถปรับแต่งและแชร์การกําหนดค่ารายการภายในพื้นที่ทํางาน ซึ่งช่วยเพิ่มความคล่องตัวในการจัดการวงจรชีวิตเนื้อหา จากมุมมองการกู้คืนจากภัยพิบัติผู้ใช้ไลบรารีตัวแปรต้องป้องกันภัยพิบัติในระดับภูมิภาคในเชิงรุก ซึ่งสามารถทําได้ผ่านการผสานรวม Fabric Git ซึ่งทําให้มั่นใจได้ว่าหลังจากเกิดภัยพิบัติในระดับภูมิภาค ไลบรารีตัวแปรของผู้ใช้จะยังคงใช้งานได้ เมื่อต้องการกู้คืนไลบรารีตัวแปร เราขอแนะนําสิ่งต่อไปนี้:

• ใช้การรวม Fabric Git เพื่อซิงโครไนซ์ไลบรารีตัวแปรของคุณกับที่เก็บ ADO ของคุณ ในกรณีที่เกิดภัยพิบัติ คุณสามารถใช้ที่เก็บเพื่อสร้างไลบรารีตัวแปรใหม่ในพื้นที่ทํางานใหม่ที่คุณสร้างขึ้น ใช้ขั้นตอนต่อไปนี้:

  1. เชื่อมต่อพื้นที่ทํางานของคุณกับที่เก็บ Git ตามที่อธิบายไว้ที่นี่
  2. ตรวจสอบให้แน่ใจว่าได้ซิงค์ WS และที่เก็บกับ Commit และ Update
  3. การกู้คืน - ในกรณีที่เกิดภัยพิบัติ ให้ใช้ที่เก็บเพื่อสร้างไลบรารีตัวแปรใหม่ในพื้นที่ทํางานใหม่:

• ในพื้นที่ทํางานที่สร้างขึ้นใหม่ ให้เชื่อมต่อและซิงค์กับที่เก็บ Azure ADO ของคุณอีกครั้ง

• รายการ Fabric ทั้งหมดในที่เก็บนี้จะถูกดาวน์โหลดไปยังพื้นที่ทํางานใหม่ของคุณโดยอัตโนมัติ

• หลังจากซิงค์รายการของคุณจาก Git แล้ว ให้เปิดไลบรารีตัวแปรของคุณในพื้นที่ทํางานใหม่ และเลือก ชุดค่าที่ใช้งานอยู่ที่ต้องการด้วยตนเอง

คีย์ที่จัดการโดยลูกค้าสําหรับพื้นที่ทํางาน Fabric

คุณสามารถใช้คีย์ที่จัดการโดยลูกค้า (CMK) ที่จัดเก็บไว้ใน Azure Key Vault เพื่อเพิ่มชั้นการเข้ารหัสลับเพิ่มเติมที่ด้านบนของคีย์ที่จัดการโดย Microsoft สําหรับข้อมูลที่ไม่ได้ใช้งาน ในกรณีที่ Fabric ไม่สามารถเข้าถึงได้หรือไม่ใช้งานได้ในภูมิภาค ส่วนประกอบของมันจะเปลี่ยนเป็นอินสแตนซ์สํารอง ในระหว่างการเฟลโอเวอร์ คุณลักษณะ CMK รองรับการดําเนินการแบบอ่านอย่างเดียว ตราบใดที่บริการ Azure Key Vault ยังคงใช้งานได้ดีและสิทธิ์ในห้องนิรภัยยังคงเหมือนเดิม Fabric จะยังคงเชื่อมต่อกับคีย์ของคุณและอนุญาตให้คุณอ่านข้อมูลได้ตามปกติ ซึ่งหมายความว่าการดําเนินการต่อไปนี้ไม่ได้รับการสนับสนุนในระหว่างการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด: การเปิดใช้งานและปิดใช้งานการตั้งค่า CMK ของพื้นที่ทํางานและการอัปเดตคีย์

OneLake

ส่วนนี้จะแนะนําคุณตลอดขั้นตอนการกู้คืนสําหรับคุณลักษณะ OneLake สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการกู้คืนจากภัยพิบัติสําหรับข้อมูล OneLake โปรดดู การกู้คืนจากภัยพิบัติของ OneLake

นโยบายการจัดการวงจรชีวิต

ในกรณีที่ Fabric ไม่สามารถเข้าถึงได้หรือไม่ใช้งานได้ในภูมิภาค นโยบายวงจรการใช้งาน OneLake ของคุณยังคงสามารถอ่านและอัปเดตได้ในระหว่างการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด ข้อมูลใดๆ ที่ย้ายไปยังระดับ Cool หรือ Cold จะยังคงอยู่ในระดับนั้น คุณสามารถทําตามขั้นตอนเหล่านี้เพื่อนํานโยบายที่มีอยู่ไปใช้กับพื้นที่ทํางานการกู้คืนใหม่ของคุณ:

1. เรียกใช้นโยบายการส่งออกบนพื้นที่ทํางานเดิมของคุณและบันทึกนโยบายวงจรการใช้งานทั้งหมด
2. เรียกใช้นโยบายการนําเข้าในพื้นที่ทํางานที่กู้คืนของคุณ โดยมีนโยบายวงจรการใช้งานที่ส่งออกของคุณเป็นเนื้อหาคําขอ

กฎอินสแตนซ์ทรัพยากร

กฎอินสแตนซ์ทรัพยากรช่วยให้คุณควบคุมการเข้าถึงข้อมูลใน OneLake ได้อย่างปลอดภัยโดยใช้ข้อมูลประจําตัวทรัพยากร Azure ที่เชื่อถือได้ ในระหว่างการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาดระดับภูมิภาค ระบบจะยังคงบังคับใช้กฎที่มีอยู่สําหรับการเข้าถึงการอ่าน อย่างไรก็ตาม คุณไม่สามารถสร้าง อัปเดต หรือลบกฎอินสแตนซ์ทรัพยากรได้จนกว่าพื้นที่ทํางานจะกลับสู่สถานะที่สามารถเขียนได้

ข้อมูลที่เกี่ยวข้อง

• Microsoft Fabric คู่มือการกู้คืนจากภัยพิบัติ