อัปเกรด Postgres แบบไม่หยุดให้บริการ

 (knock.app)
2 คะแนน โดย GN⁺ 2023-12-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การเตรียมตัวสำหรับการอัปเกรด Postgres

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

เกี่ยวกับการมอนิเตอร์และเมตริก

  • การมอนิเตอร์ระบบ: ใช้เครื่องมือที่รัดกุมเพื่อมอนิเตอร์สุขภาพของฐานข้อมูลและระบบ
  • การติดตามเมตริกสำคัญ: มอนิเตอร์เมตริกหลัก เช่น transaction ID, การใช้ CPU, session ที่รออยู่, query latency, API response latency เป็นต้น

ตัวเลือกในการอัปเกรด Postgres

การอัปเกรดในระบบเดิม (ไม่เหมาะกับการอัปเกรดแบบ zero downtime)

  • ข้อจำกัดของการอัปเกรดในระบบเดิม: หากรันบน AWS RDS จำเป็นต้องรีบูตฐานข้อมูล และใช้เวลาตามปริมาณข้อมูล

การอัปเกรดแบบอิงการทำสำเนา

  • การเลือกอัปเกรดแบบอิงการทำสำเนา: ช่วยให้ทำขั้นตอน migration แบบค่อยเป็นค่อยไป ทดสอบฐานข้อมูลใหม่ด้วย workload และข้อมูลจริง และควบคุมการอัปเกรดได้มากขึ้น
  • การตั้งค่าฐานข้อมูลต้นทางและปลายทาง: ตั้งค่า replication slot และตั้งค่า wal_level เป็น logical

การเลือกวิธีทำสำเนาตาราง

การทำสำเนาตาราง "ขนาดเล็ก"

  • การทำสำเนาตารางขนาดเล็ก: สามารถทำสำเนาได้ด้วยการเพิ่มอย่างง่ายและรีเฟรช subscription

ตารางขนาดใหญ่ที่มีแต่การเพิ่มข้อมูล

  • การทำสำเนาตารางแบบ append-only: ตั้งค่าออปชัน copy_data เป็น false เพื่อทำสำเนาเฉพาะการเปลี่ยนแปลงในอนาคต แล้วค่อย backfill ข้อมูลเก่าจาก backup

ตารางขนาดใหญ่ที่มีการอัปเดตจำนวนมาก

  • การทำสำเนาตารางขนาดใหญ่ที่มีการอัปเดตมาก: ลดขนาดตาราง รัน VACUUM และพิจารณาแบ่งพาร์ทิชันตาราง

การตรวจสอบสถานะการทำสำเนาตาราง

  • การมอนิเตอร์สถานะการทำสำเนา: ตรวจสอบสถานะการทำสำเนาผ่านตารางระบบ pg_subscription_rel และแนะนำให้ทำสำเนาทีละหนึ่งตาราง

การหยุดการทำสำเนา

  • วิธีหยุดการทำสำเนา: หากจำเป็น สามารถหยุดการทำสำเนาตารางและย้อนกลับได้ด้วยการรีเฟรช subscription

ข้อควรระวังก่อนย้าย replication slot

  • ปัญหาในการย้าย replication slot: LSN ของ replication slot มีความเฉพาะกับฐานข้อมูลต้นทาง จึงไม่สามารถคัดลอกไปยังฐานข้อมูลใหม่ได้โดยตรง

การปิดงาน migration

  • การตรวจสอบความสอดคล้องของตาราง: ตรวจสอบว่าจำนวนแถวของตารางตรงกันระหว่างฐานข้อมูลทั้งสอง และหากจำเป็นให้ใช้การสุ่มตัวอย่างเพื่อตรวจสอบความตรงกันของข้อมูล

การเปลี่ยนแปลงในระดับแอปพลิเคชัน

  • การเปลี่ยนการเชื่อมต่อฐานข้อมูล: เปลี่ยนให้แอปพลิเคชันเชื่อมต่อกับฐานข้อมูลใหม่ และวางกลยุทธ์การสลับทราฟฟิก

หมายเหตุเพิ่มเติมเกี่ยวกับ sequence

  • การซิงก์ sequence: ค่า sequence จะไม่ถูกซิงก์ระหว่างกระบวนการทำสำเนา จึงต้องตั้งค่าด้วยตนเอง

เช็กลิสต์การตรวจสอบขั้นสุดท้าย

  • การตรวจสอบขั้นสุดท้าย: ตรวจสอบความสอดคล้องของตาราง, สถานะ subscription, ความตรงกันของ schema, ขนาดฐานข้อมูล, การเพิ่ม replica, การสร้างดัชนีใหม่, การทดสอบประสิทธิภาพ, การประเมินความเสี่ยง และการซ้อมในสภาพแวดล้อม staging

การสลับใช้งานครั้งสุดท้าย

  • การสลับใช้งานครั้งสุดท้าย: ทำการทำสำเนาตารางในช่วงเย็น ซ้อมหลายครั้งในสภาพแวดล้อม staging จากนั้นตรวจสอบรอบสุดท้ายและสลับ flag

