PostgreSQL Streaming Replication (WAL) คืออะไร และตั้งค่าอย่างไร

 (mindhub365.com)
4 คะแนน โดย GN⁺ 2024-10-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Streaming Replication ของ PostgreSQL เป็นวิธีที่มีประสิทธิภาพในการคงสำเนาแบบจำลองที่เกือบเรียลไทม์ของ DB หลักไว้บนเซิร์ฟเวอร์สแตนด์บายตั้งแต่หนึ่งเครื่องขึ้นไป
  • เซิร์ฟเวอร์หลักจะส่งเรกคอร์ด Write-Ahead Log (WAL) ไปยังเซิร์ฟเวอร์สแตนด์บายอย่างต่อเนื่องทันทีที่ถูกสร้างขึ้น เพื่อลดความหน่วงของกระบวนการจำลองให้เหลือน้อยที่สุด
  • ออกแบบมาเพื่อเพิ่มความพร้อมใช้งานสูงและการขยายระบบ โดยสามารถย้ายคำสั่งอ่านไปยังเซิร์ฟเวอร์สแตนด์บายเพื่อลดภาระของเซิร์ฟเวอร์หลักได้
  • รองรับทั้งโหมด synchronous และ asynchronous จึงปรับสมดุลระหว่างความสอดคล้องของข้อมูลกับประสิทธิภาพได้อย่างยืดหยุ่น
  • ครอบคลุมกระบวนการที่เซิร์ฟเวอร์สแตนด์บายเชื่อมต่อกับเซิร์ฟเวอร์หลักเพื่อร้องขอการสตรีม WAL และนำเรกคอร์ดที่ได้รับไปใช้กับสำเนา DB ของตนเอง
  • เมื่อเทียบกับการส่งล็อกแบบอิงไฟล์ จะให้การ failover ที่เร็วกว่าและลดความเสี่ยงของการสูญหายของข้อมูล จึงเหมาะกับสภาพแวดล้อมที่กระจายตัวทางภูมิศาสตร์

Streaming Replication ทำงานอย่างไร?

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

ไฟล์ตั้งค่า PostgreSQL และตำแหน่ง

  • ไฟล์คอนฟิกของ PostgreSQL มีบทบาทสำคัญในการจัดการการตั้งค่าและการทำงานของเซิร์ฟเวอร์ฐานข้อมูล
    • postgresql.conf: ไฟล์ตั้งค่าหลักที่รวมการตั้งค่าเซิร์ฟเวอร์ส่วนใหญ่ไว้ ตำแหน่งอาจแตกต่างกันตามระบบปฏิบัติการ เช่น /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) หรือ /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS)
    • pg_hba.conf: ควบคุมการยืนยันตัวตนของไคลเอนต์และกำหนดวิธีที่ไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์ โดยทั่วไปจะอยู่ในไดเรกทอรีเดียวกับ postgresql.conf
    • pg_ident.conf: ใช้สำหรับการแมปชื่อผู้ใช้ แต่ใช้งานไม่บ่อยนัก
    • recovery.conf: ใช้ตั้งค่าเซิร์ฟเวอร์สแตนด์บายใน PostgreSQL เวอร์ชันก่อน 12 แต่ในเวอร์ชันหลังจากนั้น เนื้อหาได้ย้ายไปอยู่ใน postgresql.conf และ postgresql.auto.conf
  • ตำแหน่งที่แน่นอนอาจแตกต่างกันตามระบบปฏิบัติการ วิธีติดตั้ง และเวอร์ชันของ PostgreSQL
    • สามารถใช้คำสั่ง SQL SHOW config_file; เพื่อค้นหาตำแหน่งของไฟล์เหล่านี้จากภายในอินสแตนซ์ PostgreSQL ได้

ตัวอย่างและโครงสร้างของ WAL (Write Ahead Logs)

  • สามารถดู WAL ได้ด้วยคำสั่ง pg_waldump
  • แต่ละบรรทัดแสดงเรกคอร์ด WAL ที่มีข้อมูลเกี่ยวกับการทำงานของ DB
  • องค์ประกอบของแต่ละเรกคอร์ด:
    • rmgr: ตัวจัดการทรัพยากร เช่น Heap, Btree, Transaction
    • len: ความยาวของเรกคอร์ด
    • tx: ID ของทรานแซกชัน
    • lsn: หมายเลขลำดับของล็อก
    • prev: LSN ก่อนหน้า
    • desc: คำอธิบายการทำงาน
  • ประเภทการทำงานที่มองเห็นได้:
    • การทำงานแบบ INSERT (Heap และ Btree)
    • การทำงานแบบ MULTI_INSERT (Heap2)
    • การ COMMIT ทรานแซกชัน
    • การทำงานกับไฟล์ (CREATE)
    • Full Page Writes (FPW)
  • เอาต์พุตของ WAL แสดงลำดับการไหลของทรานแซกชัน การแก้ไขข้อมูล และกิจกรรมของระบบอย่างละเอียด จึงมีประโยชน์ต่อการวิเคราะห์พฤติกรรมของ DB การแก้ปัญหา และการกู้คืนแบบ point-in-time

