Panduan Pakar untuk Replikasi Slony untuk PostgreSQL

Apa itu Slony?

Slony-I (disebut hanya sebagai 'Slony' mulai sekarang) adalah sistem replikasi pihak ketiga untuk PostgreSQL yang berasal dari sebelum versi 8.0, menjadikannya salah satu opsi lama untuk replikasi yang tersedia. Ini beroperasi sebagai metode replikasi berbasis pemicu yang merupakan solusi 'master ke banyak budak'.

Slony beroperasi dengan memasang pemicu pada setiap tabel untuk direplikasi, pada master dan slave, dan setiap kali tabel mendapat INSERT, UPDATE, atau DELETE, ia mencatat record mana yang diubah, dan apa perubahannya. Proses luar, yang disebut 'slon daemons', terhubung ke database seperti klien lain dan mengambil perubahan dari master, lalu memutar ulang pada semua node slave yang berlangganan master. Dalam penyiapan replikasi yang berkinerja baik, asinkron this ini replikasi dapat diperkirakan akan tertinggal 1 hingga 20 detik di belakang master.

Saat tulisan ini dibuat, versi terbaru Slony ada di versi 2.2.6, dan mendukung PostgreSQL 8.3 ke atas. Dukungan berlanjut hingga hari ini dengan pembaruan kecil, namun jika versi PostgreSQL yang akan datang mengubah fungsionalitas dasar transaksi, fungsi, pemicu, atau fitur inti lainnya, proyek Slony dapat memutuskan untuk menghentikan pembaruan besar untuk mendukung pendekatan baru yang drastis tersebut.

Maskot PostgreSQL adalah seekor gajah yang dikenal sebagai 'Slonik', yang merupakan bahasa Rusia untuk 'gajah kecil'. Karena proyek replikasi ini adalah tentang banyak database PostgreSQL yang saling mereplikasi, kata Rusia untuk gajah (jamak) digunakan:Slony.

Konsep

• Cluster:Instance replikasi Slony.
• Node:Database PostgreSQL spesifik sebagai node replikasi Slony, yang beroperasi sebagai master atau slave untuk kumpulan replikasi.
• Set Replikasi:Sekelompok tabel dan / atau urutan yang akan direplikasi.
• Pelanggan:Pelanggan adalah node yang berlangganan kumpulan replikasi, dan menerima kejadian replikasi untuk semua tabel dan urutan dalam kumpulan tersebut dari node master.
• Daemon Slony:Pekerja utama yang menjalankan replikasi, daemon Slony dimulai untuk setiap node dalam kumpulan replikasi dan membuat berbagai koneksi ke node yang dikelolanya, serta node master.

Cara Penggunaannya

Slony diinstal baik oleh sumber atau melalui repositori PGDG (PostgreSQL Global Development Group) yang tersedia untuk distribusi linux berbasis Red Hat dan Debian. Binari ini harus diinstal pada semua host yang akan berisi node master atau slave dalam sistem replikasi.

Setelah instalasi, cluster replikasi Slony diatur dengan mengeluarkan beberapa perintah menggunakan biner 'slonik'. 'slonik' adalah perintah dengan sintaksisnya sendiri yang sederhana namun unik untuk menginisialisasi dan memelihara cluster slony. Ini adalah antarmuka utama untuk mengeluarkan perintah ke cluster Slony yang sedang berjalan yang bertanggung jawab atas replikasi.

Antarmuka dengan Slony dapat dilakukan dengan menulis perintah slonik khusus, atau mengompilasi slony dengan flag --with-perltools, yang menyediakan skrip 'altperl' yang membantu menghasilkan skrip slonik yang diperlukan.

Membuat Cluster Replikasi Slony

Sebuah 'Cluster Replikasi' adalah kumpulan database yang merupakan bagian dari replikasi. Saat membuat kluster replikasi, skrip init perlu ditulis yang mendefinisikan berikut ini:

• Nama cluster Slony yang diinginkan
• Informasi koneksi untuk setiap node bagian dari replikasi, masing-masing dengan nomor node yang tidak dapat diubah.
• Mencantumkan semua tabel dan urutan yang akan direplikasi sebagai bagian dari 'set replikasi'.

Contoh skrip dapat ditemukan di dokumentasi resmi Slony.

