Upgrade Postgres Tanpa Downtime

Persiapan untuk upgrade Postgres

• Penilaian risiko: Buat daftar risiko yang dapat muncul selama proses upgrade dan urutkan berdasarkan tingkat kepentingannya.
• Mencari cara mitigasi risiko: Pertimbangkan solusi yang dapat sepenuhnya menghilangkan risiko atau menyebarkannya seiring waktu.
• Memperbarui daftar risiko: Perbarui daftar saat risiko baru ditemukan selama proyek berlangsung.

Tentang pemantauan dan metrik

• Pemantauan sistem: Gunakan alat yang menyeluruh untuk memantau kesehatan database dan sistem.
• Mengamati metrik inti: Pantau metrik utama seperti transaction ID, penggunaan CPU, sesi yang menunggu, latensi query, dan latensi respons API.

Opsi upgrade Postgres

Upgrade in-place (tidak cocok untuk upgrade zero downtime)

• Keterbatasan upgrade in-place: Saat dijalankan di AWS RDS, database perlu di-reboot, dan waktu yang dibutuhkan bergantung pada jumlah data.

Upgrade berbasis replikasi

• Memilih upgrade berbasis replikasi: Memungkinkan tahap migrasi bertahap, pengujian database baru dengan workload dan data nyata, serta kendali yang lebih baik atas proses upgrade.
• Menyiapkan database sumber dan tujuan: Atur replication slot, dan setel wal_level ke logical.

Memilih metode replikasi tabel

Replikasi tabel "kecil"

• Replikasi tabel kecil: Dapat direplikasi dengan penambahan sederhana dan refresh subscription.

Tabel besar yang hanya append

• Replikasi tabel append-only: Setel opsi copy_data ke false agar hanya perubahan di masa depan yang direplikasi, lalu lakukan backfill data lama dari backup.

Tabel besar dengan banyak update

• Replikasi tabel besar dengan banyak update: Kecilkan ukuran tabel, jalankan VACUUM, dan pertimbangkan partisi tabel.

Memeriksa status replikasi tabel

• Memantau status replikasi: Periksa status replikasi melalui tabel sistem pg_subscription_rel, dan disarankan mereplikasi satu tabel pada satu waktu.

Menghentikan replikasi

• Cara menghentikan replikasi: Jika perlu, replikasi tabel dapat dihentikan dan di-rollback dengan refresh subscription.

Perhatian tentang pemindahan replication slot

• Masalah pemindahan replication slot: LSN dari replication slot bersifat unik untuk database asal, sehingga tidak bisa langsung disalin ke database baru.

Menyelesaikan migrasi

• Memverifikasi konsistensi tabel: Pastikan jumlah baris tabel cocok di kedua database, dan bila perlu verifikasi konsistensi data dengan sampling acak.

Perubahan di level aplikasi

• Mengubah koneksi database: Ubah aplikasi agar terhubung ke database baru, dan siapkan strategi pengalihan traffic.

Catatan tambahan tentang sequence

• Sinkronisasi sequence: Nilai sequence tidak disinkronkan selama proses replikasi, sehingga nilai sequence perlu disetel secara manual.

Checklist pemeriksaan akhir

• Pemeriksaan akhir: Kecocokan tabel, status subscription, kecocokan skema, ukuran database, penambahan replika, pembangunan ulang indeks, pengujian performa, penilaian risiko, dan latihan di lingkungan staging.

Peralihan akhir

• Menjalankan peralihan akhir: Lakukan replikasi tabel pada malam hari, berlatih beberapa kali di lingkungan staging, lalu lakukan pemeriksaan akhir dan pengalihan flag.

Opini GN⁺