วิธีทำงานด้วย Docker

  • ค่าตั้งสำคัญที่เกี่ยวข้องกับ Streaming Replication ใน postgresql.conf:
    • wal_level, max_wal_senders, max_replication_slots, hot_standby เป็นต้น
  • สิ่งที่ต้องมีสำหรับตัวอย่าง Docker Compose:
    • init-master.sh: ตั้งค่า PostgreSQL master สำหรับการจำลอง สร้างผู้ใช้และสล็อตสำหรับ replication และอัปเดตค่าตั้งที่เกี่ยวข้องกับ WAL
    • init-replica.sh: เตรียม PostgreSQL replica ให้เชื่อมต่อกับ master และเริ่มการจำลอง รอจนกว่า master จะพร้อม จากนั้นทำ base backup และตั้งค่า replica
    • start-replica.sh: เริ่ม PostgreSQL replica ในคอนเทนเนอร์ Docker โดยรันสคริปต์ init-replica.sh ก่อนแล้วจึงเริ่ม PostgreSQL
    • docker-compose.yml: กำหนด service ของ master และ replica พร้อมตั้งค่า environment variables, volumes, commands ที่จำเป็น
  • หลังให้สิทธิ์รันกับสคริปต์แล้ว ให้รัน docker-compose up -d เพื่อเริ่ม master และ replica
  • สามารถเชื่อมต่อกับ master แล้วตรวจสอบสถานะการจำลองได้ด้วย pg_stat_replication
  • สามารถเชื่อมต่อกับ replica แล้วตรวจสอบว่าอยู่ในโหมดกู้คืนหรือไม่ด้วย pg_is_in_recovery()

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

  • Streaming Replication สามารถยกระดับทั้งประสิทธิภาพและความทนทานของโครงสร้างพื้นฐานฐานข้อมูลได้อย่างมาก ไม่ว่าจะเพื่อรองรับสถานการณ์ failover หรือกระจายภาระการอ่านไปยัง replica วิธีนี้ช่วยให้ DB ขยายขนาดได้และคงประสิทธิภาพที่เสถียร
  • การแสดงกระบวนการตั้งค่าทั้งหมดและเอาต์พุตที่เกิดขึ้นจริงเป็นสิ่งสำคัญ เพราะช่วยให้เห็นภาพรวมของส่วนประกอบที่เกี่ยวข้องจำนวนมาก และเข้าใจได้ดีขึ้นว่าเกิดอะไรขึ้น
  • การเข้าใจวิธีทำงานของ Streaming Replication และตั้งค่าให้ถูกต้องเป็นเรื่องสำคัญมาก หวังว่าบทความนี้จะช่วยทำให้กระบวนการชัดเจนขึ้นและให้มุมมองต่อการทำงานของ replication
  • ผลิตภัณฑ์หรือโครงการอื่นที่มีความสามารถคล้ายกัน ได้แก่ Replication ของ MySQL หรือ Data Guard ของ Oracle ซึ่งโซลูชันเหล่านี้ก็ทำงานโดยส่งการเปลี่ยนแปลงจาก master ไปยัง replica เช่นกัน แต่รายละเอียดการนำไปใช้อาจแตกต่างกัน
  • เมื่อต้องใช้ Streaming Replication ควรพิจารณาแบนด์วิดท์และ latency ของเครือข่ายด้วย การส่งข้อมูลระหว่าง master กับ replica อาจใช้ทรัพยากรเครือข่ายค่อนข้างมาก ความสามารถในการขยายจำนวน replica ก็เป็นอีกประเด็นสำคัญ
  • ควรประเมินข้อกำหนดด้านความสอดคล้องของข้อมูลด้วย การจำลองแบบ synchronous อาจกระทบประสิทธิภาพการเขียน แต่ให้ความสอดคล้องที่แข็งแกร่งกว่า ส่วน asynchronous ให้ประสิทธิภาพดีกว่า แต่มีโอกาสสูญหายของข้อมูลเล็กน้อย

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

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

 
GN⁺ 2024-10-14
ความคิดเห็นบน Hacker News

  • มีความเห็นว่าบทความนี้ยอดเยี่ยม แต่ในมุมมองของนักพัฒนาแบบฟูลสแตกที่ต้องการดูแลฐานข้อมูลเอง รู้สึกว่ายังขาดกรณีการใช้งานจริง

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

  • มีการอ้างว่าโซลูชันที่ง่ายที่สุดสำหรับการทำ replication ของ PostgreSQL คือ Kubernetes operator

    • ยก CloudnativePG เป็นตัวอย่าง
    • อธิบายว่าสิ่งที่ต้องมีไม่ใช่แค่ replication แต่รวมถึง failover, recovery, monitoring, self-healing และ backup ด้วย
    • มีคำถามว่ามีนอกเหนือจาก Kubernetes แล้วมี implementation ฟรี/โอเพนซอร์สอื่นหรือไม่

  • มองว่าหนึ่งในเหตุผลที่ใช้ Kubernetes และ Helm คือสามารถแก้ปัญหานี้ได้

    • อธิบายว่าสามารถตั้งค่าทุกอย่างได้ผ่านแพ็กเกจ Bitnami PostgreSQL โดยแทบไม่ต้องปรับแต่งเพิ่ม
    • อธิบายว่า Postgres-ha สร้างพร็อกซีขึ้นมาเพื่อจัดการความล้มเหลวอย่างเหมาะสม ทำให้ทำ failover แบบไร้การหยุดชะงักได้

  • แนะนำ StackGres สำหรับผู้ใช้ Kubernetes

  • สุดท้าย มีความเห็นเชิงสงสัยว่าบทความนี้ดูเหมือนถูกเขียนโดย AI