คุณจะอัปเดตสคีมาฐานข้อมูล / ฐานข้อมูลการผลิตของคุณโดยไม่ทำให้หยุดทำงานได้อย่างไร

เทคนิคใดบ้างสำหรับการอัพเดตสกีมาโค้ดฐาน / ฐานข้อมูลของเซิร์ฟเวอร์ที่ใช้งานจริงโดยไม่ทำให้เครื่องหยุดทำงาน

โดยทั่วไปเว็บไซต์ที่ฉันทำงานด้วยซึ่งมีความต้องการประเภทนี้ล้วน แต่อยู่เบื้องหลังโหลดบาลานซ์หรือมีสถานที่เกิดความล้มเหลวแยกต่างหาก ในตัวอย่างนี้ฉันจะสมมติว่าคุณมี load balancer เพียงตัวเดียวเว็บเซิร์ฟเวอร์ 2 ตัว (A & B) และเซิร์ฟเวอร์ฐานข้อมูล 2 ตัว (M & N - โดยปกติแล้วเซิร์ฟเวอร์ DB จะเชื่อมโยงผ่าน logshipping - อย่างน้อยในโลกเซิร์ฟเวอร์ SQL )

1. เว็บเซิร์ฟเวอร์ A ที่จะตัดการเชื่อมต่อจาก load balancer (ดังนั้นทราฟฟิกที่เข้ามาทั้งหมดจะไปที่ B)
2. การจัดส่งบันทึกถูกหยุดลง (DB Server M กำลังจะได้รับการอัปเดตก่อน)
3. อัปเดตเว็บเซิร์ฟเวอร์ A. กำหนดค่าไปที่ DB Server M
4. ทดสอบและตรวจสอบว่าการอัปเดตใช้งานได้หรือไม่ (โดยปกติแล้วคนจะกดที่อยู่ IP โดยตรง)
5. ตั้งค่าตัวโหลดบาลานซ์เพื่อให้เซสชันที่มีอยู่ยังคงไปที่ B. เซสชันใหม่ไปที่ A
6. รอให้เซสชันทั้งหมดบน B หมดอายุ (อาจใช้เวลาครึ่งชั่วโมงหรือมากกว่านั้นโดยปกติเราจะดูปริมาณการใช้งานและมีกำหนดพัก 1 ชั่วโมง)
7. อัปเดต B และ N
8. ทดสอบและตรวจสอบว่าการอัปเดตทำงานหรือไม่
9. ตั้งค่าการจัดส่งบันทึกอีกครั้งและทดสอบการทำงาน
10. ตั้งค่าตัวโหลดบาลานซ์ให้เป็นการทำงานปกติ

ในแอปพลิเคชันบนเว็บที่ซับซ้อนมากสิ่งที่อธิบายไว้ในขั้นตอนที่ 1-5 อาจใช้เวลาตลอดทั้งคืนและเป็นสเปรดชีต Excel ขนาด 50 หน้าพร้อมเวลาและหมายเลขติดต่อฉุกเฉิน ในสถานการณ์เช่นนี้การอัพเดตครึ่งหนึ่งของระบบจะถูกกำหนดเวลา 18.00 น. ถึง 6.00 น. ในขณะที่ปล่อยให้ระบบพร้อมใช้งานสำหรับผู้ใช้ การจัดการการอัปเดตสำหรับไซต์ DR มักจะกำหนดไว้ในคืนถัดไป - หวังว่าจะไม่มีวันหยุดพักในวันแรก

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

สำหรับฐานข้อมูลทั่วไป (ตัวอย่างเช่น Oracle) เป็นไปได้ที่จะแก้ไขสคีมาฐานข้อมูลในขณะที่ยังคงเรียกใช้คิวรีแบบขนาน มันต้องมีการวางแผนล่วงหน้า

มีข้อ จำกัด บางประการสำหรับการเปลี่ยนแปลงที่จะนำไปใช้:

• มันควรทำงานกับรหัสที่มีอยู่ซึ่งหมายความว่ารหัสควรจัดการกับทั้ง schema รุ่นเก่าและใหม่
• ไม่ควรมีภาระดังกล่าวในฐานข้อมูลที่ธุรกรรมจะร้องเสียงกรี๊ดเพื่อหยุดชะงัก (ฉันกำลังมองหาคุณCREATE INDEX)
• ไม่ควรเกิดการสูญเสียข้อมูล (คุณไม่สามารถวางและสร้างตารางใหม่ได้)

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

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

คำแนะนำง่ายๆในการวางแผนล่วงหน้า: ระบุชื่อคอลัมน์ในคำขอ DB ของคุณเสมอ (อย่าใช้SELECT * FROM) วิธีนี้คุณจะไม่มีคอลัมน์ใหม่ปรากฏขึ้นในคำขอเก่า

ระบบทั้งหมดไม่สามารถทำได้ต้องตั้งค่าในลักษณะที่รองรับ