Saat dijalankan, slonik akan terhubung ke semua node yang ditentukan dan membuat skema Slony pada masing-masing node. Ketika daemon Slony dimulai, mereka kemudian akan menghapus semua data dalam tabel yang direplikasi pada slave (jika ada), dan menyalin semua data dari master ke slave. Sejak saat itu, daemon akan terus mereplikasi perubahan yang direkam pada master ke semua slave yang berlangganan.

Konfigurasi Pintar

Sementara Slony pada awalnya adalah sistem replikasi Master-to-Multiple-Slave, dan sebagian besar telah digunakan dengan cara itu, ada beberapa fitur lain dan penggunaan cerdas yang membuat Slony lebih berguna daripada solusi replikasi sederhana. Sifat Slony yang sangat dapat disesuaikan membuatnya tetap relevan untuk berbagai situasi bagi administrator yang dapat berpikir di luar kebiasaan.

Replikasi Berjenjang

Node slony dapat diatur untuk melakukan replikasi kaskade ke bawah rantai node yang berbeda. Jika node master diketahui mengambil beban yang sangat berat, setiap slave tambahan akan meningkatkan beban itu sedikit. Dengan replikasi berjenjang, satu node slave yang terhubung ke master dapat dikonfigurasi sebagai 'node penerusan', yang kemudian akan bertanggung jawab untuk mengirimkan peristiwa replikasi ke lebih banyak slave, dengan menjaga beban pada node master seminimal mungkin.

Pemrosesan Data pada Node Budak

Tidak seperti replikasi bawaan PostgreSQL, node slave sebenarnya tidak 'hanya baca', hanya tabel yang sedang direplikasi yang dikunci sebagai 'hanya baca'. Ini berarti pada node slave, pemrosesan data dapat dilakukan dengan membuat tabel baru bukan bagian dari replikasi untuk menampung data yang diproses. Tabel bagian dari replikasi juga dapat memiliki indeks khusus yang dibuat tergantung pada pola akses yang mungkin berbeda dari slave dan master.

Tabel hanya baca pada slave masih dapat memiliki fungsi berbasis pemicu khusus yang dijalankan pada perubahan data, memungkinkan lebih banyak penyesuaian dengan data.

Upgrade Waktu Henti Minimal

Memutakhirkan versi utama PostgreSQL bisa sangat memakan waktu. Bergantung pada ukuran data dan jumlah tabel, pemutakhiran termasuk proses 'menganalisis' pasca pemutakhiran dapat memakan waktu bahkan beberapa hari. Karena Slony dapat mereplikasi data antara cluster PostgreSQL dari versi yang berbeda, Slony dapat digunakan untuk mengatur replikasi antara versi yang lebih lama sebagai master dan versi yang lebih baru sebagai slave. Ketika upgrade akan terjadi, cukup lakukan 'switchover', menjadikan slave sebagai master baru, dan master lama menjadi slave. Saat pemutakhiran ditandai sebagai sukses, nonaktifkan kluster replikasi Slony dan matikan database lama.

Ketersediaan Tinggi Dengan Pemeliharaan Server yang Sering

Seperti downtime minimal untuk upgrade, maintenance server dapat dilakukan dengan mudah tanpa downtime dengan melakukan 'switchover' antara dua atau lebih node, memungkinkan slave untuk di-reboot dengan update/maintenance lainnya. Ketika budak kembali online, itu akan terhubung kembali ke cluster replikasi dan mengejar semua data yang direplikasi. Pengguna akhir yang terhubung ke database mungkin mengalami gangguan transaksi yang lama, tetapi waktu henti itu sendiri akan menjadi beberapa detik saat peralihan terjadi, daripada berapa lama waktu yang dibutuhkan untuk mem-boot ulang / memperbarui host.

Pengiriman Log

Meskipun tidak mungkin menjadi solusi populer, budak Slony dapat diatur sebagai simpul 'pengiriman log', di mana semua data yang diterimanya melalui replikasi dapat ditulis ke file SQL, dan dikirimkan. Ini dapat digunakan untuk berbagai alasan, seperti menulis ke drive eksternal dan memindahkan ke database slave secara manual, dan tidak melalui jaringan, dikompresi dan disimpan di arsip untuk cadangan di masa mendatang, atau bahkan memiliki program eksternal yang mengurai file SQL dan ubah isinya.

