Replikasi memainkan peran penting dalam menjaga ketersediaan tinggi. Server bisa gagal, sistem operasi atau perangkat lunak database mungkin perlu ditingkatkan. Ini berarti mengubah peran server dan memindahkan tautan replikasi, sambil mempertahankan konsistensi data di semua basis data. Perubahan topologi akan diperlukan, dan ada berbagai cara untuk melakukannya.
Mempromosikan Server Siaga
Bisa dibilang, ini adalah operasi paling umum yang perlu Anda lakukan. Ada beberapa alasan - misalnya, pemeliharaan basis data di server utama yang akan memengaruhi beban kerja dengan cara yang tidak dapat diterima. Mungkin ada waktu henti yang direncanakan karena beberapa operasi perangkat keras. Kerusakan server utama yang membuatnya tidak dapat diakses oleh aplikasi. Ini semua adalah alasan untuk melakukan failover, baik direncanakan atau tidak. Dalam semua kasus, Anda harus mempromosikan salah satu server siaga untuk menjadi server utama baru.
Untuk mempromosikan server siaga, Anda perlu menjalankan:
[email protected]:~$ /usr/lib/postgresql/10/bin/pg_ctl promote -D /var/lib/postgresql/10/main/
waiting for server to promote.... done
server promotedSangat mudah untuk menjalankan perintah ini, tetapi pertama-tama, pastikan untuk menghindari hilangnya data. Jika kita berbicara tentang skenario "server utama mati", Anda mungkin tidak memiliki terlalu banyak opsi. Jika ini adalah pemeliharaan terencana, maka dimungkinkan untuk mempersiapkannya. Anda perlu menghentikan lalu lintas di server utama, dan kemudian memverifikasi bahwa server siaga menerima dan menerapkan semua data. Ini dapat dilakukan di server siaga, menggunakan kueri seperti di bawah ini:
postgres=# select pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();
pg_last_wal_receive_lsn | pg_last_wal_replay_lsn
-------------------------+------------------------
1/AA2D2B08 | 1/AA2D2B08
(1 row)Setelah semuanya baik-baik saja, Anda dapat menghentikan server utama yang lama dan mempromosikan server siaga.
Unduh Whitepaper Hari Ini Pengelolaan &Otomatisasi PostgreSQL dengan ClusterControlPelajari tentang apa yang perlu Anda ketahui untuk menerapkan, memantau, mengelola, dan menskalakan PostgreSQLUnduh WhitepaperMemasang Ulang Server Siaga dari Server Utama baru
Anda mungkin memiliki lebih dari satu server siaga yang bekerja di server utama Anda. Lagi pula, server siaga berguna untuk menurunkan lalu lintas hanya baca. Setelah mempromosikan server siaga ke server utama baru, Anda perlu melakukan sesuatu tentang server siaga yang tersisa yang masih terhubung (atau yang mencoba terhubung) ke server utama lama. Sayangnya, Anda tidak bisa begitu saja mengubah recovery.conf dan menghubungkannya ke server utama yang baru. Untuk menghubungkannya, Anda harus membangunnya kembali terlebih dahulu. Ada dua metode yang dapat Anda coba di sini:pencadangan dasar standar atau pg_rewind.
Kami tidak akan membahas detail cara mengambil cadangan dasar - kami membahasnya di posting blog kami sebelumnya, yang berfokus pada pengambilan cadangan dan memulihkannya di PostgreSQL. Jika Anda menggunakan ClusterControl, Anda juga dapat menggunakannya untuk membuat cadangan dasar:
Di sisi lain, katakanlah beberapa kata tentang pg_rewind. Perbedaan utama antara kedua metode adalah bahwa pencadangan dasar membuat salinan lengkap dari kumpulan data. Jika kita berbicara tentang kumpulan data kecil, itu boleh saja tetapi untuk kumpulan data dengan ukuran ratusan gigabyte (atau bahkan lebih besar), itu bisa dengan cepat menjadi masalah. Pada akhirnya, Anda ingin memiliki server siaga dengan cepat dan berjalan - untuk membongkar server aktif Anda dan memiliki siaga lain untuk failover, jika diperlukan. Pg_rewind bekerja secara berbeda - hanya menyalin blok yang telah dimodifikasi. Alih-alih menyalin semuanya, itu hanya menyalin perubahan, mempercepat proses dengan cukup signifikan. Mari kita asumsikan master baru Anda memiliki IP 10.0.0.103. Ini adalah bagaimana Anda dapat menjalankan pg_rewind. Harap perhatikan bahwa Anda harus menghentikan server target - PostgreSQL tidak dapat berjalan di sana.
[email protected]:~$ /usr/lib/postgresql/10/bin/pg_rewind --source-server="user=myuser dbname=postgres host=10.0.0.103" --target-pgdata=/var/lib/postgresql/10/main --dry-run
servers diverged at WAL location 1/AA4F1160 on timeline 3
rewinding from last common checkpoint at 1/AA4F10F0 on timeline 3
Done!Ini akan membuat lari kering , menguji proses tetapi tidak membuat perubahan apa pun. Jika semuanya baik-baik saja, yang harus Anda lakukan adalah menjalankannya lagi, kali ini tanpa parameter '--dry-run'. Setelah selesai, langkah terakhir yang tersisa adalah membuat file recovery.conf, yang akan mengarah ke master baru. Ini mungkin terlihat seperti ini:
standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.103 port=5432 user=replication_user password=replication_password'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'Sekarang Anda siap untuk memulai server siaga Anda dan server tersebut akan mereplikasi dari server baru yang aktif.
Replikasi Berrantai
Ada banyak alasan mengapa Anda mungkin ingin membangun replikasi berantai, meskipun biasanya dilakukan untuk mengurangi beban pada server utama. Melayani WAL ke server siaga menambahkan beberapa overhead. Tidak masalah jika Anda memiliki satu atau dua siaga, tetapi jika kita berbicara tentang sejumlah besar server siaga, ini bisa menjadi masalah. Misalnya, kita dapat meminimalkan jumlah server siaga yang mereplikasi langsung dari yang aktif dengan membuat topologi seperti di bawah ini:
Perpindahan dari topologi dua server siaga ke replikasi berantai cukup mudah.
Anda perlu memodifikasi recovery.conf pada 10.0.0.103, arahkan ke 10.0.0.102 dan kemudian restart PostgreSQL.
standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.102 port=5432 user=replication_user password=replication_password'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'Setelah dimulai ulang, 10.0.0.103 akan mulai menerapkan pembaruan WAL.
Ini adalah beberapa kasus umum dari perubahan topologi. Salah satu topik yang tidak dibahas, namun tetap penting, adalah dampak dari perubahan ini pada aplikasi. Kami akan membahasnya di postingan terpisah, serta cara membuat perubahan topologi ini transparan untuk aplikasi.