ตัวอย่างเช่นหนึ่งในระบบหลักของเราที่ฉันช่วยอัปเกรดเมื่อไม่กี่ปีที่ผ่านมาควรมีให้ตลอด 24/7 ประกอบด้วยระดับหลายระดับรวมถึงระดับการสื่อสารที่บริสุทธิ์ระหว่างส่วนต่อประสานผู้ใช้นอกไซต์กับชั้นธุรกิจ เนื่องจากวิธีการเข้ารหัสเลเยอร์การสื่อสารการเปลี่ยนแปลงใด ๆ ในอนาคตกับเลเยอร์ธุรกิจหรือสคีมา DB สามารถดำเนินการได้โดยไม่เกิดการหยุดทำงานจริง ในสถานการณ์กรณีที่เลวร้ายที่สุดผู้ใช้จะพบกับการหยุดชั่วคราว 10-30 วินาทีเนื่องจากการเปลี่ยนแปลงมีผล

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

มันสามารถทำได้เพราะ:

• ชั้นการสื่อสารสามารถเก็บข้อความ สิ่งนี้ทำให้เรามีไฟดับจริง ๆ ในชั้นอื่น ๆ นอกเหนือจากเลเยอร์ UI โดยไม่จำเป็นต้องทำให้ UI ลง
• ชั้นธุรกิจจัดการโดย MVDB เรียกUniData นี้ถือรหัสทั้งหมดในหน่วยความจำ หลังจากรวบรวมรหัสแล้วคุณสามารถใช้คำสั่งเพื่อบังคับให้รหัสวัตถุใหม่เข้าสู่หน่วยความจำแทนรหัสเดิม

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

นี่คือมุมมองที่แตกต่างจากโลกของระบบฐานข้อมูลแบบฝังและระบบฝังตัว ระบบฝังตัวรวมถึงอุปกรณ์โครงสร้างพื้นฐานเครือข่าย / โทรคมนาคมที่หลากหลายและในอาณาจักรนี้พวกเขามักจะพูดคุยเกี่ยวกับเวลาการทำงาน 99.999% (ห้า 9 วินาที)

We (McObject) เป็นผู้จำหน่ายตระกูล eXtremeDB ของผลิตภัณฑ์ระบบฐานข้อมูลแบบฝังรวมถึง eXtremeDB High Availability

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

ด้วยความพร้อมใช้งานสูง eXtremeDB มีอินสแตนซ์ MASTER ของแอปพลิเคชันของคุณ (ซึ่งอาจเป็นกระบวนการหนึ่งหรือหลายกระบวนการ) และอินสแตนซ์ REPLICA ของแอปพลิเคชันของคุณอย่างน้อยหนึ่งรายการ เมื่อแบบจำลองสร้างการเชื่อมต่อกับต้นแบบมันจะได้รับสำเนาของฐานข้อมูลหลักผ่านกระบวนการที่เรียกว่า "การซิงโครไนซ์เริ่มต้น" สิ่งนี้สามารถทำได้ในขณะที่แอ็พพลิเคชันหลักยังคงทำงานต่อไป เมื่อ syncrhonized มันจะได้รับการทำธุรกรรมของเจ้านายผ่านการจำลองแบบ ดังนั้นเรพลิคาจะมีข้อมูลปัจจุบันอยู่เสมอและสามารถเข้าครอบครอง (ผ่านกระบวนการที่เรียกว่า failover) ในกรณีที่มาสเตอร์ล้มเหลว

คุณลักษณะหนึ่งของการซิงโครไนซ์เริ่มต้นเรียกว่า "วิวัฒนาการของไบนารีสคีมา" ในภาษาอังกฤษแบบธรรมดาหมายความว่ากระบวนการเติมฐานข้อมูลของแบบจำลองจะรองรับความแตกต่างระหว่างสคีมาฐานข้อมูลของแบบจำลองและสคีมาฐานข้อมูลของต้นแบบ

ในทางปฏิบัติซึ่งหมายความว่าคุณสามารถสร้างแอปพลิเคชันรุ่นใหม่กว่าของคุณ (ด้วยตารางใหม่ / ที่ถูกทิ้ง, เขตข้อมูลใหม่ / ที่ลดลง / ที่เปลี่ยนแปลง, ดัชนีใหม่ / ที่ลดลง), แนบแอปพลิเคชันรุ่นใหม่ของคุณ แบบจำลองที่ใหม่กว่าจะกลายเป็นต้นแบบใหม่ (เช่นบังคับให้ failover ไปยังแบบจำลองใหม่ดังนั้นจึงกลายเป็นต้นแบบและต้นแบบเก่าปิดตัวเองลง) ใน Voila คุณได้ย้ายแอปพลิเคชันของคุณจากเวอร์ชัน N ไปยัง N + 1 โดยไม่รบกวนความพร้อมของระบบของคุณ ตอนนี้คุณสามารถไปอัปเกรดต้นแบบเก่าและแบบจำลองอื่น ๆ เป็นรุ่น N + 1