Beberapa tahun terakhir telah terlihat peningkatan adopsi untuk PostgreSQL. PostgreSQL adalah database relasional yang luar biasa. Dari segi fitur, ada yang terbaik, jika bukan yang terbaik. Ada banyak hal yang saya sukai – PL/PG SQL, default cerdas, replikasi (yang benar-benar bekerja di luar kotak), dan komunitas open source yang aktif dan bersemangat. Namun, selain fitur, ada aspek penting lain dari database yang perlu dipertimbangkan. Jika Anda berencana untuk membangun operasi 24/7 yang besar, kemampuan untuk mengoperasikan database dengan mudah setelah dalam produksi menjadi faktor yang sangat penting. Dalam aspek ini, PostgreSQL tidak bertahan dengan baik. Dalam posting blog ini, kami akan merinci beberapa tantangan operasional ini dengan PostgreSQL. Tidak ada yang secara fundamental tidak dapat diperbaiki di sini, hanya masalah prioritas. Semoga kami dapat membangkitkan minat yang cukup pada komunitas open source untuk memprioritaskan fitur-fitur ini.
1. Tidak Ada Deteksi Driver Klien Otomatis dari Master Failover
Driver klien PostgreSQL tidak secara otomatis mendeteksi saat terjadi failover master (dan master baru telah dipilih). Untuk mengatasi ini, administrator harus menyebarkan lapisan proxy di sisi server. Pilihan populer adalah pemetaan DNS, pemetaan IP virtual, PgPool dan HAProxy. Semua opsi ini dapat dibuat untuk bekerja dengan baik, tetapi ada pembelajaran tambahan yang signifikan dan upaya administrator yang diperlukan. Jika proxy diperkenalkan di jalur data, ada juga dampak kinerja yang cukup besar. Ini adalah fitur bawaan standar di banyak database NoSQL baru, dan PostgreSQL akan melakukan yang terbaik untuk mengambil bagian dari pembukuan mereka dalam hal operasi.
2. Tidak Ada Failover Otomatis Bawaan Antara Master &Siaga
Saat master PostgreSQL gagal, salah satu server siaga harus dipilih untuk menjadi master. Mekanisme ini tidak dibangun ke dalam PostgreSQL. Biasanya, perangkat lunak pihak ketiga seperti Patroni, Pacemaker, dll. digunakan untuk menangani skenario ini. Mengapa ini tidak membangunnya ke dalam server? Alat pihak ketiga ini tampak sederhana, tetapi membutuhkan banyak usaha, pengetahuan, dan pengujian dari pihak administrator untuk mendapatkan hak ini. Dengan memasukkan ini ke dalam database, Anda memberikan bantuan yang sangat besar kepada administrator database Anda.
Mempermudah Mengelola Produksi #PostgreSQL DatabaseKlik Untuk Tweet3. Upgrade Besar Tanpa Nol Waktu Henti
Tidak mungkin mengupgrade database PostgreSQL Anda dari satu versi utama ke versi lain tanpa waktu henti. Anda pada dasarnya harus mematikan semua server Anda dan menggunakan pg_upgrade untuk meningkatkan data Anda ke versi yang lebih baru. Waktu hentinya tidak besar karena tidak ada salinan data yang terlibat, namun masih ada waktu henti. Jika Anda menjalankan operasi 24/7, ini mungkin bukan pilihan untuk Anda.
Dengan dirilisnya replikasi logis, kami memiliki opsi alternatif untuk peningkatan online.
- Buat penyiapan PostgreSQL Master-Standby baru dengan versi baru.
- Siapkan replikasi logis untuk direplikasi dari versi lama ke versi yang lebih baru.
- Setelah Anda siap, ubah string koneksi Anda dari penyiapan lama ke penyiapan baru.
Sekali lagi, ini dapat dibuat berfungsi, tetapi biayanya sangat besar. Idealnya, apa yang diperlukan di sini adalah cara untuk meningkatkan di tempat secara bergulir melalui pengaturan siaga utama. Upgrade MySQL memungkinkan Anda untuk mengupgrade slave di tempat ke versi baru dan kemudian memicu failover.
4. Tidak ada VAKUM PENUH di Tempat
Autovacuum/VACUUM sangat berguna dan membantu mengatasi masalah ini sampai batas tertentu. Anda harus memeriksa kembung di meja secara teratur untuk memastikan setelan vakum otomatis Anda sesuai dan berfungsi dengan baik untuk meja Anda. Namun, autovacuum tidak sepenuhnya berfungsi – itu tidak benar-benar berakhir dengan menggabungkan dan menghapus halaman. Jika Anda memiliki banyak pembaruan, memasukkan dan menghapus beban kerja, halaman Anda akan berakhir terfragmentasi, memengaruhi kinerja Anda. Satu-satunya cara untuk mengatasinya adalah dengan menjalankan VACUUM FULL yang pada dasarnya akan membangun kembali semua halaman untuk menghilangkan fragmentasi. Namun, proses ini hanya dapat dilakukan dengan waktu henti – meja Anda tidak aktif selama VACUUM FULL. Untuk kumpulan data besar, ini bisa memakan waktu beberapa jam dan bukan alternatif praktis jika Anda ingin menjalankan operasi 24/7.
Catatan:Komunitas telah mulai bekerja pada mesin penyimpanan zheap yang mengatasi batasan ini.
Jika ada perbaikan lain yang menurut Anda berguna, silakan tinggalkan komentar.
