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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เลคเฮ้าส์

เลคเฮ้าส์จากภูมิภาคเดิมยังคงไม่มีให้บริการสําหรับลูกค้า ในการกู้คืนเลคเฮ้าส์ ลูกค้าสามารถสร้างใหม่ในพื้นที่ทํางาน 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

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

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

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

โน้ตบุ๊ก

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

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

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

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

   

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

   

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

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

      

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

      

      

   3. หากสมุดบันทึกต้นฉบับมีบ้านพักทะเลสาบเริ่มต้น ให้ดู ส่วนบ้านทะเลสาบ เพื่อกู้คืนบ้านพักทะเลสาบ จากนั้นเชื่อมต่อบ้านพักทะเลสาบที่กู้คืนใหม่กับสมุดบันทึกที่กู้คืนใหม่

      

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

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

         1. บันทึกไฟล์หรือโฟลเดอร์ลงในดิสก์ท้องถิ่นหรือไปยังตําแหน่งอื่น

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

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

         

         

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

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

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

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

   

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

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

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

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

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

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

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

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

   

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

   

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

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

ฟังก์ชันข้อมูลผู้ใช้

หากต้องการกู้คืนฟังก์ชันข้อมูลผู้ใช้ของคุณในภูมิภาคที่สมบูรณ์ ให้ใช้วิธีใดวิธีหนึ่งต่อไปนี้

แนวทางที่ 1: ใช้การผสานรวมกับ Git (แนะนํา)

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

เตรียมพร้อมก่อนเกิดภัยพิบัติ

1. กําหนดค่าการผสานรวม Fabric Git สําหรับพื้นที่ทํางานที่โฮสต์ฟังก์ชันข้อมูลผู้ใช้
2. Connect the workspace to an Azure DevOps or GitHub repository.
3. บันทึกฟังก์ชันข้อมูลผู้ใช้ทั้งหมดลงในที่เก็บข้อมูลและซิงโครไนซ์การเปลี่ยนแปลงอย่างสม่ําเสมอ
4. เก็บการตั้งค่าเฉพาะสภาพแวดล้อมแยกกันในไลบรารีตัวแปรหากต้องการ

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

หลังจากภัยพิบัติระดับภูมิภาค:

1. สร้างขีดความสามารถ Fabric ใหม่ในภูมิภาคที่มีสุขภาพดี เช่น C2
2. สร้างพื้นที่ทํางานใหม่ เช่น W2 ในตําแหน่งใหม่
3. เชื่อมต่อพื้นที่ทํางานกับที่เก็บข้อมูล Azure DevOps หรือ GitHub เดียวกัน
4. โอเพ่น ซอร์สควบคุม และซิงโครไนซ์เนื้อหาในคลังข้อมูลไปยังพื้นที่ทํางาน
5. สร้างหรือกู้คืนทรัพยากร Fabric ที่ขึ้นต่อกันทั้งหมด เช่น บ้านพักริมทะเลสาบ ฐานข้อมูล SQL ใน Fabric คลังสินค้า และกิจกรรมทางธุรกิจ
6. ปรับใช้ฟังก์ชันข้อมูลผู้ใช้ใหม่
7. ตรวจสอบการทํางานของฟังก์ชันและการเชื่อมต่อระหว่างการพึ่งพา
8. อัปเดตแอปพลิเคชันปลายทาง ท่อข้อมูล หรืออุปกรณ์อื่น ๆ ที่รวมอยู่ในฟังก์ชันที่กู้คืนได้
9. การตรวจสอบความถูกต้องครบวงจรของทุกสถานการณ์ของคุณ

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

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

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

แนวทางที่ 2: การกู้คืนด้วยมือ

ถ้าการผสานรวม Git ยังไม่ได้ตั้งค่าก่อนเกิดภัยพิบัติ คุณสามารถสร้างฟังก์ชันข้อมูลผู้ใช้จากซอร์สโค้ดสํารองได้ด้วยตนเอง

