Implementasi Kloning Database Instan di PostgreSQL 18

 (boringsql.com)
1 poin oleh GN⁺ 2025-12-24 | 1 komentar | Bagikan ke WhatsApp
  • PostgreSQL 18 dapat mengkloning database hampir seketika dengan menggabungkan strategi penyalinan file (FILE_COPY) dan fitur klon sistem file
  • Dengan menggunakan nilai konfigurasi baru file_copy_method = clone, PostgreSQL dapat memanfaatkan fitur kloning (FICLONE) pada sistem file modern seperti XFS, ZFS, dan APFS
  • Hasil benchmark menunjukkan, saat mengkloning database 6GB, metode WAL_LOG memerlukan sekitar 67 detik, sedangkan metode klon hanya sekitar 0,2 detik
  • Database hasil kloning awalnya berbagi blok fisik yang sama, tetapi akan terpisah melalui copy-on-write saat ada operasi tulis
  • Namun, kloning hanya dapat dilakukan saat tidak ada koneksi aktif dan hanya bekerja di dalam satu sistem file yang sama

Struktur Kloning Berbasis Template di PostgreSQL

  • Saat menjalankan perintah CREATE DATABASE dbname, PostgreSQL secara internal mengkloning database template1 untuk membuat database baru
    • Perilaku ini sama dengan CREATE DATABASE dbname TEMPLATE template1
  • Selain template1, database lain juga bisa ditentukan, sehingga template buatan pengguna dapat digunakan untuk kloning
  • Di PostgreSQL 18, sistem template ini diperluas menjadi struktur yang mendukung kloning instan

CREATE DATABASE ... STRATEGY

  • Sejak PostgreSQL 15, parameter CREATE DATABASE ... STRATEGY diperkenalkan untuk memungkinkan pemilihan metode kloning
    • Nilai default adalah WAL_LOG, yang melakukan kloning per blok melalui Write-Ahead Log
    • Metode ini mengurangi beban I/O dan meningkatkan dukungan konkurensi, tetapi lambat untuk kloning berukuran besar
  • Dengan menetapkan STRATEGY=FILE_COPY, PostgreSQL dapat kembali ke metode penyalinan file lama, dan di PostgreSQL 18 opsi kloning baru ditambahkan di atas mekanisme ini
Iklan

FILE_COPY dan file_copy_method

  • Pengaturan file_copy_method di PostgreSQL 18 mengontrol metode kloning file di tingkat sistem operasi
    • Nilai default adalah copy, yang membaca semua byte lalu menuliskannya ke lokasi baru
    • Jika diubah ke clone, PostgreSQL menggunakan fitur klon sistem file (FICLONE) untuk kloning instan tanpa konsumsi ruang tambahan
  • Sistem file yang didukung: XFS, ZFS, APFS, FreeBSD ZFS
  • Prosedur pengaturan
    • Bangun cluster PostgreSQL di atas sistem file yang mendukung
    • Atur file_copy_method = clone lalu lakukan reload

Hasil Benchmark

  • Setelah membuat database uji (source_db) berukuran sekitar 6GB, dua metode dibandingkan
    • Metode WAL_LOG: 67.000ms (sekitar 67 detik)
    • Metode FILE_COPY + clone: 212ms
  • Pada ukuran data yang sama, terkonfirmasi peningkatan kecepatan lebih dari 300x
  • Database hasil kloning (fast_clone) hampir tidak menggunakan ruang disk tambahan
Iklan

Cara Kerja Data Hasil Kloning

  • Saat menggunakan file_copy_method = clone, hanya metadata sistem file yang dikloning, sehingga kedua database berbagi blok fisik yang sama
  • Ukuran database yang dilaporkan PostgreSQL tetap merupakan ukuran logis yang sama (sekitar 6GB)
  • Saat terjadi operasi tulis, copy-on-write (COW) akan aktif dan halaman terkait dipisahkan
    • Halaman yang berisi baris yang dimodifikasi
    • Halaman tempat tuple baru ditulis
    • Halaman indeks serta halaman FSM dan visibility map
  • Menjalankan VACUUM juga dapat memicu pemisahan halaman tambahan

