Kegagalan untuk Replikasi PostgreSQL 101

Bekerja di industri TI, kita mungkin sering mendengar kata "failover", tetapi juga dapat menimbulkan pertanyaan seperti:Apa sebenarnya failover itu? Untuk apa kita bisa menggunakannya? Apakah penting untuk memilikinya? Bagaimana kita bisa melakukannya?

Meskipun pertanyaan tersebut mungkin tampak pertanyaan yang cukup mendasar, penting untuk mempertimbangkannya di lingkungan basis data apa pun. Dan lebih sering daripada tidak, kita tidak memperhitungkan dasar-dasarnya...

Untuk memulai, mari kita lihat beberapa konsep dasar.

Apa itu Failover?

Failover adalah kemampuan sistem untuk terus berfungsi bahkan jika beberapa kegagalan terjadi. Ini menunjukkan bahwa fungsi sistem diasumsikan oleh komponen sekunder jika komponen utama gagal.

Dalam kasus PostgreSQL, ada berbagai alat yang memungkinkan Anda untuk mengimplementasikan cluster database yang tahan terhadap kegagalan. Salah satu mekanisme redundansi yang tersedia secara native di PostgreSQL adalah replikasi. Dan hal baru di PostgreSQL 10 adalah implementasi dari replikasi logis.

Apa itu Replikasi?

Ini adalah proses menyalin dan menjaga data diperbarui dalam satu atau lebih node database. Ini menggunakan konsep node master yang menerima modifikasi, dan node slave tempat mereka direplikasi.

Kami Memiliki Beberapa Cara Mengkategorikan Replikasi:

• Replikasi Sinkron:Tidak ada kehilangan data meskipun master node kita hilang, tetapi commit di master harus menunggu konfirmasi dari slave, yang dapat mempengaruhi kinerja.
• Replikasi Asinkron:Ada kemungkinan kehilangan data jika kita kehilangan node master kita. Jika replika karena alasan tertentu tidak diperbarui pada saat kejadian, informasi yang belum disalin dapat hilang.
• Replikasi Fisik:Blok disk disalin.
• Replikasi Logis:Aliran data berubah.
• Budak Siaga Hangat:Mereka tidak mendukung koneksi.
• Budak Siaga Panas:Mendukung koneksi hanya-baca, berguna untuk laporan atau kueri.

Untuk Apa Failover Digunakan?

Ada beberapa kemungkinan penggunaan failover. Mari kita lihat beberapa contohnya.

Migrasi

Jika kita ingin bermigrasi dari satu pusat data ke pusat data lainnya dengan meminimalkan waktu henti, kita dapat menggunakan failover.

Misalkan master kita berada di pusat data A, dan kita ingin memigrasikan sistem kita ke pusat data B.

Kita dapat membuat replika di pusat data B. Setelah disinkronkan, kita harus menghentikan sistem kita, mempromosikan replika kita ke master baru dan failover, sebelum kita mengarahkan sistem kita ke master baru di pusat data B.

Failover bukan hanya tentang database, tetapi juga aplikasi. Bagaimana mereka tahu database mana yang harus dihubungkan? Kami tentu tidak ingin harus memodifikasi aplikasi kami, karena ini hanya akan memperpanjang waktu henti kami.. Jadi, kami dapat mengkonfigurasi penyeimbang beban sehingga ketika kami menurunkan master kami, itu akan secara otomatis menunjuk ke server berikutnya yang dipromosikan.

Pilihan lainnya adalah penggunaan DNS. Dengan mempromosikan replika master di pusat data baru, kami langsung mengubah alamat IP dari nama host yang mengarah ke master. Dengan cara ini kita tidak perlu memodifikasi aplikasi kita, dan meskipun tidak dapat dilakukan secara otomatis, ini merupakan alternatif jika kita tidak ingin menerapkan penyeimbang beban.

Memiliki instance penyeimbang beban tunggal tidak bagus karena dapat menjadi satu titik kegagalan. Oleh karena itu, Anda juga dapat menerapkan failover untuk penyeimbang beban, menggunakan layanan seperti keepalive. Dengan cara ini, jika kami memiliki masalah dengan penyeimbang beban utama kami, keepalive bertanggung jawab untuk memigrasikan IP ke penyeimbang beban sekunder kami, dan semuanya terus bekerja secara transparan.

Pemeliharaan

Jika kita harus melakukan pemeliharaan pada server database master postgreSQL, kita dapat mempromosikan slave, melakukan tugas, dan merekonstruksi slave pada master lama.

Setelah ini kita dapat mempromosikan kembali master lama, dan mengulangi proses rekonstruksi dari slave, kembali ke keadaan awal.

Dengan cara ini, kami dapat bekerja di server kami, tanpa menghadapi risiko offline atau kehilangan informasi saat melakukan pemeliharaan.

Tingkatkan