เตรียมพร้อมก่อนเกิดภัยพิบัติ

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

• ส่งออกซอร์สโค้ดฟังก์ชันไปยังที่เก็บ GitHub
• บันทึกและรักษาข้อมูลการพึ่งพา
• การตั้งค่าสภาพแวดล้อมเอกสาร

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

หลังจากภัยพิบัติระดับภูมิภาค:

1. สร้างขีดความสามารถ Fabric ใหม่ในภูมิภาคที่มีสุขภาพดี เช่น C2
2. สร้างพื้นที่ทํางานใหม่ เช่น W2
3. กู้คืนทรัพยากรทั้งหมดที่ฟังก์ชันต้องการ รวมถึงบ้านพักริมทะเลสาบ ฐานข้อมูล SQL ใน Fabric คลังสินค้า บ้านจัดงาน และบริการภายนอก
4. สร้างโปรเจกต์ฟังก์ชันข้อมูลผู้ใช้ใหม่
5. นําเข้าหรือสร้างซอร์สโค้ดของฟังก์ชันใหม่
6. ปรับตั้งค่าการกําหนดค่าขณะรันไทม์ใหม่
7. ติดตั้งฟังก์ชันที่ขึ้นกับฟังก์ชันทั้งหมดใหม่
8. ปรับฟังก์ชันใหม่
9. กําหนดค่าการตรวจสอบสิทธิ์และการอนุญาตใหม่
10. สร้างผู้เผยแพร่หรือผู้บริโภคกิจกรรมธุรกิจขึ้นใหม่ หากมีการใช้งาน
11. การทดสอบตรวจสอบแบบครบวงจรสําหรับสถานการณ์และการผสานรวมของคุณ

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 เรียนรู้ 

แอป

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

วิธีการแบบแมนนวล

คุณสามารถกู้คืนแอป Fabric ด้วยตนเองหลังเกิดภัยพิบัติระดับภูมิภาคโดยใช้ซอร์สโค้ดของแอปพลิเคชันและ Rayfin CLI 

ข้อกําหนดเบื้องต้น 

ก่อนเกิดภัยพิบัติ:

• เก็บซอร์สโค้ดของ Fabric App ไว้ใน GitHub, Azure DevOps หรือที่เก็บซอร์สโค้ดอื่น ๆ 

• บันทึกกระบวนการฟื้นฟู  

ขั้นตอนการฟื้นฟู 

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

2. กู้คืนทรัพยากรที่ขึ้นกับก่อนนําแอปพลิเคชันไปปรับใช้ใหม่  

3. ดึงซอร์สโค้ดล่าสุดของ Fabric App จากคลังควบคุมซอร์สโค้ดหรือสํารองข้อมูลในเครื่อง 

4. จากไดเรกทอรีต้นทางของแอปพลิเคชัน ให้ปรับใช้ Fabric App เข้าสู่พื้นที่กู้คืนโดยใช้ Rayfin CLI รัน rayfin up --workspace <new workspace> 

5. กู้คืนรายการลูกของแอป (ฐานข้อมูล SQL ใน Fabric) โดยทําตามขั้นตอนการกู้คืนที่เกี่ยวข้อง  

6. ปรับตั้งค่าระดับรายการใหม่ รวมถึงบทบาทและการควบคุมการเข้าถึงตามความจําเป็น  

7. ตรวจสอบการทํางานของแอปพลิเคชันและตรวจสอบให้แน่ใจว่าผู้ใช้มีสิทธิ์ที่ถูกต้อง  

สำคัญ 

• รักษาซอร์สโค้ดของแอป Fabric ให้อยู่นอกโซน Fabric เพื่อเปิดใช้งานการกู้คืน  

• ข้อมูลแอปพลิเคชันในฐานข้อมูลจะไม่ถูกกู้คืนในกระบวนการปรับใช้ Fabric App และต้องกู้คืนแยกต่างหาก  คุณสามารถกู้คืนแอป Fabric ด้วยตนเองหลังเกิดภัยพิบัติระดับภูมิภาคโดยใช้ซอร์สโค้ดของแอปพลิเคชันและ Rayfin CLI 

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

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