ความเห็นของ GN⁺

  • ความสำคัญ: Knock ดำเนินกระบวนการซับซ้อนในการอัปเกรดจาก Postgres 11.9 ไปเป็น 15.3 แบบ zero downtime ได้สำเร็จ นี่เป็นหมุดหมายสำคัญด้านการบริหารฐานข้อมูลและความพร้อมใช้งานของบริการ
  • ความน่าสนใจ: แนวทางการอัปเกรดแบบอิงการทำสำเนาช่วยให้ผู้ดูแลฐานข้อมูลเปลี่ยนผ่านไปยังฐานข้อมูลใหม่ได้อย่างราบรื่น ซึ่งอาจดึงดูดความสนใจอย่างมากจากชุมชนเทคนิค
  • ความสนุก: กระบวนการอัปเกรดของ Knock แสดงให้เห็นถึงแนวปฏิบัติที่ดีในการเอาชนะความท้าทายทางเทคนิคที่ซับซ้อน ผ่านการจัดการความเสี่ยงและการแก้ปัญหาอย่างเป็นระบบ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-14
ความคิดเห็นจาก Hacker News

  • มีวิธีที่ดีกว่าการคัดลอกตารางขนาดใหญ่อยู่

    • สามารถสร้าง logical replica ได้ด้วยการสร้าง replication slot, เก็บ snapshot, กู้คืน snapshot ไปยังอินสแตนซ์ใหม่, ไล่ LSN และเริ่มการทำ replication
    • บทความของ Instacart อธิบายกระบวนการนี้ไว้
    • บทความอาจมีข้อผิดพลาดเล็กน้อย แต่เคยใช้วิธีนี้อัปเกรดอินสแตนซ์ขนาดระดับ TB ได้สำเร็จหลายครั้ง

  • แนวทางที่นำเสนอที่นี่น่าสนใจและมีเอกสารดี แต่ไม่เห็นด้วยกับประโยคที่ว่า "ลูกค้าสมัยใหม่คาดหวังความพร้อมใช้งาน 100%"

    • จากประสบการณ์ทั้งในฐานะลูกค้าและผู้ให้บริการ ความสอดคล้องของข้อมูลสำคัญกว่าความพร้อมใช้งานมาก
    • เมื่อผู้ให้บริการประกาศ downtime จะรู้สึกสบายใจเพราะมองว่าเป็นสัญญาณว่าพวกเขาจัดการข้อมูลอย่างรอบคอบ

  • ตอนนี้ AWS รองรับการทำ blue-green deployment แล้ว

  • ได้เขียนเครื่องมือที่ช่วยทำหลายปัญหาให้เป็นอัตโนมัติ

    • เครื่องมือนี้แชร์ไว้บน GitHub และสามารถขยายต่อได้ผ่าน feedback หรือไอเดียต่าง ๆ

  • กำลังย้ายระบบที่ hava.io จาก AWS RDS PostgreSQL 11.13 ไปเป็น 15.5

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

  • มีข้อสงสัยต่อคำกล่าวที่ว่า downtime ใด ๆ ก็ยอมรับไม่ได้สำหรับบริการของ Knock

    • ระบบที่ซับซ้อนย่อมเกิดอุบัติเหตุและ downtime ได้
    • downtime 15 นาทีที่ประกาศล่วงหน้าไม่ใช่ปัญหาสำหรับธุรกิจ SaaS ส่วนใหญ่
    • การนำเวลาเชิงวิศวกรรมไปลงทุนกับการพัฒนาผลิตภัณฑ์หรือเพิ่มความเร็วให้ทีมพัฒนาอาจสร้างความพึงพอใจแก่ผู้ใช้ได้มากกว่า
    • ในการย้ายฐานข้อมูล ปริมาณงานที่ต้องใช้ระหว่างการย้ายแบบ "downtime น้อย" กับแบบ "zero downtime" แตกต่างกันมาก

  • รู้สึกแปลกใจที่ไม่สามารถเริ่มต้น replication จาก backup ได้

    • ถ้าทำได้ก็น่าจะลดความยุ่งยากในการสตรีมเนื้อหา DB ที่มีอยู่และเสถียรไปยังเซิร์ฟเวอร์ใหม่
    • แม้จะเรียกว่า "zero downtime" แต่ในความเป็นจริงก็ยังมี downtime ไม่กี่วินาทีระหว่างสลับไปยังเซิร์ฟเวอร์ใหม่
    • ไม่มีรายละเอียดเกี่ยวกับวิธีรักษาความสอดคล้องของข้อมูล
    • ไม่มีการกล่าวถึงตัวเลือกสำหรับ rollback ทั้งที่เมื่อทำงานย้ายครั้งเดียวกับข้อมูลขนาดใหญ่ ควรมีแผนย้อนกลับไปขั้นก่อนหน้าเสมอ

  • ถามว่ามีใครสนใจเครื่องมือแบบ all-in-one ที่เพียงใส่ credentials ของฐานข้อมูลแล้วอัปเดต Postgres แบบ zero downtime ได้หรือไม่

  • ประเด็นเรื่องการใช้ sequence น่าสนใจ

    • โดยทั่วไปใช้ sequential UUID หรืออัลกอริทึม HiLo แทน sequence

  • พูดติดตลกว่า ปัญหาที่เกิดใน distributed system แก้ได้ด้วยการใส่ sleep(1000) อย่างเหมาะสม

    • Postgres เป็นระบบที่ไม่ค่อยคุ้นมือสำหรับ DBA แต่ก็ดีขึ้นกว่าเมื่อก่อนมากแล้ว