Meskipun PostgreSQL 11 belum tersedia, secara teknis dimungkinkan untuk memutakhirkan dari PostgreSQL versi 10, menggunakan replikasi logis, seperti yang dapat dilakukan dengan mesin lain.

Langkah-langkahnya akan sama dengan migrasi ke pusat data baru (Lihat Bagian Migrasi), hanya saja slave kita berada di PostgreSQL 11.

Masalah

Fungsi failover yang paling penting adalah meminimalkan waktu henti atau menghindari hilangnya informasi, saat mengalami masalah dengan database utama kita.

Jika karena alasan tertentu kita kehilangan database master, kita dapat melakukan failover mempromosikan slave ke master, dan menjaga sistem kita tetap berjalan.

Untuk melakukan ini, PostgreSQL tidak memberi kami solusi otomatis apa pun. Kita dapat melakukannya secara manual, atau mengotomatiskannya dengan skrip atau alat eksternal.

Untuk mempromosikan budak kita menjadi tuan:

• Jalankan pg_ctl promo

  bash-4.2$ pg_ctl promote -D /var/lib/pgsql/10/data/
  waiting for server to promote.... done
  server promoted

• Buat file trigger_file yang harus kita tambahkan di recovery.conf dari direktori data kita.

  bash-4.2$ cat /var/lib/pgsql/10/data/recovery.conf
  standby_mode = 'on'
  primary_conninfo = 'application_name=pgsql_node_0 host=postgres1 port=5432 user=replication password=****'
  recovery_target_timeline = 'latest'
  trigger_file = '/tmp/failover.trigger'
  
  bash-4.2$ touch /tmp/failover.trigger

Untuk menerapkan strategi failover, kita perlu merencanakannya dan menguji secara menyeluruh melalui skenario kegagalan yang berbeda. Karena kegagalan dapat terjadi dengan cara yang berbeda, dan solusinya idealnya bekerja untuk sebagian besar skenario umum. Jika kita mencari cara untuk mengotomatisasi ini, kita dapat melihat apa yang ditawarkan ClusterControl.

ClusterControl untuk Kegagalan PostgreSQL

ClusterControl memiliki sejumlah fitur yang terkait dengan replikasi PostgreSQL dan failover otomatis.

Tambahkan Budak

Jika kita ingin menambahkan budak di pusat data lain, baik sebagai kontingensi atau untuk memigrasi sistem Anda, kita bisa pergi ke Cluster Actions, dan pilih Add Replication Slave.

Kita harus memasukkan beberapa data dasar, seperti IP atau nama host, direktori data (opsional), slave sinkron atau asinkron. Kita harus mengaktifkan dan menjalankan budak kita setelah beberapa detik.

Jika menggunakan pusat data lain, sebaiknya buat slave asinkron, karena jika tidak, latensi dapat sangat memengaruhi kinerja.

Pengalihan manual

Dengan ClusterControl, failover dapat dilakukan secara manual atau otomatis.

Untuk melakukan failover manual, buka ClusterControl -> Pilih Cluster -> Nodes, dan di Action Node salah satu budak kami, pilih "Promote Slave". Dengan cara ini, setelah beberapa detik, budak kita menjadi tuan, dan yang sebelumnya menjadi tuan kita, berubah menjadi budak.

Di atas berguna untuk tugas migrasi, pemeliharaan, dan peningkatan yang kita lihat sebelumnya.

Pengalihan otomatis

Dalam kasus failover otomatis, ClusterControl mendeteksi kegagalan di master dan mempromosikan slave dengan data terkini sebagai master baru. Ini juga berfungsi pada budak lainnya agar mereka meniru dari master baru.

Dengan mengaktifkan opsi "Pemulihan Otomatis", ClusterControl kami akan melakukan failover otomatis serta memberi tahu kami tentang masalahnya. Dengan cara ini, sistem kami dapat pulih dalam hitungan detik, dan tanpa campur tangan kami.

Kontrol Cluster menawarkan kepada kami kemungkinan untuk mengonfigurasi daftar putih/daftar hitam untuk menentukan bagaimana kami ingin server kami diperhitungkan (atau tidak diperhitungkan) saat memutuskan calon master.

Dari yang tersedia sesuai dengan konfigurasi di atas, ClusterControl akan memilih budak paling canggih, menggunakan untuk tujuan ini pg_current_xlog_location (PostgreSQL 9+) atau pg_current_wal_lsn (PostgreSQL 10+) tergantung pada versi database kami.

ClusterControl juga melakukan beberapa pemeriksaan atas proses failover, untuk menghindari beberapa kesalahan umum. Salah satu contohnya adalah jika kita berhasil memulihkan master lama yang gagal, itu TIDAK akan diperkenalkan kembali secara otomatis ke cluster, baik sebagai master maupun sebagai budak. Kita perlu melakukannya secara manual. Ini akan menghindari kemungkinan kehilangan data atau inkonsistensi dalam kasus bahwa budak kami (yang kami promosikan) tertunda pada saat kegagalan. Kami mungkin juga ingin menganalisis masalah secara mendetail, tetapi saat menambahkannya ke cluster kami, kami mungkin akan kehilangan informasi diagnostik.

