การปรับใช้เป็นศูนย์การหยุดทำงาน - Schema Db การนำส่ง

การใช้ Zero Downtime Deploymentประสบปัญหาเดียวกัน แต่ฉันต้องการคำแนะนำเกี่ยวกับกลยุทธ์ที่ฉันกำลังพิจารณา

บริบท

แอปพลิเคชันบนเว็บพร้อม Apache / PHP สำหรับการประมวลผลฝั่งเซิร์ฟเวอร์และฐานข้อมูล MySQL / ระบบไฟล์เพื่อการคงอยู่

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

มันเป็นความตั้งใจของฉันที่เราสามารถใช้การปรับปรุงกับแอปพลิเคชันโดยไม่ต้องหยุดทำงาน ฉันใช้ความเจ็บปวดอย่างมากเมื่อออกแบบโครงสร้างพื้นฐานเพื่อให้แน่ใจว่าฉันสามารถให้เวลาได้ 100% มันน่าผิดหวังอย่างยิ่งที่มีเวลาหยุดทำงาน 10-15 นาทีทุกครั้งที่มีการอัปเดต สิ่งนี้มีความสำคัญอย่างยิ่งเนื่องจากเราตั้งใจที่จะมีวงจรการเผยแพร่ที่รวดเร็วมาก (บางครั้งอาจถึงหนึ่งหรือมากกว่านั้นต่อวัน

โครงสร้างเครือข่าย

นี่เป็นบทสรุปของเครือข่าย:

                      Load Balancer
             |----------------------------|
              /       /         \       \  
             /       /           \       \ 
 | Web Server |  DB Server | Web Server |  DB Server |
 |-------------------------|-------------------------|
 |   Host-1   |   Host-2   |   Host-1   |   Host-2   |
 |-------------------------|-------------------------|
            Node A        \ /        Node B
              |            /            |
              |           / \           |
   |---------------------|   |---------------------|
           Switch 1                  Switch 2

   And onward to VRRP enabled routers and the internet

หมายเหตุ: เซิร์ฟเวอร์ฐานข้อมูลใช้การจำลองแบบต้นแบบหลัก

กลยุทธ์ที่แนะนำ

เพื่อให้บรรลุนี้ฉันกำลังคิดที่จะแบ่งสคริปต์การอัพเกรด DB schema ออกเป็นสองส่วน การอัพเกรดจะมีลักษณะเช่นนี้:

1. เว็บเซิร์ฟเวอร์บนโหนด A ถ่ายแบบออฟไลน์ ทราฟฟิกยังคงถูกประมวลผลโดยเว็บเซิร์ฟเวอร์บนโหนด B
2. การเปลี่ยนแปลง Schema ในช่วงเปลี่ยนผ่านจะใช้กับเซิร์ฟเวอร์ฐานข้อมูล
3. เว็บเซิร์ฟเวอร์มีการอัปเดตรหัสฐานแคชจะถูกล้างและการดำเนินการอัปเกรดอื่น ๆ
4. เว็บเซิร์ฟเวอร์ A ออนไลน์และเว็บเซิร์ฟเวอร์ B ถูกออฟไลน์
5. รหัสฐานเว็บ B ถูกอัพเดตแคชจะถูกล้างและการดำเนินการอัพเกรดอื่น ๆ จะถูกดำเนินการ
6. เว็บเซิร์ฟเวอร์ B ถูกนำมาออนไลน์
7. การเปลี่ยนแปลงแบบแผนสุดท้ายถูกนำไปใช้กับฐานข้อมูล

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

'Final Schema' จะลบความเข้ากันได้ย้อนหลังและเป็นระเบียบเรียบร้อย

คำถาม

ในระยะสั้นจะใช้งานได้หรือไม่

โดยเฉพาะอย่างยิ่ง:

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

2. มีวิธีที่ง่ายกว่านี้หรือไม่ที่ให้ความเสถียรในระดับนี้ในขณะที่ยังอนุญาตให้อัปเดตโดยไม่ต้องหยุดทำงาน นอกจากนี้ยังเป็นที่นิยมในการหลีกเลี่ยงกลยุทธ์สคีมา 'วิวัฒนาการ' เนื่องจากฉันไม่ต้องการล็อคเข้ากับสคีมาด้านหลัง

มันเสียงเหมือนสิ่งที่คุณกำลังมองหาจริงๆไม่ว่างสูงให้มากที่สุดเท่าที่คุณจะต้องพร้อมอย่างต่อเนื่อง

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

การผลิตหนึ่ง

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

การผลิตสอง

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

ฝ่ายผลิต

นี่เป็นอีกรายการหนึ่งที่ศูนย์ข้อมูลแยกต่างหากซึ่งตั้งอยู่ในภูมิภาคต่างๆของโลก สิ่งนี้ช่วยให้คุณล้มเหลวในกรณีที่เกิดเหตุการณ์ภัยพิบัติด้วยสวิตช์ DNS ที่ Load Balancer

ใช้ชีวิต

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

การโยกย้ายข้อมูล

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

ข้อสรุป

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

ข้อเสีย

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

กลยุทธ์ของคุณคือเสียง ฉันขอเสนอให้พิจารณาขยาย "Schema Transitional" เป็นชุด "ตารางธุรกรรม" ที่สมบูรณ์

ด้วยตารางธุรกรรม SELECTs (แบบสอบถาม) จะดำเนินการกับตารางปกติเพื่อให้มั่นใจว่าถูกต้อง แต่ฐานข้อมูล INSERTs, UPDATEs และ DELETE ทั้งหมดจะถูกเขียนลงในตารางธุรกรรมที่ผิดปกติเสมอ

จากนั้นกระบวนการที่เกิดขึ้นพร้อมกันก็จะนำการเปลี่ยนแปลงเหล่านั้นมาใช้ (อาจจะใช้กระบวนงานที่เก็บไว้) กับตารางปกติตามกฎทางธุรกิจและข้อกำหนดของสคีมาที่สร้างขึ้น

ส่วนใหญ่เวลานี้จะเป็นจริงทันที แต่การแยกการดำเนินการช่วยให้ระบบสามารถรองรับกิจกรรมที่มากเกินไปและความล่าช้าในการปรับปรุงสคีมา

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

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

แถวของตารางธุรกรรมอาจดูเหมือน ...

| ROWID | TRANSNR | DB | TABLE | SQL STATEMENT
    0        0       A    Name   INSERT INTO Name ...
    1        0       A    Addr   INSERT INTO Addr ...
    2        0       A    Phone  INSERT INTO Phone ...
    3        1       A    Stats   UPDATE Stats SET NrOfUsers=...

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

แนวคิดดังกล่าวเป็นไปตามหลักการเดียวกับการทำบัญชีสองครั้งและด้วยเหตุผลที่คล้ายกัน

ตารางธุรกรรมมีความคล้ายคลึงกับ "วารสาร" การทำบัญชี ตารางที่ได้รับการทำให้เป็นมาตรฐานอย่างสมบูรณ์นั้นคล้ายคลึงกับ "บัญชีแยกประเภท" การทำบัญชีโดยแต่ละตารางมีลักษณะคล้ายกับบัญชี "บัญชี"

ในการทำบัญชีแต่ละรายการจะได้รับสองรายการในสมุดรายวัน หนึ่งบัญชีสำหรับบัญชีแยกประเภท "เดบิต" และอีกบัญชีหนึ่งสำหรับบัญชี "เครดิต"

ใน RDBMS "เจอร์นัล" (ตารางธุรกรรม) ได้รับรายการสำหรับแต่ละตารางปกติที่จะถูกเปลี่ยนแปลงโดยธุรกรรมนั้น

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