การโคลนฐานข้อมูลแบบเกือบทันทีใน PostgreSQL 18

 (boringsql.com)
1 คะแนน โดย GN⁺ 2025-12-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • PostgreSQL 18 สามารถโคลนฐานข้อมูลได้แทบจะทันที โดยผสาน กลยุทธ์การคัดลอกไฟล์ (FILE_COPY) กับ ความสามารถในการโคลนของระบบไฟล์
  • เมื่อใช้ค่าตั้งใหม่ file_copy_method = clone จะสามารถใช้ ความสามารถโคลนของระบบไฟล์สมัยใหม่ (FICLONE) เช่น XFS, ZFS, APFS ได้
  • จากผลเบนช์มาร์ก การโคลนฐานข้อมูลขนาด 6GB วิธีเดิมแบบ WAL_LOG ใช้เวลาราว 67 วินาที ขณะที่แบบโคลนลดเหลือเพียง ประมาณ 0.2 วินาที
  • ฐานข้อมูลที่ถูกโคลนจะ ใช้บล็อกกายภาพเดียวกันร่วมกันในช่วงแรก แต่เมื่อมีการเขียนข้อมูลจะถูกแยกออกด้วย copy-on-write
  • อย่างไรก็ตาม จะโคลนได้เฉพาะตอนที่ไม่มีการเชื่อมต่อใช้งานอยู่ และมีข้อจำกัดว่า ทำงานได้ภายในระบบไฟล์เดียวกันเท่านั้น

โครงสร้างการโคลนแบบอิงเทมเพลตของ PostgreSQL

  • ใน PostgreSQL เมื่อรันคำสั่ง CREATE DATABASE dbname ภายในระบบจะ โคลนฐานข้อมูล template1 เพื่อสร้างฐานข้อมูลใหม่
    • พฤติกรรมนี้เหมือนกับ CREATE DATABASE dbname TEMPLATE template1
  • สามารถระบุฐานข้อมูลอื่นแทน template1 ได้ จึงรองรับการโคลนโดยใช้ เทมเพลตที่ผู้ใช้กำหนดเอง
  • ใน PostgreSQL 18 ระบบเทมเพลตนี้ถูกขยายให้เป็น โครงสร้างที่รองรับการโคลนแบบเกือบทันที

CREATE DATABASE ... STRATEGY

  • ตั้งแต่ PostgreSQL 15 มีการเพิ่มพารามิเตอร์ CREATE DATABASE ... STRATEGY เพื่อให้ เลือกวิธีการโคลน ได้
    • ค่าเริ่มต้นคือ WAL_LOG ซึ่งทำ การโคลนระดับบล็อกผ่าน Write-Ahead Log
    • วิธีนี้ช่วย ลดภาระ I/O และปรับปรุงการรองรับการทำงานพร้อมกัน แต่จะช้าเมื่อโคลนข้อมูลขนาดใหญ่
  • หากระบุ STRATEGY=FILE_COPY จะย้อนกลับไปใช้ วิธีคัดลอกไฟล์แบบเดิม และใน PostgreSQL 18 ก็ได้เพิ่ม ตัวเลือกการโคลนใหม่ บนพื้นฐานนี้

FILE_COPY และ file_copy_method

  • การตั้งค่า file_copy_method ใน PostgreSQL 18 ใช้ควบคุม วิธีโคลนไฟล์ในระดับระบบปฏิบัติการ
    • ค่าเริ่มต้นคือ copy ซึ่งจะอ่านทุกไบต์แล้วเขียนไปยังตำแหน่งใหม่
    • หากเปลี่ยนเป็น clone จะใช้ ความสามารถโคลนของระบบไฟล์ (FICLONE) ทำให้ โคลนได้แทบจะทันทีและไม่ใช้พื้นที่เพิ่ม
  • ระบบไฟล์ที่รองรับ: XFS, ZFS, APFS, FreeBSD ZFS
  • ขั้นตอนการตั้งค่า
    • ติดตั้ง PostgreSQL cluster บนระบบไฟล์ที่รองรับ
    • ตั้งค่า file_copy_method = clone แล้ว reload

ผลเบนช์มาร์ก

  • หลังสร้างฐานข้อมูลทดสอบขนาดประมาณ 6GB (source_db) ได้มีการเปรียบเทียบสองวิธี
    • วิธี WAL_LOG: 67,000ms (ประมาณ 67 วินาที)
    • วิธี FILE_COPY + clone: 212ms
  • ยืนยันได้ว่าที่ขนาดข้อมูลเท่ากัน ความเร็วเพิ่มขึ้นมากกว่า 300 เท่า
  • ฐานข้อมูลที่ถูกโคลน (fast_clone) แทบไม่ใช้พื้นที่ดิสก์เพิ่ม