• Pentingnya: Knock berhasil menjalankan proses kompleks upgrade dari Postgres 11.9 ke 15.3 tanpa downtime. Ini menjadi tonggak penting dalam pengelolaan database dan ketersediaan layanan.
• Menarik: Pendekatan upgrade berbasis replikasi memungkinkan administrator database melakukan transisi yang mulus ke database baru, dan hal ini dapat menarik minat besar dari komunitas teknis.
• Seru: Proses upgrade Knock menunjukkan praktik terbaik dalam mengatasi tantangan teknis yang kompleks melalui manajemen risiko yang sistematis dan pemecahan masalah.

[GN⁺]

Komentar Hacker News

• Ada cara yang lebih baik daripada menyalin tabel berukuran besar.

  • Anda bisa membuat replika logis dengan membuat replication slot, mengambil snapshot, memulihkan snapshot ke instance baru, memajukan LSN, lalu memulai replikasi.
  • Artikel dari Instacart menjelaskan proses ini.
  • Mungkin ada kesalahan kecil di artikelnya, tetapi metode ini telah berhasil digunakan berkali-kali untuk meng-upgrade instance berukuran TB.

• Pendekatan yang disajikan di sini menarik dan terdokumentasi dengan baik, tetapi saya tidak setuju dengan kalimat "pelanggan modern mengharapkan ketersediaan 100%".

  • Berdasarkan pengalaman sebagai pelanggan maupun pemasok, konsistensi jauh lebih penting daripada ketersediaan.
  • Saat vendor mengumumkan downtime, saya justru merasa lega karena itu tanda mereka menangani data dengan hati-hati.

• AWS sekarang mendukung deployment blue-green.

• Saya menulis alat yang mengotomatiskan sebagian besar masalah ini.

  • Alat tersebut dibagikan di GitHub dan bisa dikembangkan lebih lanjut melalui masukan atau ide.

• Di hava.io, kami sedang bermigrasi dari AWS RDS PostgreSQL 11.13 ke 15.5.

  • Kami memilih metode replikasi satu arah menggunakan pglogical.
  • Metode ini tidak cepat, tetapi dapat memakan waktu beberapa hari untuk mereplikasi database secara bertahap ke instance baru.
  • Metode ini memberi lebih banyak kebebasan untuk mengubah jenis dan ukuran storage.

• Saya mempertanyakan klaim bahwa downtime dalam bentuk apa pun tidak dapat diterima untuk layanan Knock.

  • Sistem yang kompleks pasti mengalami insiden dan downtime.
  • Downtime 15 menit yang diumumkan sebelumnya bukan masalah bagi sebagian besar bisnis SaaS.
  • Menginvestasikan waktu engineering pada pengembangan produk atau peningkatan kecepatan tim pengembang bisa memberi kepuasan yang lebih besar bagi pengguna.
  • Dalam migrasi database, perbedaan beban kerja antara membuat migrasi dengan "downtime minim" dan migrasi "tanpa downtime" sangat besar.

• Saya terkejut bahwa replikasi tidak bisa diinisialisasi dari backup.

  • Itu seharusnya bisa mengurangi kerepotan melakukan streaming isi DB yang sudah stabil ke server baru.
  • Disebut "tanpa downtime", tetapi pada praktiknya tetap ada downtime beberapa detik saat beralih ke server baru.
  • Tidak ada rincian tentang cara menjaga konsistensi.
  • Tidak ada penyebutan opsi rollback, padahal saat melakukan pemindahan satu kali untuk data berskala besar, Anda selalu perlu punya rencana untuk kembali ke tahap sebelumnya.

• Ada yang tertarik dengan alat all-in-one yang bisa melakukan update Postgres tanpa downtime hanya dengan memasukkan kredensial database?

• Pembahasan tentang penggunaan sequence cukup menarik.

  • Saya lebih sering memakai UUID berurutan atau algoritma HiLo daripada sequence.

• Sebagai lelucon, masalah yang muncul dalam sistem terdistribusi bisa diselesaikan dengan sleep(1000) yang tepat.

  • Postgres bukan sistem yang akrab bagi DBA, tetapi sekarang lebih baik dibanding dulu.