Verifikasi Blok Bersama di XFS

  • Dengan perintah filefrag -v, dapat diverifikasi apakah dua database berbagi blok fisik yang sama
    • Pada kondisi awal, semua extent ditandai sebagai shared
    • Setelah beberapa baris di-update, 40 blok pertama (sekitar 160KB) dipisahkan dan berubah ke alamat fisik yang berbeda
    • Extent lainnya tetap dalam status berbagi
Iklan

Hal yang Perlu Diperhatikan dan Batasan

  • Tidak boleh ada koneksi aktif ke database sumber saat kloning dilakukan
    • Ini merupakan batasan PostgreSQL, bukan masalah sistem file
    • Di lingkungan produksi, penggunaan database template terpisah adalah praktik umum
  • Kloning hanya dapat dilakukan dalam satu sistem file yang sama
    • Jika beberapa tablespace berada di mount point yang berbeda, PostgreSQL akan kembali memakai penyalinan biasa
  • Pada layanan cloud terkelola (AWS RDS, Google Cloud SQL, dll.), fitur ini tidak dapat digunakan karena tidak ada akses ke sistem file
    • Di lingkungan VM sendiri atau bare metal, kontrol penuh tetap dimungkinkan

Kesimpulan

  • Fitur file_copy_method = clone di PostgreSQL 18 langsung memanfaatkan fitur klon di tingkat sistem operasi untuk
    memangkas waktu kloning database berukuran besar secara drastis
  • Di lingkungan pengujian, pengembangan, dan pembelajaran, ini memungkinkan workflow database yang bisa dikloning instan dan di-reset dengan cepat
  • Namun, desain operasional tetap perlu mempertimbangkan batasan koneksi aktif dan keharusan berada dalam satu sistem file

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-24
Komentar Hacker News

  • Untuk orang-orang yang tidak bisa menunggu atau membutuhkan isolasi instance penuh di PG18, saya membuat Velo, alat untuk melakukan branching instan dengan snapshot ZFS
    Ini bekerja di versi PostgreSQL apa pun, dan setiap branch memiliki container serta port yang independen
    Untuk DB 100GB, pembuatannya memakan waktu sekitar 2~5 detik
    Perbedaannya dengan pendekatan PG18 adalah, ini tidak berbagi satu instance, melainkan menyediakan isolasi server penuh
    Tautan GitHub

    • Di komentar lain ada keluhan soal penggunaan Claude Code, tetapi setelah melihat video demo di halaman GitHub, saya merasa ini menarik
    • Sekarang kebanyakan software ditulis dengan bantuan agen AI, jadi saya tidak paham kenapa sampai ada keluhan. Pendekatannya menarik
    • Saya juga sedang ingin membuat prototipe hal serupa dengan btrfs
    • Saya sempat merasa penggunaan kata “you” itu menarik, jadi agak kaget ketika ada yang bilang itu menjiplak

  • Dulu saat perusahaan saya bermigrasi ke RDS, kami membangun sistem serupa sendiri
    Karena sering muncul masalah saat migrasi produksi, kami mengotomatiskan langkah-langkah berikut untuk mencegahnya

    1. Menggandakan DB RDS atau membuat instance baru dari backup
    2. Mengekstrak CNAME atau IP publik dari ARN
    3. Menerapkannya ke konfigurasi koneksi DB aplikasi
    4. Menjalankan migrasi di lingkungan produksi palsu
      Berkat proses ini, kami bisa menangkap banyak bug khas produksi yang tidak terdeteksi di lokal maupun CI
      Setelah itu kami mengotomatiskannya dengan skrip Ruby sederhana, dan saya dengar skrip itu masih dipakai sampai sekarang
    • Saya juga sangat benci bug “migrasi yang gagal hanya di produksi karena kekhasan data” seperti itu. Beberapa kali saya bahkan pernah membatalkan rilis gara-gara itu

  • Baru kali ini saya tahu bahwa strategi template cloning bisa dikonfigurasi
    Saya memakai Neon untuk membuat lingkungan integrasi real-time, dan di proyek Golang saya pgtestdb, saya membuat DB Postgres dengan migrasi skema lengkap untuk setiap test
    Dulu saya pernah melihat startup membuat staging DB instan dengan btrfs, jadi menarik melihat ide serupa terus muncul berulang
    Kloning cepat dan pengujian seperti ini adalah keunggulan besar Postgres dan Sqlite, dan saya berharap hal seperti ini juga bisa dilakukan di Clickhouse atau MySQL

  • Belakangan ini PostgreSQL terasa seperti DB serbabisa yang mencakup hampir semua kebutuhan SQL
    Lagi pula ini gratis
    Jadi saya penasaran, apakah masih ada alasan kuat untuk memakai SQL DB lain

    • Postgres memang hebat, tetapi MySQL lebih mudah untuk replikasi master-master, dan MongoDB sederhana untuk distribusi geografis serta sharding
      Clickhouse jauh lebih cepat untuk analitik, dan DB seperti Cassandra unggul untuk workload yang berfokus pada tulis
      Jadi, masing-masing DB tetap punya kekuatannya sendiri
    • Ungkapan “bagus untuk semuanya” itu berlebihan
      Saat data membesar, bisa muncul penurunan performa atau masalah migrasi
      Dalam kasus saya, performa partisi bawaannya kurang baik sehingga saya harus mengimplementasikan partisi kustom sendiri
    • Postgres masih tidak efisien dalam cara implementasi MVCC-nya (copy-on-write)
      Pilihan ini menimbulkan berbagai dampak negatif saat beban meningkat
    • Dulu MySQL/InnoDB lebih baik untuk workload yang berfokus pada update
      Ini juga dibahas dalam artikel blog Uber
      Meski begitu, di lingkungan cloud saya paling percaya pada Postgres
    • Postgres masih belum punya alternatif matang setingkat Vitess
      Karena itu, pada deployment OLTP skala besar, MySQL masih lebih sering dipakai (misalnya YouTube, Uber)

  • Dengan memakai struktur data immutable (HAMT), kita bisa membuat DB yang dapat dikloning seketika tanpa bergantung pada jenis filesystem
    Saya bilang ini teori, tapi saya benar-benar sudah mengimplementasikannya
    Saya tidak paham kenapa DB berbasis HAMT seperti ini tidak lebih banyak

    • Saya adalah pembuat ClickHouse, dan ClickHouse juga mendukung kloning tabel dengan memakai bagian data immutable
      Tautan dokumen terkait
    • Saya penasaran apakah Datomic juga punya fitur cloning seperti ini bawaan. Saya sudah lama ingin mencobanya, tetapi belum siap secara mental untuk membangun aplikasi nyata dengannya

  • Saya tidak tahu bahwa di Postgres v15, WAL_LOG menjadi default
    Di lingkungan pengujian CI paralel, lebih masuk akal untuk kembali ke strategi FILE_COPY
    Saya pernah membuat issue terkait di proyek lama integresql

  • Saya pernah membuat alat GUI sederhana pgtt untuk menguji aplikasi berbasis Postgres secara lokal
    Itu sangat menyederhanakan pengaturan lingkungan pengembangan

    • Dari README saja saya masih kurang paham, jadi saya penasaran apakah strukturnya memperlakukan template seperti snapshot
      Sepertinya itu akan membantu untuk pekerjaan migrasi SQL yang berulang
    • Akan bagus kalau README punya screenshot GUI, dan tautan Docker-nya rusak

  • Saya juga membaca tulisan lain di blog tersebut, dan secara keseluruhan sangat bagus
    Terutama, saya jadi tahu tentang tipe range di Postgres untuk pertama kalinya

    • Tipe range sangat berguna untuk hal-hal seperti menghitung tumpang tindih rentang waktu/tanggal

  • Saya penasaran apakah MariaDB juga punya fitur seperti ini
    Saya sedang pusing karena lambatnya mengembalikan DB ke kondisi awal untuk tiap test
    Karena kami memakai MariaDB di produksi, sulit untuk mengganti DB
    Meski begitu, sisi Postgres memang terlihat lebih baik

    • Jalankan setiap test dalam sesi transaksi, lalu rollback di akhir agar cepat kembali ke keadaan awal
      Pendekatan ini cukup efisien
    • Jika tidak masalah me-restart DB, memakai LVM atau snapshot btrfs di level filesystem juga bisa jadi cara

  • AWS juga mendukung fitur serupa
    Dokumen kloning Aurora

    • Klon Aurora bekerja dengan copy-on-write di level storage, tetapi tetap perlu mem-provision cluster baru sehingga memakan waktu sekitar 10 menit
      Untuk pengujian integrasi, ini tidak realistis
    • Kloning Aurora bersifat tingkat cluster, sedangkan yang dibahas di sini adalah kloning tingkat database