หลักการทำงานของข้อมูลที่ถูกโคลน

  • เมื่อใช้ file_copy_method = clone จะมีการโคลนเฉพาะ metadata ของระบบไฟล์ ทำให้ทั้งสองฐานข้อมูล ใช้บล็อกกายภาพเดียวกันร่วมกัน
  • ขนาดฐานข้อมูลที่ PostgreSQL รายงานยังคงเป็นขนาดเชิงตรรกะเท่าเดิม (ประมาณ 6GB)
  • เมื่อมีการเขียนข้อมูล copy-on-write (COW) จะทำงานและแยกเพจนั้นออก
    • เพจที่มีแถวข้อมูลที่ถูกแก้ไข
    • เพจที่มีการเขียนทูเพิลใหม่
    • เพจดัชนี รวมถึง FSM และ visibility map เป็นต้น
  • แม้แต่การรัน VACUUM ก็ทำให้เกิดการแยกเพจเพิ่มเติมได้

การตรวจสอบบล็อกร่วมกันบน XFS

  • สามารถใช้คำสั่ง filefrag -v เพื่อตรวจสอบว่า สองฐานข้อมูลใช้บล็อกกายภาพร่วมกันหรือไม่
    • ในสถานะเริ่มต้น extents ทั้งหมดจะแสดงเป็น shared
    • เมื่ออัปเดตบางแถว บล็อก 40 แรก (ประมาณ 160KB) จะถูกแยกออกและ เปลี่ยนเป็นที่อยู่กายภาพคนละตำแหน่ง
    • extents ที่เหลือยังคงอยู่ในสถานะแชร์ร่วมกัน

ข้อควรระวังและข้อจำกัด

  • ขณะโคลน ฐานข้อมูลต้นทางต้องไม่มีการเชื่อมต่อใช้งานอยู่
    • นี่เป็นข้อจำกัดของ PostgreSQL ไม่ใช่ปัญหาของระบบไฟล์
    • ในสภาพแวดล้อมโปรดักชัน มักนิยมใช้ ฐานข้อมูลเทมเพลตแยกต่างหาก
  • โคลนได้ภายในระบบไฟล์เดียวกันเท่านั้น
    • หากมีหลาย tablespace อยู่บน mount point คนละแห่ง ระบบจะกลับไปใช้การคัดลอกแบบปกติ
  • ใน บริการคลาวด์แบบ managed (AWS RDS, Google Cloud SQL เป็นต้น) ไม่สามารถใช้ฟีเจอร์นี้ได้ เพราะเข้าถึงระบบไฟล์ไม่ได้
    • แต่บน VM หรือ bare metal ที่ดูแลเองจะควบคุมได้เต็มรูปแบบ

