Replikasi streaming asli di PostgreSQL hanya berfungsi antara server dengan versi utama yang sama. Kami berbicara tentang replikasi logis di posting sebelumnya . Kami melihat bagaimana replikasi logis membantu memindahkan data dari satu versi PostgreSQL ke versi lain. Tetapi replikasi logis hanya cocok untuk versi PostgreSQL yang didukung, misalnya, PostgreSQL 9.4 dan PostgreSQL 11. Apa yang harus dilakukan dengan versi sebelum 9.4? Gunakan Slony-I .
Gunakan replikasi dengan Slony-I untuk mentransfer data dari database lama ke versi terbaru PostgreSQL. Apa itu Slony dan bagaimana cara kerjanya?
Ini adalah pos keempat dalam seri kami. Peningkatan atau migrasi versi PostgreSQL lama ke yang baru , di mana kami mempelajari berbagai metode untuk memperbarui basis data PostgreSQL.
Slony
Slony adalah implementasi replikasi logis tingkat aplikasi untuk PostgreSQL. Atau lebih tepatnya, itu adalah alat replikasi pihak ketiga yang membutuhkan instalasi dan konfigurasi terpisah. Slony sudah ada sejak lama. Versi terbaru mendukung PostgreSQL dari 8.4 hingga 11.
Tujuan utama replikasi adalah untuk mentransfer perubahan dari satu server database ke yang lain. Untuk lebih memahami arsitekturnya, mari kita lihat istilah-istilahnya: Slon, events, dan slonik.
Ngomong-ngomong, Slony, jika Anda belum bisa menebak, ini adalah "gajah". Dan mereka benar-benar memiliki ingatan yang hebat. Bukan kebetulan bahwa gajah yang ketat tapi imut memamerkan logo PostgreSQL.
Slon
Slon adalah daemon yang berjalan pada setiap node PostgreSQL di replikasi Slony-I. Daemon ini digunakan untuk menangani peristiwa konfigurasi dan replikasi untuk setiap server PostgreSQL. Setiap server PostgreSQL disebut host. Semua node bersama-sama membentuk cluster Slony.
Node penerbit adalah sumber perubahan, dan node pelanggan menerima dan menerapkan perubahan dari penerbit.
Untuk mengkonfigurasi replikasi, Anda harus menentukan semua tabel yang direplikasi, atau satu set replikasi. Berlangganan berfungsi untuk set tertentu. Perubahan pada tabel yang direplikasi digabungkan menjadi SYNC, sekelompok transaksi yang diterapkan bersama pada pelanggan.
Acara
Perubahan dilaporkan dari penerbit sebagai acara. Ketika suatu acara diproses oleh Slon daemon pada host jarak jauh, sebuah pemberitahuan dihasilkan. Dan peristiwa memberi tahu node perubahan konfigurasi, seperti menambah atau menghapus node baru, langganan baru, atau perubahan DDL.
Setiap peristiwa memiliki pengidentifikasi sumber unik, nomor seri, pengidentifikasi transaksi untuk snapshot pada simpul acara, beberapa argumen dan cap waktu dengan zona waktu.
Pemicu yang ditulis untuk PL / pgSQL mencatat semua perubahan pada tabel yang direplikasi. Sayangnya, tidak ada cara yang dapat diandalkan untuk menangani perubahan pada blob, DDL, atau perubahan pada pengguna dan peran.
slonik
Ini adalah utilitas baris perintah dengan penganalisis dan juru bahasa yang menerima skrip slonik - bahasa deklaratif sederhana. Ini dirancang untuk mengatasi keterbatasan bahasa prosedural. Dengan bantuan perintah slonik, Anda dapat mengonfigurasi atau memodifikasi replikasi di Slony, dan mereka dapat disematkan dalam skrip shell. Ia menerima perintah dari input standar atau dari file. Contoh di bawah ini menunjukkan bagaimana skrip slonik diteruskan ke slonik dan tertanam dalam skrip shell.
Skrip yang membuat konfigurasi awal untuk skema master-slave sederhana dalam database pgbench kami terlihat seperti ini:
#!/bin/sh slonik <<_EOF_ cluster name = percona_pg; node 1 admin conninfo = 'dbname=pg93 host=pg93_host user=percona_pg93_user'; node 2 admin conninfo = 'dbname=pg11 host=pg11_host user=percona_pg11_user'; #-- # Creates a _$(clustername), this example, _percona_pg schema #-- init cluster ( id=1, comment = 'Legacy PG Node'); #-- # Add a list of tables being replicated to a set. #-- create set (id=1, origin=1, comment='pgbench'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.pgbench_accounts', comment='accounts'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.pgbench_branches', comment='branches'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.pgbench_tellers', comment='tellers'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.pgbench_history', comment='history'); #-- # Create the second node (the slave) tell the 2 nodes how to connect to # each other and how they should listen for events. #-- store node (id=2, comment = 'Target node', event node=1); store path (server = 1, client = 2, conninfo='dbname=pg93 host=pg93_host user=percona_pg93_user'); store path (server = 2, client = 1, conninfo='dbname=pg11 host=pg11_host user=percona_pg11_user'); _EOF_
Mengapa Slony nyaman untuk migrasi?
Terlepas dari keuntungan dari replikasi logis internal, untuk versi sebelum PostgreSQL 9.4, Anda harus menggunakan solusi pihak ketiga ini. Pendekatan berbasis pemicu tergantung pada API basis data - kedua versi harus kompatibel untuk menggunakan sintaks PL / pgSQL dan SQL.
Bagaimana cara mengadaptasi basis data untuk digunakan dengan Slony?
- Tabel harus memiliki kunci utama. Tambahkan bidang serial ke semua tabel tanpa kunci utama.
- Perubahan pada gumpalan OID tidak direplikasi. Jika Anda memiliki kolom dengan nilai pendek, konversikan ke BYTEA. Jika objek sangat besar - misalnya, gambar - lebih baik menyimpan data dalam penyimpanan eksternal (katakanlah, S3 di cloud Amazon). Jika mengubah aplikasi terlalu rumit, terapkan perubahan gumpalan di langkah terakhir migrasi.
- ALTER TABLE dan operasi DDL lainnya. Slony tidak mendeteksi perubahan struktur tabel. Gunakan perintah slonik EXECUTE SCRIPT untuk menerapkan file SQL dengan string SQL atau DDL ke seluruh cluster replikasi.
Migrasi online dari versi PostgreSQL sebelumnya
- Buat pengguna replikasi dengan hak superuser. Anda dapat mengkonfigurasi hak secara detail, tetapi jauh lebih rumit.
- Buat database di tujuan dengan akses TCP / IP.
- Salin definisi tabel dari master ke slave.
- Instal Slony-I. Pada server dengan versi OS yang lama, akan lebih mudah untuk menginstal Slony-I dari kode sumber.
- Tentukan cluster, set tabel, dan informasi koneksi node sebagai daftar perintah slonik.
- Jalankan daemon slon pada setiap server PostgreSQL. Periksa output standar atau file log untuk kesalahan koneksi.
- Jalankan perintah berlangganan slonik untuk memulai sinkronisasi.
- Uji permintaan hanya baca di Postgres versi baru.
- Ketika semua data direplikasi dan disinkronkan, hentikan aplikasi dan arahkan ke server Postgres baru.
- Gunakan node uninstall di versi baru PostgreSQL untuk menghapus semua jejak replikasi Slony.
Transisi ke versi sebelumnya
Gunakan prosedur yang sama untuk meningkatkan ke versi sebelumnya. Dengan Slony, Anda dapat mereplikasi dari versi apa pun dan ke versi PosgreSQL apa pun yang didukung oleh versi Slony. Versi minimum yang didukung adalah 8.4.
Ringkasan
Kami melihat secara umum bagaimana Anda dapat meningkatkan ke versi baru dengan downtime minimal menggunakan Slony. Cari tahu lebih lanjut di webinar kami.