Saatnya.
Sekitar setahun yang lalu, kami menerbitkan PostgreSQL 10 dengan dukungan untuk replikasi logis asli. Salah satu kegunaan dari replikasi logis adalah untuk memungkinkan pemutakhiran yang rendah atau tanpa waktu henti antara versi utama PostgreSQL. Hingga saat ini, PostgreSQL 10 adalah satu-satunya rilis PostgreSQL dengan replikasi logika asli, jadi tidak banyak peluang untuk meningkatkan dengan cara ini. (Replikasi logis juga dapat digunakan untuk memindahkan data antar instans pada sistem operasi atau arsitektur CPU yang berbeda atau dengan pengaturan konfigurasi tingkat rendah yang berbeda seperti ukuran blok atau lokal — sidegrading jika Anda mau.) Sekarang setelah PostgreSQL 11 sudah dekat, akan ada lebih banyak alasan untuk menggunakan fungsi ini.
Mari kita bandingkan dulu tiga cara utama untuk meningkatkan instalasi PostgreSQL:
- pg_dump dan pulihkan
- pg_upgrade
- replikasi logis
Kami dapat membandingkan metode ini dalam hal ketangguhan, kecepatan, waktu henti yang diperlukan, dan batasan (dan banyak lagi, tetapi kami harus berhenti di suatu tempat untuk artikel ini).
pg_dump dan restore bisa dibilang metode yang paling kuat, karena ini yang paling teruji dan telah digunakan selama beberapa dekade. Ini juga memiliki sedikit batasan dalam hal apa yang dapat ditanganinya. Dimungkinkan untuk membangun database yang tidak dapat dibuang dan dipulihkan, sebagian besar melibatkan hubungan ketergantungan objek tertentu, tetapi hal itu jarang terjadi dan biasanya melibatkan praktik yang tidak disarankan.
Masalah dengan metode dump and restore tentu saja secara efektif membutuhkan waktu henti selama operasi dump dan restore berjalan. Sementara database sumber masih dapat dibaca dan ditulis saat proses berjalan, pembaruan apa pun ke database sumber setelah dump dimulai akan hilang.
pg_upgrade meningkatkan proses pg_dump dengan memindahkan file data secara langsung tanpa harus membuangnya ke dalam bentuk tekstual logis. Perhatikan bahwa pg_upgrade masih menggunakan pg_dump secara internal untuk menyalin skema, tetapi bukan datanya. Ketika pg_upgrade masih baru, kekokohannya dipertanyakan, dan itu mengupgrade beberapa database secara tidak benar. Tapi pg_upgrade sekarang sudah cukup matang dan teruji dengan baik, jadi orang tidak perlu ragu untuk menggunakannya karena alasan itu lagi. Saat pg_upgrade berjalan, sistem database sedang down. Tetapi seseorang dapat membuat pilihan tentang berapa lama pg_upgrade berjalan. Dalam mode penyalinan default, total waktu berjalan terdiri dari waktu untuk membuang dan memulihkan skema (yang biasanya sangat cepat, kecuali ada yang memiliki ribuan tabel atau objek lain) ditambah waktu untuk menyalin file data, yang bergantung pada seberapa besar database (dan sistem I/O, sistem file, dll.).
Dalam mode tautan opsional, file data malah ditautkan ke direktori data baru, sehingga waktunya hanyalah waktu untuk melakukan operasi kernel singkat per file alih-alih menyalin setiap byte. Kekurangannya adalah jika ada yang salah dengan pemutakhiran atau Anda harus kembali ke instalasi lama, operasi ini akan menghancurkan database lama Anda. (Saya sedang mengerjakan solusi terbaik untuk PostgreSQL 12 menggunakan reflink atau operasi kloning file pada sistem file yang didukung.)
Replikasi logis adalah yang terbaru dari kelompok di sini, jadi mungkin perlu beberapa waktu untuk mengatasi kekusutan. Jika Anda tidak punya waktu untuk menjelajah dan menyelidiki, ini mungkin bukan cara yang tepat untuk dilakukan saat ini. (Tentu saja, orang-orang telah menggunakan solusi replikasi logis non-inti lainnya seperti Slony, Londiste, dan pglogical untuk memutakhirkan PostgreSQL selama bertahun-tahun, jadi ada banyak pengalaman dengan prinsip-prinsip, jika tidak dengan rinciannya.)
Keuntungan menggunakan replikasi logis untuk memutakhirkan adalah aplikasi dapat terus berjalan melawan instans lama saat sinkronisasi data berlangsung. Hanya perlu ada pemadaman kecil saat koneksi klien dialihkan. Jadi, meskipun pemutakhiran menggunakan replikasi logis mungkin lebih lambat dari awal hingga akhir daripada menggunakan pg_upgrade dalam mode salin (dan pasti lebih lambat daripada menggunakan mode tautan keras), itu tidak terlalu menjadi masalah karena waktu henti sebenarnya bisa jauh lebih singkat.
Perhatikan bahwa replikasi logis saat ini tidak mereplikasi perubahan skema. Dalam prosedur peningkatan yang diusulkan ini, skema masih disalin melalui pg_dump, tetapi perubahan skema berikutnya tidak terbawa. Memutakhirkan dengan replikasi logis juga memiliki beberapa batasan lainnya. Operasi tertentu tidak ditangkap oleh replikasi logis:objek besar, TRUNCATE, perubahan urutan. Kami akan membahas solusi untuk masalah ini nanti.
Jika Anda memiliki standby fisik (dan jika tidak, mengapa tidak?), Ada juga beberapa perbedaan yang perlu dipertimbangkan di antara metode tersebut. Dengan salah satu metode tersebut, Anda perlu membangun siaga fisik baru untuk instans yang ditingkatkan versinya. Dengan dump dan restore serta dengan replikasi logis, mereka dapat ditempatkan sebelum pemutakhiran dimulai sehingga sebagian besar siaga akan siap setelah pemulihan atau sinkronisasi awal replikasi logis selesai, tergantung pada penundaan replikasi.
Dengan pg_upgrade, standby baru harus dibuat setelah upgrade dari yang utama selesai. (Dokumentasi pg_upgrade menjelaskan hal ini secara lebih rinci.) Jika Anda mengandalkan standby fisik untuk ketersediaan tinggi, standby harus ada sebelum Anda beralih ke instance baru, sehingga pengaturan standby dapat mempengaruhi perhitungan waktu Anda secara keseluruhan.
Tapi kembali ke replikasi logis. Berikut adalah cara meningkatkan dengan replikasi logis dapat dilakukan:
0. Instance lama harus disiapkan untuk replikasi logis. Ini memerlukan beberapa pengaturan konfigurasi seperti yang dijelaskan di bawah http://www.postgresql.org/docs/10/static/logical-replication-config.html (terutama wal_level = logical . Jika ternyata Anda perlu melakukan perubahan itu, mereka akan memerlukan server restart. Jadi periksa ini dengan baik sebelumnya. Periksa juga pg_hba.conf pada instance lama diatur untuk menerima koneksi dari instance baru. (Mengubah itu hanya membutuhkan reload.)
1. Instal versi PostgreSQL baru. Anda memerlukan setidaknya paket server dan paket klien yang berisi pg_dump. Banyak kemasan sekarang memungkinkan menginstal beberapa versi berdampingan. Jika Anda menjalankan mesin virtual atau instance cloud, ada baiknya mempertimbangkan untuk menginstal instance baru di host baru.
2. Siapkan instance baru, yaitu, jalankan initdb. Instans baru dapat memiliki pengaturan yang berbeda dari yang lama, misalnya lokal, ukuran segmen WAL, atau checksumming. (Mengapa tidak menggunakan kesempatan ini untuk mengaktifkan checksum data?)
3. Sebelum Anda memulai instans baru, Anda mungkin perlu mengubah beberapa pengaturan konfigurasi. Jika instance berjalan di host yang sama dengan instance lama, Anda perlu menyetel nomor port yang berbeda. Juga, bawa semua perubahan khusus yang telah Anda buat di postgresql.conf pada instance lama Anda, seperti pengaturan memori, max_connections , dll. Demikian pula, buat pg_hba.conf pengaturan yang sesuai dengan lingkungan Anda. Anda biasanya dapat memulai dengan menyalin pg_hba.conf file dari instance lama. Jika Anda ingin menggunakan SSL, siapkan sekarang.
4. Mulai instance baru (kosong) dan periksa apakah itu berfungsi sesuai keinginan Anda. Jika Anda menyiapkan instans baru pada host baru, periksa pada titik ini apakah Anda dapat membuat koneksi database (menggunakan psql) dari host baru ke instans database lama. Kami akan membutuhkannya di langkah selanjutnya.
5. Salin definisi skema dengan pg_dumpall. (Atau Anda dapat melakukannya dengan pg_dump untuk setiap database secara terpisah, tetapi jangan lupakan objek global seperti peran.)
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
Perubahan skema apa pun setelah titik ini tidak akan dimigrasikan. Anda harus mengelolanya sendiri. Dalam banyak kasus, Anda hanya dapat menerapkan perubahan DDL pada kedua host, tetapi menjalankan perintah yang mengubah struktur tabel selama pemutakhiran mungkin merupakan tantangan yang terlalu jauh.
6. Di setiap database di instance sumber, buat publikasi yang menangkap semua tabel:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
Replikasi logis bekerja secara terpisah di setiap database, jadi ini perlu diulang di setiap database. Di sisi lain, Anda tidak perlu memutakhirkan semua database sekaligus, sehingga Anda dapat melakukan ini satu database sekaligus atau bahkan tidak mengupgrade beberapa database.
7. Di setiap database di instance target, buat langganan yang berlangganan publikasi yang baru saja dibuat. Pastikan untuk mencocokkan database sumber dan target dengan benar.
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
Atur parameter koneksi yang sesuai.
8. Sekarang Anda menunggu hingga langganan menyalin data awal dan sepenuhnya menyusul penerbit. Anda dapat memeriksa status sinkronisasi awal setiap tabel dalam langganan di katalog sistem pg_subscription_rel (cari r =siap di kolom srsubstate ). Status keseluruhan dari replikasi dapat diperiksa di pg_stat_replication di sisi pengirim dan pg_stat_subscription di sisi penerima.
9. Seperti disebutkan di atas, perubahan urutan tidak direplikasi. Salah satu solusi yang mungkin untuk ini adalah menyalin nilai urutan menggunakan pg_dump. Anda bisa mendapatkan dump dari nilai urutan saat ini menggunakan sesuatu seperti ini:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(Ini mengasumsikan bahwa semua nama urutan cocok dengan *_seq dan tidak ada tabel yang cocok dengan nama itu. Dalam kasus yang lebih rumit, Anda juga dapat menempuh rute membuat dump penuh dan mengekstrak data urutan dari daftar isi dump.)
Karena urutannya mungkin maju saat Anda melakukan ini, mungkin bungkam seq-data.sql file untuk menambahkan sedikit kelonggaran pada angka.
Kemudian pulihkan file tersebut ke database baru menggunakan psql.
10. Waktu Tayang:Beralih aplikasi ke instans baru. Ini membutuhkan beberapa pemikiran sebelumnya. Dalam skenario paling sederhana, Anda menghentikan program aplikasi Anda, mengubah pengaturan koneksi, memulai ulang. Jika Anda menggunakan proxy koneksi, Anda dapat mengalihkan koneksi di sana. Anda juga dapat mengganti aplikasi klien satu per satu, mungkin untuk menguji hal-hal sedikit atau meringankan beban pada sistem baru. Ini akan berfungsi selama aplikasi masih menunjuk ke server lama dan yang menunjuk ke server baru tidak membuat penulisan yang bertentangan. (Dalam hal ini Anda akan menjalankan sistem multimaster, setidaknya untuk waktu yang singkat, dan itu adalah urutan kerumitan lainnya.)
11. Saat pemutakhiran selesai, Anda dapat meruntuhkan pengaturan replikasi. Di setiap database pada instance baru, jalankan
DROP SUBSCRIPTION s_upgrade;
Jika Anda telah mematikan instans lama, ini akan gagal karena tidak dapat menjangkau server jauh untuk menjatuhkan slot replikasi. Lihat halaman manual DROP SUBSCRIPTION untuk mengetahui cara melanjutkan dalam situasi ini.
Anda juga dapat menghapus publikasi pada instance sumber, tetapi itu tidak perlu karena publikasi tidak menyimpan sumber daya apa pun.
12. Terakhir, hapus instance lama jika Anda tidak membutuhkannya lagi.
Beberapa komentar tambahan tentang solusi untuk hal-hal yang tidak didukung oleh replikasi logis. Jika Anda menggunakan objek besar, Anda dapat memindahkannya menggunakan pg_dump, tentu saja selama tidak berubah selama proses peningkatan. Ini adalah batasan yang signifikan, jadi jika Anda adalah pengguna berat objek besar, maka metode ini mungkin bukan untuk Anda. Jika aplikasi Anda mengeluarkan TRUNCATE selama proses peningkatan, tindakan tersebut tidak akan direplikasi. Mungkin Anda dapat men-tweak aplikasi Anda untuk mencegahnya melakukan itu pada saat peningkatan, atau Anda dapat menggantinya dengan DELETE. PostgreSQL 11 akan mendukung replikasi TRUNCATE, tetapi itu hanya akan berfungsi jika instance sumber dan tujuan adalah PostgreSQL 11 atau yang lebih baru.
Beberapa komentar penutup yang benar-benar berlaku untuk semua upaya peningkatan:
- Aplikasi dan semua program klien basis data harus diuji terhadap versi PostgreSQL utama yang baru sebelum dimasukkan ke dalam produksi.
- Untuk itu, Anda juga harus menguji prosedur peningkatan versi sebelum menjalankannya di lingkungan produksi.
- Tuliskan semuanya atau skrip yang lebih baik dan otomatiskan sebanyak mungkin.
- Pastikan penyiapan pencadangan, sistem pemantauan, serta alat dan skrip pemeliharaan apa pun disesuaikan dengan benar selama prosedur pemutakhiran. Idealnya, ini harus ada dan diverifikasi sebelum peralihan dilakukan.
Dengan mengingat hal itu, semoga berhasil dan silakan bagikan pengalaman Anda.