Juga, jika failover gagal, tidak ada upaya lebih lanjut yang dilakukan, intervensi manual diperlukan untuk menganalisis masalah dan melakukan tindakan yang sesuai. Ini untuk menghindari situasi di mana ClusterControl, sebagai manajer ketersediaan tinggi, mencoba untuk mempromosikan budak berikutnya dan yang berikutnya. Mungkin ada masalah, dan kami tidak ingin memperburuk keadaan dengan mencoba beberapa kali failover.

Penyeimbang Beban

Seperti yang kami sebutkan sebelumnya, penyeimbang beban adalah alat penting untuk dipertimbangkan untuk failover kami, terutama jika kami ingin menggunakan failover otomatis dalam topologi database kami.

Agar failover menjadi transparan bagi pengguna dan aplikasi, kita memerlukan komponen di antaranya, karena tidak cukup untuk mempromosikan master ke slave. Untuk ini, kita dapat menggunakan HAProxy + Keepalive.

Apa itu HAProxy?

HAProxy adalah penyeimbang beban yang mendistribusikan lalu lintas dari satu asal ke satu atau lebih tujuan dan dapat menentukan aturan dan/atau protokol khusus untuk tugas ini. Jika salah satu tujuan berhenti merespons, itu ditandai sebagai offline, dan lalu lintas dikirim ke tujuan lain yang tersedia. Ini mencegah lalu lintas dikirim ke tujuan yang tidak dapat diakses, dan mencegah hilangnya lalu lintas ini dengan mengarahkannya ke tujuan yang valid.

Apa itu Keepalive?

Keepalive memungkinkan Anda untuk mengonfigurasi IP virtual dalam grup server aktif/pasif. IP virtual ini ditetapkan ke server "Utama" yang aktif. Jika server ini gagal, IP secara otomatis dimigrasikan ke server “Sekunder” yang ternyata pasif, memungkinkannya untuk terus bekerja dengan IP yang sama secara transparan untuk sistem kami.

Untuk mengimplementasikan solusi ini dengan ClusterControl, kami memulai seolah-olah kami akan menambahkan budak. Buka Cluster Actions dan pilih Add Load Balancer (lihat gambar ClusterControl Add Slave 1).

Kami menambahkan informasi penyeimbang beban baru kami dan bagaimana kami ingin berperilaku (Kebijakan).

Jika ingin menerapkan failover untuk penyeimbang beban kita, kita harus mengonfigurasi setidaknya dua instance.

Kemudian kita dapat mengkonfigurasi Keepalive (Pilih Cluster -> Manage -> Load Balancer -> Keepalive).

Setelah ini, kita memiliki topologi berikut:

HAProxy dikonfigurasi dengan dua port berbeda, satu baca-tulis dan satu baca-saja.

Di port baca-tulis kami, kami memiliki server master kami sebagai online dan node kami lainnya sebagai offline. Di port read-only, kami memiliki master dan slave online. Dengan cara ini kita dapat menyeimbangkan lalu lintas membaca antara node kita. Saat menulis, port baca-tulis akan digunakan, yang akan menunjuk ke master.

Ketika HAProxy mendeteksi bahwa salah satu node kami, baik master atau slave, tidak dapat diakses, secara otomatis menandainya sebagai offline. HAProxy tidak akan mengirimkan lalu lintas apa pun ke sana. Pemeriksaan ini dilakukan oleh skrip pemeriksaan kesehatan yang dikonfigurasi oleh ClusterControl pada saat penerapan. Ini memeriksa apakah instance aktif, apakah sedang menjalani pemulihan, atau hanya-baca.

Ketika ClusterControl mempromosikan budak ke master, HAProxy kami menandai master lama sebagai offline (untuk kedua port) dan menempatkan node yang dipromosikan online (di port baca-tulis). Dengan cara ini, sistem kami terus beroperasi secara normal.

Jika HAProxy aktif kami (yang diberi alamat IP Virtual yang terhubung dengan sistem kami) gagal, Keepalive memigrasikan IP ini ke HAProxy pasif kami secara otomatis. Artinya, sistem kami dapat terus berfungsi secara normal.

Kesimpulan

Seperti yang bisa kita lihat, failover adalah bagian mendasar dari basis data produksi apa pun. Ini dapat berguna saat melakukan tugas pemeliharaan umum atau migrasi. Kami berharap blog ini bermanfaat sebagai pengantar topik, sehingga Anda dapat terus meneliti dan membuat strategi failover Anda sendiri.