โมเดลและการทดลอง ML

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

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

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

คลังข้อมูล

คู่มือนี้จะพาคุณผ่านขั้นตอนการกู้คืนสําหรับภาระงาน Fabric คลังข้อมูล ครอบคลุมสินค้าในคลังสินค้า

คลังสินค้า

คุณไม่สามารถเข้าถึงคลังสินค้าจากภูมิภาคเดิมได้ เมื่อต้องการกู้คืนคลังสินค้า ให้ใช้สองขั้นตอนต่อไปนี้

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

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

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

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

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

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

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

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

5. ขึ้นอยู่กับวิธีที่คุณปรับใช้คํานิยามตารางก่อนนําเข้าข้อมูล T-SQL ที่ใช้ในการนําเข้าอาจแตกต่างกัน ในการกู้คืนตารางโกดังจากบ้านริมทะเลสาบ คุณสามารถใช้INSERT INTOวิธีการ , SELECT INTO, หรือCREATE TABLE AS SELECT ในตัวอย่างต่อไปนี้ เราใช้ INSERT INTO. หากคุณใช้โค้ดต่อไปนี้ ให้แทนที่ตัวอย่างด้วยชื่อตารางและคอลัมน์จริง

   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 ของคุณ

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

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

คลังข้อมูล

ลูกค้าไม่สามารถเข้าถึงรายการ Data Factory จากภูมิภาคหลัก และการตั้งค่ารวมถึงการกําหนดค่าในท่อส่งหรือรายการ Dataflow Gen2 จะไม่ถูกจําลองไปยังภูมิภาครอง เพื่อกู้คืนรายการเหล่านี้หลังจากเกิดความล้มเหลวในระดับภูมิภาค คุณต้องสร้างรายการ Data Integration ของคุณใหม่ในพื้นที่ทํางานอื่นจากภูมิภาคอื่น ส่วนต่อไปนี้แสดงรายละเอียด

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

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

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

   

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

   

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

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

   

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

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

ฟีเจอร์ บันทึกเป็น สําหรับ Dataflows ไม่รองรับในกรณีกู้คืนจากภัยพิบัติ

Pipelines

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

งานคัดลอก

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

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

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

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

   

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

   

2. กู้คืน CopyJob จากรีโป Azure DevOps

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

      

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

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

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

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

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

ทําตามขั้นตอนเหล่านี้เพื่อบรรลุเป้าหมายนี้:

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

2. หลังจากนั้นคุณจะเห็นงาน Airflow ของคุณซิงค์กับ repo ADO ของคุณ

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

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

คู่มือนี้จะแนะนําคุณผ่านขั้นตอนการกู้คืนสําหรับประสบการณ์ Real-Time Intelligence ครอบคลุมฐานข้อมูล KQL, ชุดคําสั่ง และรายการ eventstream

Activator

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. สร้างสําเนาของแหล่งข้อมูลของคุณในภูมิภาคต่าง ๆ

2. สร้างรายการ eventstream ในภูมิภาคที่เกี่ยวข้อง

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

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

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

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

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

• Azure Events คือการสมัครใช้งานเหตุการณ์สําหรับกิจกรรมที่สร้างโดยบัญชี Azure Blob Storage ทรัพยากร Azure เหล่านี้มีอยู่โดยไม่ขึ้นกับความจุหรือภูมิภาคของ Fabric แม้ว่าทรัพยากร Azure Blob Storage เองอาจยังคงใช้งานได้ในช่วงที่เกิดการขัดข้องในภูมิภาค Fabric แต่การสมัครสมาชิกที่ตั้งค่าใน hub 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 เป็นทางเลือกขึ้นอยู่กับสถานการณ์ หากคุณสํารองสคีมาเหตุการณ์ของคุณด้วยการผสานรวม Git ให้กู้คืนก่อนโดยทําตาม ส่วน Event schema set จากนั้นชี้เหตุการณ์ทางธุรกิจไปยังชุดสคีมาที่กู้คืนแล้ว

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 hub โดยชี้ไปยังรายการ workspace, งาน หรือเส้นทาง OneLake ที่คุณกู้คืนในภูมิภาคกู้คืน โดยทําตามบทความ Explore Fabric events in Fabric Real-Time hub

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

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

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

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

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

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

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

