PostgreSQL 9.6 baru saja dirilis dan sebagian besar pengguna postgres akan mulai bertanya pada diri sendiri bagaimana meningkatkan ke versi utama yang baru. Postingan ini bertujuan untuk menunjukkan prosedur yang berbeda untuk mengupgrade server PostgreSQL Anda.
Memutakhirkan ke versi utama yang baru adalah tugas yang memiliki rasio persiapan yang tinggi dibandingkan total waktu eksekusi. Khususnya saat melewatkan rilis di tengah, misalnya saat Anda melompat dari versi 9.3 ke versi 9.5.
Pelepasan poin
Di sisi lain, peningkatan rilis poin tidak memerlukan banyak persiapan. Secara umum, satu-satunya persyaratan adalah agar layanan postgres dimulai ulang. Tidak ada perubahan pada struktur data yang mendasarinya, jadi tidak perlu membuang dan memulihkan. Dalam skenario terburuk, Anda mungkin perlu membuat ulang beberapa indeks setelah Anda selesai memutakhirkan rilis poin.
Sangat bijaksana untuk selalu mengikuti rilis poin terbaru, sehingga Anda tidak tersandung bug yang diketahui (dan kemungkinan diperbaiki). Ini berarti bahwa setelah versi terbaru keluar, jadwalkan waktu untuk peningkatan sesegera mungkin.
Upgrade rilis utama
Saat melakukan tugas kompleks seperti ini, ada baiknya mempertimbangkan semua opsi yang memungkinkan untuk mencapai hasil akhir.
Untuk peningkatan versi rilis besar, ada tiga kemungkinan jalur yang dapat Anda ambil:
- Upgrade pemulihan dari dump logis
- Peningkatan fisik
- Peningkatan versi Online
Mari saya jelaskan masing-masing secara rinci:
1) Tingkatkan versi pemulihan dari dump logis
Ini adalah cara termudah dari semua cara yang mungkin untuk meningkatkan struktur data cluster Anda.
Singkatnya, proses di sini memerlukan dump logis menggunakan pg_dump dari versi lama, dan pg_restore pada cluster bersih yang dibuat dengan versi yang baru diinstal.
Poin-poin penting yang mendukung penggunaan jalur ini adalah:
- Ini yang paling teruji
- Kompatibilitas kembali ke versi 7.0 sehingga pada akhirnya Anda dapat meningkatkan versi dari 7.x ke salah satu rilis terbaru
Alasan mengapa Anda harus menghindari penggunaan opsi ini:
- Total waktu henti pada database besar dapat menjadi masalah, karena Anda harus menghentikan koneksi tulis sebelum mulai menjalankan pg_dump;
- Jika ada banyak objek besar dalam database, pg_dump akan lambat. Bahkan ketika melakukannya secara paralel. Pemulihan akan lebih lambat dari pg_dump ketika banyak objek besar disimpan dalam database;
- Ini membutuhkan ruang disk ganda, atau penghapusan cluster lama sebelum memulihkan;
Pada server dengan beberapa inti CPU, pg_dump dapat dijalankan secara paralel menggunakan format direktori. Setelah selesai, pulihkan juga secara paralel, menggunakan sakelar -j di pg_dump dan pg_restore. Tetapi Anda tidak dapat memulai proses pemulihan sampai seluruh dump selesai.
2) Peningkatan fisik
Upgrade semacam ini telah tersedia sejak versi 9.0 untuk melakukan upgrade di tempat dari versi setua 8.3. Disebut “di tempat” karena dilakukan di server yang sama, dan sebaiknya di direktori data yang sama.
Keuntungan dari jenis peningkatan ini:
- Anda tidak memerlukan ruang untuk salinan cluster lainnya.
- Waktu henti jauh lebih rendah dibandingkan dengan menggunakan pg_dump.
Ada beberapa kelemahan:
- Setelah Anda memulai PostgreSQL versi baru, Anda tidak dapat kembali ke versi lama (cluster hanya akan berfungsi dengan versi baru dari sana).
- Statistik dinolkan setelah pemutakhiran, jadi segera setelah memulai versi baru PostgreSQL, analisis luas klaster harus dijalankan.
- Ada banyak bug yang ditemukan selama beberapa tahun terakhir terkait pg_upgrade, yang membuat beberapa administrator database enggan menggunakan metode ini untuk memutakhirkan.
- Beberapa orang mengalami masalah saat melewatkan rilis utama, misalnya beralih dari versi 9.2 ke versi 9.4.
- Dengan katalog besar, kinerjanya akan buruk (cluster dengan banyak database, atau database dengan ribuan objek).
Anda juga dapat menjalankan pg_upgrade tanpa opsi –link (dalam hal ini pg_upgrade akan menghasilkan salinan kedua pada disk cluster Anda) sehingga Anda dapat kembali ke versi lama. Tetapi Anda akan kehilangan kedua keuntungan yang tercantum di atas.
3) Peningkatan versi Online
Prosedur yang harus diikuti untuk metode ini adalah seperti ini:
- Instal kedua versi sehingga Anda dapat membuatnya bekerja secara paralel. Ini dapat dilakukan di server yang sama, atau menggunakan dua server fisik.
- Buat salinan awal, dan replikasi perubahan sejak Anda memulai penyalinan pada node sumber (ini akan mirip dengan pg_dump awal).
- Terus replika perubahan secara logika hingga lag mendekati nol.
- Tunjukkan kembali info koneksi dari server aplikasi untuk terhubung ke server baru.
Jenis pemutakhiran ini telah tersedia sejak solusi replikasi berbasis pemicu pertama ada. Dengan kata lain, sejak Slony-I ada.
Solusi replikasi berbasis pemicu tidak peduli versi mana yang Anda miliki di satu sisi atau yang lain, karena ia menyalin perubahan menggunakan perintah SQL yang didukung.
Alat replikasi berbasis pemicu yang direkomendasikan, dalam urutan kemunculannya adalah:
- skytools:PgQ + londiste
- Slony-I
Ini harus menjadi cara yang disukai untuk meningkatkan. Mari kita lihat keuntungan menggunakan metode ini:
- Tidak ada waktu henti!
- Bagus juga untuk meningkatkan ke perangkat keras yang lebih baru.
- Pengujian cluster secara online dengan versi baru (kueri hanya-baca, atau Anda mungkin akan mengalami konflik).
- Mengurangi secara drastis semua tabel dan indeks yang membengkak.
Ada beberapa kelemahan:
- Perlu ruang penyimpanan ganda, karena harus menyimpan salinan kedua dari data Anda.
- Karena didasarkan pada pemicu, sistem harus menulis setiap perubahan dua kali, yang berarti akan ada lebih banyak disk I/O saya di server sumber (klaster versi lama).
- Semua tabel harus memiliki kunci utama, sehingga alat replikasi dapat mempersonalisasikan tupel yang diperbarui atau dihapus
- Ini tidak mereplikasi tabel katalog, jadi tidak akan mereplikasi objek besar.
- Penggunaan dasar tidak mencakup perubahan skema. Itu bisa dilakukan, tapi tidak transparan.
Perbatasan baru dengan pglogical
Sejak PostgreSQL 9.4 kami memiliki decoding logis dari log transaksi. Ini berarti bahwa sekarang kita dapat memecahkan kode transaksi dari WAL dan memanipulasi outputnya.
Dunia kemungkinan yang sama sekali baru muncul di bidang replikasi. Pemicu tidak lagi diperlukan untuk menyelesaikan replikasi logis!
Ini pada dasarnya berarti Anda tidak perlu menyimpan salinan terpisah dari semua sisipan, pembaruan, dan penghapusan menggunakan pemicu lagi. Anda bisa mendapatkan operasi manipulasi data tersebut dari log transaksi, dengan mendekodekannya. Kemudian, itu adalah alat yang Anda gunakan yang harus memanipulasi output dan mengirimkannya ke node hilir yang berlangganan. Dalam hal ini alat tersebut bersifat pglogical.
Jadi, apa artinya semua ini?
Nah, jika Anda menggunakan PostgreSQL versi 9.4 atau 9.5 dan ingin mengupgrade ke 9.6, Anda dapat melakukan upgrade online seperti yang dijelaskan di atas, tetapi menggunakan pglogical alih-alih salah satu solusi replikasi berbasis pemicu.
Saya tidak akan membahas lebih jauh karena ada blog lain tentang topik khusus ini, seperti yang ditulis oleh Petr Jelinek:Paket PGLogical 1.1 untuk PostgreSQL 9.6beta1
Kesimpulan
Bergantung pada skema database Anda, ukuran data, kemungkinan jendela waktu henti, versi penginstalan PostgreSQL saat ini, Anda dapat memilih satu opsi di atas yang lain atau apa pun yang paling sesuai.
- Jika database Anda kecil dan ada jendela pemeliharaan yang sesuai yang dapat Anda gunakan, Anda dapat memilih untuk menjalankan pg_dump dan pg_restore. Bergantung pada ukuran kumpulan data, ada titik di mana opsi tidak memungkinkan lagi.
- Jika Anda memiliki database yang besar (beberapa ratus GB, atau bahkan TB data), Anda harus mencari opsi lain seperti peningkatan di tempat dengan pg_upgrade atau peningkatan online.
- Jika meningkatkan dari versi 8.3 atau lebih tinggi ke versi 9.x apa pun, Anda dapat menggunakan pg_upgrade.
- Untuk versi yang lebih lama dari 8.3, Anda harus memilih salah satu solusi replikasi logis seperti londiste atau slony.
- Jika pada database 9.4 atau 9.5 Anda lebih baik menggunakan pglogical.
Selalu ingat bahwa untuk replikasi logis, tabel harus memiliki Kunci Utama.
Dengan pglogical aturan itu tidak terlalu ketat:Anda dapat mereplikasi tabel hanya sisipan. Tapi untuk update dan delete, tetap wajib ada Primary Key atau REPLICA IDENTITY di tabel.
Jika Anda membutuhkan bantuan untuk mengupgrade database PostgreSQL, Anda dapat memeriksa
layanan Upgrade 2ndQuadrant.
