Minggu lalu, saya berada di Nordic PGDay 2018 dan saya memiliki beberapa percakapan tentang alat yang saya tulis, yaitu pglupgrade , untuk mengotomatiskan pemutakhiran versi utama PostgreSQL dalam penyiapan kluster replikasi. Saya cukup senang bahwa itu telah didengar dan beberapa orang lain di komunitas yang berbeda memberikan ceramah di pertemuan dan konferensi lain tentang peningkatan waktu henti yang hampir nol menggunakan replikasi logis. Mengingat ada ceramah yang saya berikan di PGDAY'17 Russia, PGConf.EU 2017 di Warsawa dan terakhir di FOSDEM PGDay 2018 di Brussels, saya pikir lebih baik membuat posting blog agar presentasi ini tersedia bagi orang-orang yang bisa tidak sampai ke salah satu konferensi yang disebutkan di atas. Jika Anda ingin langsung berbicara dan melewatkan membaca posting blog ini, inilah tautan Anda:Peningkatan Otomatis Cluster PostgreSQL Hampir-Zero Downtime di Cloud
Motivasi utama di balik pengembangan alat ini adalah untuk mengusulkan solusi untuk meminimalkan waktu henti selama pemutakhiran versi utama yang sayangnya mempengaruhi hampir semua orang yang menggunakan PostgreSQL. Saat ini, kami tidak memiliki alat yang memungkinkan pengguna PostgreSQL untuk memutakhirkan database mereka tanpa waktu henti dan ini jelas merupakan masalah bagi banyak pengguna, terutama bisnis. Dan, jika kita ingin memecahkan masalah peningkatan, kita harus memikirkan lebih dari satu server (mulai akan disebut sebagai cluster), karena tidak banyak orang yang hanya menggunakan satu server database lagi. Skenario yang paling umum adalah memiliki penyiapan replikasi streaming fisik baik untuk tujuan ketersediaan tinggi atau penskalaan kueri baca.
Peningkatan Basis Data
Sebelum menyelami solusinya, mari kita bahas sedikit tentang cara kerja pemutakhiran basis data secara umum. Ada empat kemungkinan pendekatan utama untuk peningkatan basis data:
- Pendekatan pertama adalah agar database menjaga format penyimpanannya tetap sama atau setidaknya kompatibel di seluruh versi. Namun, ini sulit untuk menjamin jangka panjang karena fitur baru mungkin memerlukan perubahan dalam cara data disimpan atau menambahkan lebih banyak informasi metadata agar berfungsi dengan baik. Selain itu, performa sering kali ditingkatkan dengan mengoptimalkan struktur data.
- Pendekatan kedua adalah membuat salinan logis (dump) dari server lama dan memuatnya ke server baru. Ini adalah pendekatan paling tradisional yang mengharuskan server lama untuk tidak menerima pembaruan apa pun selama proses dan mengakibatkan waktu henti yang berkepanjangan berjam-jam atau bahkan berhari-hari di database besar.
- Opsi ketiga adalah mengonversi data dari format lama ke format baru. Ini dapat dilakukan dengan cepat saat sistem baru sedang berjalan, tetapi menimbulkan penalti kinerja yang sulit diprediksi karena bergantung pada pola akses data, atau dapat dilakukan secara offline saat server sedang down, lagi-lagi menimbulkan berkepanjangan waktu henti (walaupun sering kali lebih pendek dari metode kedua).
- Metode keempat adalah menggunakan dump logis untuk menyimpan dan memulihkan database sambil merekam perubahan yang terjadi sementara dan secara logis mereplikasinya ke database baru setelah pemulihan awal selesai. Metode ini memerlukan orkestrasi dari beberapa komponen tetapi juga mengurangi jumlah waktu yang tidak dapat ditanggapi oleh database terhadap kueri.
Tingkatkan Metode di PostgreSQL
Upgrade PostgreSQL dapat dicocokkan dengan empat metode yang tercantum di atas. Misalnya, rilis minor PostgreSQL, yang tidak berisi fitur baru tetapi hanya perbaikan, tidak mengubah format data yang ada dan sesuai dengan pendekatan pertama. Untuk pendekatan kedua, PostgreSQL menyediakan alat yang disebut pg_dump dan pg_restore yang melakukan pencadangan dan pemulihan logis. Ada juga alat pg_upgrade (itu adalah modul contrib dan dipindahkan ke pohon utama di PostgreSQL 9.5) yang melakukan konversi offline (server tidak berjalan) dari direktori data lama ke direktori baru, yang dapat masuk ke dalam opsi ketiga. Untuk pendekatan keempat, ada solusi berbasis pemicu pihak ketiga seperti Slony untuk memutakhirkan, tetapi mereka memiliki beberapa peringatan yang akan kita bahas nanti.
Metode peningkatan versi tradisional hanya bisa tingkatkan server utama sementara server replika harus dibangun kembali sesudahnya (konversi offline) . Hal ini menyebabkan masalah tambahan dengan ketersediaan dan kapasitas cluster, sehingga secara efektif meningkatkan persepsi waktu henti database dari sudut pandang aplikasi dan pengguna. Replikasi logis memungkinkan replikasi saat sistem berjalan dan berjalan dan upaya pengujian dapat ditangani sementara itu (konversi online) .
Ada berbagai metode peningkatan yang berlaku untuk lingkungan yang berbeda. Misalnya, pg_dump memungkinkan peningkatan versi dari versi lama (yaitu 7.0) ke rilis terbaru, jadi jika Anda menjalankan PostgreSQL versi antik, metode terbaik adalah menggunakan pg_dump/restore (dan lebih baik lakukan sekarang!). Jika PostgreSQL versi Anda adalah 8.4 dan yang lebih baru Anda dapat menggunakan pg_upgrade . Jika Anda menggunakan PostgreSQL 9.4 dan yang lebih baru ini berarti Anda memiliki “Penguraian Logika” dalam inti dan Anda dapat menggunakan pglogical ekstensi sebagai sarana peningkatan. Terakhir, jika Anda menggunakan PostgreSQL 10 , Anda akan memiliki kesempatan untuk meningkatkan basis data Anda ke PostgreSQL 11 dan yang lebih baru (setelah tersedia) dengan menggunakan “Replikasi Logis” dalam inti (ya!).
Replikasi Logis untuk Upgrade
Di mana ide untuk memutakhirkan PostgreSQL dengan menggunakan replikasi logis berasal dari? Jelas, pglogical tidak mengklaim tujuan peningkatan secara terbuka seperti pg_upgrade tidak (ini adalah salah satu argumen menentang pglogical di pesta konferensi ), tetapi ini tidak berarti bahwa kami tidak dapat menggunakan alat untuk peningkatan. Faktanya, ketika pglogical dirancang, peningkatan waktu henti hampir nol dianggap sebagai salah satu kasus penggunaan yang diharapkan oleh pengembang ekstensi.
Tidak seperti replikasi fisik, yang menangkap perubahan pada data mentah pada disk, replikasi logis menangkap perubahan logis ke catatan individu dalam database dan mereplikasi mereka. Catatan logis berfungsi di seluruh rilis utama , maka replikasi logis dapat digunakan untuk meningkatkan versi dari satu rilis ke rilis lainnya. Gagasan menggunakan replikasi logis sebagai sarana peningkatan versi masih jauh dari yang baru, alat replikasi berbasis pemicu telah melakukan peningkatan secara logis dengan menangkap dan mengirim perubahan melalui pemicu (karena pemicu dapat bekerja terlepas dari versi database juga! ).
Jika Anda dapat menggunakan solusi replikasi berbasis pemicu untuk pemutakhiran waktu henti minimum, mengapa Anda lebih memilih replikasi logis? Dalam mekanisme berbasis pemicu, semua perubahan ditangkap dengan menggunakan pemicu dan ditulis ke dalam tabel antrean. Prosedur ini menggandakan operasi tulis, menggandakan file log, dan memperlambat sistem karena semua perubahan harus ditulis dua kali; menghasilkan lebih banyak disk I/O dan memuat pada server sumber. Sebaliknya, replikasi logis dalam inti (sama berlaku untuk ekstensi pglogical) dibangun di atas decoding logis. Decoding logis adalah mekanisme yang mengekstrak informasi dari file WAL menjadi perubahan logis (INSERT/UPDATE/DELETE). Karena data dari mekanisme WAL digunakan dengan mendekode log transaksi, tidak ada amplifikasi penulisan seperti dalam kasus solusi replikasi berbasis pemicu, maka metode ini berperforma lebih baik . Akibatnya, solusi berbasis decoding logis hanya memiliki dampak yang lebih rendah pada sistem daripada solusi berbasis pemicu.
Kesimpulan
Dalam postingan pengantar ini, saya ingin memberikan gambaran mengapa kita harus mempertimbangkan untuk menggunakan replikasi logis untuk mencapai waktu henti minimal selama peningkatan versi utama. Kami akan melanjutkan dengan detail arsitektur dan implementasi alat ini di postingan mendatang.