แนะนํา: สํารองข้อมูลด้วยการผสานรวม Fabric Git

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

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

2. รักษา event schema ให้ถูก commit และซิงโครไนซ์อย่างสม่ําเสมอ โดยเฉพาะหลังจากเพิ่มประเภทเหตุการณ์หรือเผยแพร่เวอร์ชัน schema ใหม่

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

4. สร้างผู้เผยแพร่และผู้บริโภคที่ใช้ชุดสคีมาขึ้นใหม่ โดยทําตามคําแนะนําสําหรับประเภทรายการเหล่านั้น

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

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

ทางเลือก: สร้างใหม่ด้วยตนเอง

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

แผนที่

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

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

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

ภววิทยา

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

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

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

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

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

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

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

การกู้คืน SQL Fabric สําหรับการวางแผน

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

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

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

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

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

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

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

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

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

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

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

Databases

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

ฐานข้อมูล SQL

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

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

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

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

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

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

แพลตฟอร์ม

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

การตรวจสอบพื้นที่ทํางาน

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

การตรวจสอบข้อมูลจากพื้นที่ทํางานเดิม (C1. W1) จะไม่ถูกโอนย้ายไป เพราะการตรวจสอบสะท้อนกิจกรรมของพื้นที่ทํางานที่มันทํางานอยู่

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

ไลบรารีตัวแปร 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 ยังคงมีสุขภาพดีและสิทธิ์การเข้าถึง Vault ยังคงอยู่ Fabric จะเชื่อมต่อกับคีย์ของคุณและอนุญาตให้คุณอ่านข้อมูลได้ตามปกติ ซึ่งหมายความว่าการดําเนินการต่อไปนี้ไม่ได้รับการสนับสนุนในระหว่างการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาด: การเปิดใช้งานและปิดใช้งานการตั้งค่า CMK ของพื้นที่ทํางานและการอัปเดตคีย์

Fabric Migration Assistant สําหรับฐานข้อมูล SQL ใน Fabric

Fabric Migration Assistant สามารถย้ายฐานข้อมูล SQL Server ไปยังฐานข้อมูล SQL ใน Fabric ได้ในสามขั้นตอน: ตัวช่วยสร้างการย้ายสร้างฐานข้อมูลเป้าหมายและเริ่มการย้าย, ตัวตรวจสอบการย้ายข้อมูลติดตามความคืบหน้าในขณะที่สคีมาถูกปรับใช้จาก DACPAC, Migration Assistant ช่วยตรวจสอบและแก้ไขข้อผิดพลาดของสคริปต์, เตรียมฐานข้อมูล, คัดลอกข้อมูลด้วยงานคัดลอก และสรุปการคัดลอก

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

ความวุ่นวายในระดับภูมิภาคสามารถทําให้การย้ายถิ่นล้มเหลวได้สามวิธี:

• ฐานข้อมูลเป้าหมายยังไม่ได้ถูกสร้าง

  หาก Fabric ไม่สามารถสร้างฐานข้อมูลเป้าหมายได้ ตัวช่วยสร้างการย้ายข้อมูลจะแสดงข้อผิดพลาดและการย้ายข้อมูลจะไม่เริ่ม เลือก เริ่มการย้ายข้อมูล เพื่อลองใหม่ หรือลองใหม่ในภายหลัง

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

• การปรับใช้ล้มเหลว

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

  วิธีกู้คืน:

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

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

• ประวัติการย้ายข้อมูลไม่โหลด

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

OneLake

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

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

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

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

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

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

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

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