Berbagi beberapa data basis data

Karena sejumlah tabel dapat direplikasi sesuka hati, kumpulan replikasi Slony dapat diatur untuk berbagi tabel tertentu antar database. Meskipun akses serupa dapat dicapai melalui Pembungkus Data Asing (yang telah ditingkatkan dalam rilis PostgreSQL baru-baru ini), ini mungkin merupakan solusi yang lebih baik untuk menggunakan Slony tergantung pada penggunaannya. Jika sejumlah besar data diperlukan untuk diambil dari satu host ke host lain, Slony mereplikasi data tersebut berarti data yang dibutuhkan sudah ada di node yang meminta, sehingga menghilangkan waktu transfer yang lama.

Replikasi Tertunda

Biasanya replikasi diinginkan secepat mungkin, tetapi mungkin ada beberapa skenario di mana penundaan diinginkan. Daemon slon untuk node slave dapat dikonfigurasi dengan lag_interval, artinya ia tidak akan menerima data replikasi apa pun hingga data tersebut lama seperti yang ditentukan. Ini dapat berguna untuk akses cepat ke data yang hilang jika terjadi kesalahan, misalnya jika sebuah baris dihapus, maka akan ada di slave selama 1 jam untuk pengambilan cepat.

Yang Perlu Diketahui:

• Setiap perubahan DDL pada tabel yang merupakan bagian dari replikasi harus dijalankan menggunakan perintah eksekusi slonik.
• Setiap tabel yang akan direplikasi harus memiliki kunci utama, atau indeks UNIK tanpa kolom yang dapat dibatalkan.
• Data yang direplikasi dari node master direplikasi setelah data apa pun mungkin dibuat secara fungsional. Artinya jika data dibuat menggunakan sesuatu seperti 'random()', nomor yang dihasilkan disimpan dan direplikasi pada slave, daripada 'random()' dijalankan lagi pada slave yang mengembalikan hasil yang berbeda.
• Menambahkan replikasi Slony akan sedikit meningkatkan beban server. Meskipun ditulis secara efisien, setiap tabel akan memiliki pemicu yang mencatat setiap INSERT, UPDATE, dan DELETE ke tabel Slony, mengharapkan peningkatan beban server sekitar 2-10%, bergantung pada ukuran database dan beban kerja.

Kiat dan Trik:

• Daemon slony dapat berjalan di host mana pun yang memiliki akses ke semua host lain, namun konfigurasi dengan performa tertinggi adalah menjalankan daemon pada node yang mereka kelola. Misalnya, daemon master berjalan pada node master, daemon slave berjalan pada node slave.
• Jika menyiapkan kluster replikasi dengan jumlah data yang sangat besar, penyalinan awal dapat memakan waktu cukup lama, artinya semua perubahan yang terjadi dari awal hingga penyalinan selesai dapat berarti lebih lama lagi untuk menyusul dan sinkron . Ini dapat diselesaikan dengan menambahkan beberapa tabel sekaligus untuk replikasi (sangat memakan waktu), atau dengan membuat salinan direktori data dari database master ke slave, kemudian melakukan 'set berlangganan' dengan opsi OMIT COPY disetel ke BENAR. Dengan opsi ini, Slony akan menganggap bahwa tabel slave 100% identik dengan master, dan tidak menghapusnya dan menyalin data.
• Skenario terbaik untuk ini adalah membuat Hot Standby menggunakan alat bawaan untuk PostgreSQL , dan selama jendela pemeliharaan dengan koneksi nol memodifikasi data, menjadikan siaga online sebagai master, memvalidasi kecocokan data di antara keduanya, memulai cluster replikasi slony dengan OMIT COPY =true, dan akhirnya mengaktifkan kembali koneksi klien. Mungkin perlu waktu untuk melakukan penyiapan untuk Hot Standby, tetapi prosesnya tidak akan menimbulkan dampak negatif yang besar bagi klien.

Komunitas dan Dokumentasi

Komunitas untuk Slony dapat ditemukan di milis, yang terletak di http://lists.slony.info/mailman/listinfo/slony1-general, yang juga mencakup arsip.

Dokumentasi tersedia di situs web resmi, http://slony.info/documentation/, dan memberikan bantuan dengan analisis log, dan spesifikasi sintaks untuk berinteraksi dengan slony.