Jasa Managed PostgreSQL

Penyetelan PostgreSQL untuk lingkungan produksi

Konfigurasi bawaan PostgreSQL sengaja dibuat konservatif agar bisa berjalan di mesin apa pun. Pada server produksi, hampir semuanya perlu disesuaikan:

• Penyesuaian shared_buffers, work_mem, dan effective_cache_size terhadap kapasitas memori.
• Penyetelan autovacuum agar mengikuti pola penulisan aplikasi Anda.
• Konfigurasi checkpoint dan WAL untuk menyeimbangkan performa dan ketahanan.
• Analisis rencana eksekusi kueri yang berat beserta penambahan indeks yang tepat.
• Pemakaian indeks parsial dan indeks ekspresi untuk pola kueri tertentu.
• Pemantauan bloat tabel dan indeks beserta penjadwalan pemeliharaannya.

Ketersediaan tinggi dengan Patroni

PostgreSQL menyediakan replikasi bawaan, tetapi perpindahan peran saat server utama mati tidak terjadi otomatis. Patroni mengisi peran itu: ia memantau kesehatan setiap node dan mempromosikan replika menjadi utama ketika dibutuhkan.

Kami memasang Patroni bersama penyimpanan konfigurasi terdistribusi dan penyeimbang beban di depannya, sehingga aplikasi cukup terhubung ke satu alamat tanpa perlu mengetahui node mana yang sedang berperan sebagai utama.

Connection pooling dan pemulihan titik waktu

PostgreSQL membuat satu proses untuk setiap koneksi, sehingga ratusan koneksi menganggur bisa menghabiskan memori dengan cepat. PgBouncer mengumpulkan koneksi tersebut menjadi kumpulan kecil yang dipakai bergantian, dan sering menyelesaikan masalah performa tanpa menambah perangkat keras.

Untuk keamanan data, kami menyiapkan arsip WAL berkelanjutan yang memungkinkan pemulihan ke titik waktu tertentu — misalnya tepat satu menit sebelum perintah penghapusan yang keliru dijalankan.

Tuning PostgreSQL production dari nilai bawaan

Nilai bawaan PostgreSQL dirancang agar bisa berjalan di mesin sekecil apa pun, termasuk laptop lama. Pada server produksi, hampir semuanya perlu disesuaikan — dan pekerjaan tuning PostgreSQL production inilah yang paling sering memberi peningkatan terbesar tanpa menambah perangkat keras.

Yang disetel lebih dulu: shared_buffers sekitar seperempat memori server, effective_cache_size mendekati tiga perempat sebagai petunjuk bagi perencana kueri, dan work_mem yang dihitung dari jumlah koneksi bersamaan — bukan dari angka yang terlihat besar. Salah di work_mem berbahaya karena nilainya dipakai per operasi pengurutan, bukan per koneksi.

Setelah itu perilaku checkpoint dan WAL. Checkpoint yang terlalu sering membuat penulisan tersendat berkala; yang terlalu jarang membuat pemulihan setelah mati mendadak jauh lebih lama. Titik seimbangnya bergantung pada pola tulis aplikasi Anda, jadi diukur dulu.

Autovacuum dan bloat yang tumbuh diam-diam

PostgreSQL tidak menghapus baris lama saat data diperbarui; ia menandainya mati dan menulis versi baru. Autovacuum-lah yang membersihkannya. Kalau setelannya tidak mengejar laju perubahan aplikasi, tabel dan indeks membengkak perlahan — kueri melambat, disk terus terisi, dan tidak ada satu pun gejala mencolok sampai keadaannya sudah parah.

Karena itu kami menaikkan agresivitas autovacuum pada tabel yang sering berubah, memantau perbandingan baris mati terhadap baris hidup, dan menjadwalkan reindex pada indeks yang sudah membengkak. Pemantauan bloat ini masuk laporan bulanan, bukan hanya diperiksa saat ada keluhan.

Streaming replication Postgres dan Patroni failover

Menyiapkan streaming replication Postgres memberi salinan data yang selalu segar sekaligus tempat mengarahkan kueri baca. Tetapi replikasi bawaan tidak memindahkan peran secara otomatis: kalau server utama mati, seseorang harus mempromosikan replika secara manual.

Di situlah Patroni failover berperan. Patroni memantau kesehatan setiap node dan mempromosikan replika ketika dibutuhkan, dengan penyimpanan konfigurasi terdistribusi sebagai penentu siapa yang berhak menjadi utama — sehingga tidak pernah ada dua node yang mengira dirinya utama.

Aplikasi tetap terhubung ke satu alamat lewat penyeimbang beban, jadi perpindahan peran tidak menuntut perubahan di sisi aplikasi. Skenario failover diuji sebelum lingkungan diserahkan, karena mekanisme yang belum pernah diuji tidak bisa disebut siap.

PgBouncer connection pooling dan backup PITR PostgreSQL

PostgreSQL membuat satu proses untuk setiap koneksi. Beberapa ratus koneksi menganggur bisa menghabiskan memori tanpa mengerjakan apa pun. PgBouncer connection pooling mengumpulkannya menjadi kumpulan kecil yang dipakai bergantian, dan cukup sering menyelesaikan keluhan performa tanpa satu pun perubahan perangkat keras.

Untuk perlindungan data, backup PITR PostgreSQL menggabungkan cadangan dasar dengan arsip WAL berkelanjutan. Hasilnya kemampuan memulihkan ke titik waktu tertentu — misalnya satu menit sebelum perintah UPDATE tanpa klausa WHERE dijalankan. Tanpa arsip WAL, pilihan Anda hanya kembali ke cadangan malam sebelumnya beserta seluruh transaksi hari itu yang ikut hilang.