สรุป

  • ฟีเจอร์ file_copy_method = clone ใน PostgreSQL 18 ใช้ ความสามารถโคลนระดับระบบปฏิบัติการโดยตรง เพื่อ
    ลดเวลาในการโคลนฐานข้อมูลขนาดใหญ่ได้อย่างมาก
  • ช่วยให้สร้างเวิร์กโฟลว์ฐานข้อมูลที่ โคลนได้ทันทีและรีเซ็ตได้ง่าย สำหรับงานทดสอบ พัฒนา และการเรียนรู้
  • แต่ก็ต้องออกแบบการใช้งานโดยคำนึงถึง ข้อจำกัดเรื่องการเชื่อมต่อที่ยังใช้งานอยู่และการต้องอยู่ในระบบไฟล์เดียวกัน

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

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

 
GN⁺ 2025-12-24
ความเห็นจาก Hacker News

  • สำหรับคนที่รอไม่ไหวหรือต้องการการแยกอินสแตนซ์แบบสมบูรณ์ของ PG18 ฉันได้สร้างเครื่องมือสำหรับแตกกิ่งได้ทันทีด้วย ZFS snapshot ชื่อ Velo
    มันทำงานได้กับ PostgreSQL ทุกเวอร์ชัน และแต่ละกิ่งจะมีคอนเทนเนอร์กับพอร์ตที่แยกอิสระ
    สำหรับฐานข้อมูลขนาด 100GB ใช้เวลาสร้างราว 2~5 วินาที
    ความต่างจากแนวทางของ PG18 คือมันไม่ได้แชร์อินสแตนซ์เดียวกัน แต่ให้การแยกระดับเซิร์ฟเวอร์อย่างสมบูรณ์
    ลิงก์ GitHub

    • มีคนบ่นเรื่องการใช้ Claude Code ในคอมเมนต์อื่น แต่พอเห็นวิดีโอเดโมบนหน้า GitHub แล้วฉันรู้สึกว่าน่าสนใจ
    • ทุกวันนี้ซอฟต์แวร์ส่วนใหญ่ก็เขียนด้วยความช่วยเหลือของ AI agent กันอยู่แล้ว เลยไม่ค่อยเข้าใจว่าทำไมถึงมีคนบ่น วิธีการนี้ก็น่าสนใจดี
    • ฉันเองก็กำลังจะลองทำต้นแบบอะไรคล้าย ๆ กันด้วย btrfs
    • ฉันคิดว่าการใช้คำว่า “คุณ” น่าสนใจดี แต่พอมีคนบอกว่าลอกมาก็แอบตกใจนิดหน่อย

  • ตอนบริษัทเก่ากำลังย้ายไป RDS ฉันเคยสร้างระบบคล้าย ๆ กันขึ้นมาเอง
    ระหว่างการย้ายโปรดักชันมักมีปัญหาเกิดขึ้นบ่อย เลยทำขั้นตอนต่อไปนี้ให้เป็นอัตโนมัติเพื่อป้องกัน

    1. ทำสำเนา RDS DB หรือสร้างอินสแตนซ์ใหม่จากแบ็กอัป
    2. ดึง CNAME หรือ public IP จาก ARN
    3. นำไปใส่ในค่าการเชื่อมต่อ DB ของแอป
    4. รัน migration ในสภาพแวดล้อมโปรดักชันจำลอง
      ด้วยกระบวนการนี้ เราจับ บั๊กเฉพาะโปรดักชัน ได้จำนวนมากที่ไม่เคยเจอในเครื่อง local หรือ CI
      หลังจากนั้นก็ทำให้เป็นอัตโนมัติด้วย Ruby script ง่าย ๆ และได้ยินมาว่ายังใช้งานสคริปต์นั้นอยู่จนถึงตอนนี้
    • ฉันก็เกลียดบั๊กประเภท “migration พังเฉพาะบนโปรดักชันเพราะข้อมูลมีลักษณะเฉพาะ” เหมือนกัน บางครั้งถึงขั้นต้องยกเลิกการปล่อยเวอร์ชันเลย

  • นี่เป็นครั้งแรกที่ฉันรู้ว่าสามารถตั้งค่ากลยุทธ์ template cloning ได้
    ฉันใช้ Neon เพื่อสร้างสภาพแวดล้อม integration แบบเรียลไทม์ และใน โปรเจกต์ Golang pgtestdb ของฉัน จะสร้าง Postgres DB ที่ผ่าน schema migration ครบถ้วนสำหรับแต่ละเทสต์
    ฉันเคยเห็นสตาร์ตอัปแห่งหนึ่งใช้ btrfs เพื่อสร้าง staging DB ได้ทันทีมาก่อน เลยรู้สึกน่าสนใจที่ไอเดียแบบนี้วนกลับมาเรื่อย ๆ
    การโคลนและทดสอบอย่างรวดเร็ว แบบนี้เป็นจุดแข็งสำคัญของ Postgres และ Sqlite และก็ดีถ้า Clickhouse หรือ MySQL ทำได้แบบเดียวกัน

  • ช่วงนี้ PostgreSQL ดูเหมือนจะกลายเป็น DB สารพัดประโยชน์ที่ครอบคลุมงาน SQL แทบทุกแบบ
    แถมยัง ฟรี อีกด้วย
    เลยสงสัยว่าตอนนี้ยังมีเหตุผลอะไรให้ต้องใช้ SQL DB ตัวอื่นอยู่อีกไหม

    • Postgres ยอดเยี่ยมก็จริง แต่ MySQL ทำ master-master replication ได้ง่ายกว่า และ MongoDB ก็จัดการการกระจายข้ามภูมิภาคกับ sharding ได้ง่าย
      Clickhouse เร็วกว่ามากสำหรับงานวิเคราะห์ และ DB อย่าง Cassandra ก็เหมาะกับ workload ที่เน้นการเขียน
      พูดอีกอย่างคือ แต่ละ DB ก็ยังมีจุดแข็งของตัวเอง
    • การบอกว่า “ทำได้ดีทุกอย่าง” ถือว่าเกินจริง
      พอข้อมูลเยอะขึ้นก็จะมีปัญหาอย่าง ประสิทธิภาพตก หรือ ปัญหา migration
      ในกรณีของฉัน ประสิทธิภาพของการแบ่งพาร์ทิชันแบบพื้นฐานไม่ดีพอ จนต้องทำ custom partition เอง
    • Postgres ยังไม่มีประสิทธิภาพนักในเรื่อง รูปแบบการทำ MVCC (copy-on-write)
      การเลือกแบบนี้ส่งผลลบหลายอย่างเมื่อโหลดสูงขึ้น
    • เมื่อก่อน MySQL/InnoDB ดีกว่าสำหรับ workload ที่เน้นการอัปเดต
      เป็นประเด็นที่พูดถึงใน บทความบล็อกของ Uber เช่นกัน
      ถึงอย่างนั้นในสภาพแวดล้อมคลาวด์ ฉันก็ยังเชื่อถือ Postgres มากที่สุด
    • Postgres ยังไม่มีตัวเลือกทดแทนที่สุกงอมระดับ Vitess
      เพราะงั้นใน การติดตั้ง OLTP ขนาดใหญ่ MySQL ก็ยังถูกใช้เป็นหลักอยู่ดี (เช่น YouTube, Uber)

  • ถ้าใช้ โครงสร้างข้อมูลแบบ immutable (HAMT) ก็สามารถสร้าง DB ที่โคลนได้ทันทีโดยไม่ขึ้นกับชนิดของไฟล์ซิสเต็ม
    แม้จะบอกว่าเป็นแค่ทฤษฎี แต่ฉันได้ลองทำจริงมาแล้ว
    เลยไม่เข้าใจว่าทำไมถึงไม่มี HAMT-based DB แบบนี้มากกว่านี้

    • ฉันเป็นผู้สร้าง ClickHouse และ ClickHouse ก็รองรับการโคลนตารางโดยใช้ data part แบบ immutable เช่นกัน
      ลิงก์เอกสารที่เกี่ยวข้อง
    • สงสัยว่า Datomic มีฟีเจอร์โคลนแบบนี้ในตัวด้วยไหม ฉันอยากลองใช้มานานแล้ว แต่ยังไม่พร้อมจะสร้างแอปจริงด้วยมัน

  • ฉันไม่เคยรู้มาก่อนว่าใน Postgres v15 ค่าเริ่มต้นเปลี่ยนเป็น WAL_LOG แล้ว
    สำหรับสภาพแวดล้อม CI test แบบขนาน การย้อนกลับไปใช้กลยุทธ์ FILE_COPY ดูสมเหตุสมผลกว่า
    ฉันเคยเปิด issue ที่เกี่ยวข้องไว้ในโปรเจกต์เก่า integresql

  • ฉันเคยสร้าง เครื่องมือ GUI ง่าย ๆ pgtt สำหรับทดสอบแอปที่ใช้ Postgres บนเครื่อง local
    มันช่วยให้การตั้งค่าสภาพแวดล้อมพัฒนาง่ายขึ้นมาก

    • อ่านจาก README อย่างเดียวแล้วยังไม่ค่อยเข้าใจ เลยสงสัยว่าโครงสร้างนี้จัดการ template แบบ snapshot หรือเปล่า
      น่าจะช่วยงานที่ต้องรัน SQL migration ซ้ำ ๆ ได้
    • ถ้ามี ภาพหน้าจอ GUI ใน README น่าจะดี และ ลิงก์ Docker ก็เสียอยู่

  • ฉันลองอ่านโพสต์อื่น ๆ ในบล็อกนี้ด้วย และโดยรวมยอดเยี่ยมมาก
    โดยเฉพาะอย่างยิ่ง ฉันเพิ่งรู้จัก range type ของ Postgres เป็นครั้งแรก

    • range type มีประโยชน์มากกับงานอย่าง การคำนวณช่วงเวลาหรือวันที่ที่ทับซ้อนกัน

  • สงสัยว่า MariaDB มีฟีเจอร์แบบนี้ไหม
    ตอนนี้ฉันกังวลเพราะการรีเซ็ต DB กลับสู่สถานะเริ่มต้นในแต่ละเทสต์ทำได้ช้า
    โปรดักชันใช้ MariaDB อยู่แล้ว เลยเปลี่ยน DB ได้ยาก
    ถึงอย่างนั้นฝั่ง Postgres ก็ดูดีกว่า

    • ถ้ารันแต่ละเทสต์ภายใน transaction session แล้ว rollback ตอนจบ ก็สามารถคืนกลับสู่สถานะเริ่มต้นได้อย่างรวดเร็ว
      วิธีนี้ค่อนข้างมีประสิทธิภาพ
    • ถ้าโอเคกับการรีสตาร์ต DB การใช้ LVM หรือ btrfs snapshot ที่ระดับไฟล์ซิสเต็มก็เป็นอีกทางเลือกหนึ่ง

  • AWS ก็รองรับฟีเจอร์คล้ายกัน
    เอกสาร Aurora clone

    • Aurora clone ทำงานแบบ copy-on-write ที่ระดับสตอเรจ แต่ก็ยังต้อง provision คลัสเตอร์ใหม่อยู่ดี เลยใช้เวลาประมาณ 10 นาที
      สำหรับ integration test ถือว่าไม่สมจริงนัก
    • Aurora เป็นการโคลนระดับ cluster ขณะที่สิ่งที่กำลังคุยกันที่นี่คือการโคลนระดับ database