Mengonfigurasi PostgreSQL untuk Kelangsungan Bisnis

Kesinambungan Bisnis untuk Basis Data

Kelangsungan bisnis untuk database berarti database harus terus beroperasi bahkan selama bencana. Sangat penting untuk memastikan bahwa database produksi tersedia untuk aplikasi sepanjang waktu bahkan selama bencana, jika tidak, bisa menjadi kesepakatan yang mahal. DBA, Arsitek perlu memastikan bahwa lingkungan basis data dapat mempertahankan bencana dan sesuai dengan SLA pemulihan bencana. Untuk memastikan bencana tidak mempengaruhi ketersediaan database, database harus dikonfigurasi untuk kelangsungan bisnis.

Konfigurasi database untuk kelangsungan bisnis melibatkan banyak arsitek, perencanaan, perancangan dan pengujian. Banyak faktor seperti pusat data dan wilayah geografisnya termasuk desain infrastruktur menjadi pertimbangan saat merancang dan menerapkan strategi pemulihan bencana yang efektif untuk database. Itu menjelaskan fakta bahwa “Kelangsungan Bisnis =Hindari pemadaman listrik selama bencana ”.

Untuk memastikan database produksi bertahan dari bencana, situs Disaster Recovery (DR) harus dikonfigurasi. Lokasi produksi dan DR harus menjadi bagian dari dua Pusat Data yang jauh secara geografis. Artinya, database siaga harus dikonfigurasi di situs DR untuk setiap database produksi sehingga, perubahan data yang terjadi pada database produksi segera disinkronkan ke database siaga melalui log transaksi. Ini dapat dicapai dengan kemampuan “Streaming Replication” di PostgreSQL.

Apa yang Perlu Terjadi jika Bencana Menghantam Basis Data Produksi (atau Primer)?

Ketika basis data produksi (utama) lumpuh atau menjadi tidak responsif, basis data siaga harus dipromosikan ke utama dan aplikasi harus diarahkan ke basis data siaga (utama baru) yang baru dipromosikan dan semuanya harus terjadi secara otomatis dalam SLA pemadaman yang ditentukan. Proses ini disebut sebagai failover.

Mengonfigurasi PostgreSQL untuk Ketersediaan Tinggi

Seperti disebutkan di atas, untuk memastikan bahwa PostgreSQL sesuai dengan pemulihan bencana, pertama-tama harus dikonfigurasi dengan Streaming Replication (master + database standby) dan dengan kemampuan promosi/failover standby otomatis. Mari kita lihat cara mengonfigurasi replikasi streaming terlebih dahulu dan diikuti dengan proses “failover”.

Mengonfigurasi Basis Data Siaga (Replikasi Streaming)

Replikasi streaming adalah fitur bawaan PostgreSQL yang memastikan data direplikasi dari database Primer ke Siaga melalui catatan WAL dan mendukung metode replikasi Asinkron dan Sinkron. Cara replikasi ini cukup andal dan cocok untuk lingkungan yang menuntut replikasi real-time dan berkinerja tinggi.

Mengonfigurasi streaming standby cukup sederhana. Langkah pertama adalah memastikan bahwa konfigurasi database utama adalah sebagai berikut:

Konfigurasi Wajib Basis Data Utama

Pastikan parameter berikut dikonfigurasi di postgresql.conf pada database utama. Melakukan perubahan berikut akan memerlukan restart database.

wal_level=logical

parameter wal_level memastikan bahwa informasi yang diperlukan untuk replikasi ditulis ke file WAL.

max_wal_senders=1 (or any number more than 0)

Catatan WAL dikirimkan melalui proses wal sender dari database utama ke database standby. Jadi, parameter di atas harus dikonfigurasikan ke minimum 1. Lebih dari nilai 1 diperlukan ketika beberapa pengirim wal diperlukan.

Aktifkan Pengarsipan WAL

Tidak ada ketergantungan keras pada Pengarsipan WAL untuk replikasi streaming. Namun, sangat disarankan untuk mengonfigurasi Pengarsipan WAL karena, jika siaga tertinggal dan jika file WAL yang diperlukan dihapus dari direktori pg_xlog (atau pg_wal), maka, file Arsip akan diperlukan untuk menyinkronkan siaga dengan yang utama jika tidak, standby harus dibangun kembali dari awal.

archive_mode=on
archive_command=<archive location>

Basis data utama harus dikonfigurasi untuk menerima koneksi dari standby.

Konfigurasi di bawah ini harus ada di pg_hba.conf

host    replication     postgres        <standby-database-host-ip>/32            trust

Sekarang, ambil cadangan dari database utama dan pulihkan yang sama di situs DR. Setelah selesai dengan pemulihan, buat file recovery.conf di direktori data dengan konten di bawah ini:

standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’

Sekarang, mulai database siaga. Replikasi streaming harus diaktifkan. Pesan di bawah ini dalam file log postgresql dari database siaga mengonfirmasi bahwa replikasi streaming berhasil bekerja:

2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG:  started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG:  redo starts at 127/CD380170

Itu menyimpulkan bahwa replikasi streaming yang berfungsi penuh telah tersedia. Langkah selanjutnya untuk menginstal/mengkonfigurasi repmgr. Sebelum itu, mari kita pahami proses failover.

Unduh Whitepaper Hari Ini Pengelolaan &Otomatisasi PostgreSQL dengan ClusterControlPelajari tentang apa yang perlu Anda ketahui untuk menerapkan, memantau, mengelola, dan menskalakan PostgreSQLUnduh Whitepaper

Apa itu Failover?

Failover terjadi ketika database utama menjadi benar-benar tidak tersedia karena bencana. Selama proses failover, database Standby akan dipromosikan menjadi database utama baru sehingga aplikasi dapat melanjutkan operasi bisnis.

Kegagalan Otomatis

Seluruh proses failover harus terjadi secara otomatis untuk memastikan kelangsungan bisnis yang efektif dan ini hanya dapat dicapai dengan beberapa alat middleware. Seluruh idenya adalah untuk menghindari intervensi manual dari DBA, Pengembang.

Salah satu alat yang membantu melakukan failover otomatis adalah “repmgr”.

Mari kita lihat repmgr dan kemampuannya.

Repmgr

Repmgr adalah alat opensource yang dikembangkan oleh 2nd Quadrant. Alat ini membantu melakukan berbagai aktivitas administrasi basis data seperti membangun dan memantau replikasi PostgreSQL termasuk melakukan aktivitas failover otomatis jika terjadi bencana dan juga membantu melakukan operasi peralihan.

Repmgr adalah alat yang mudah dipasang dan konfigurasinya juga tidak rumit. Mari kita lihat instalasinya terlebih dahulu:

Menginstal repmgr

Unduh alat dari sini.

Buka tarball dan lakukan instalasi seperti gambar di bawah ini:

Saya telah menginstal repmgr-4.2.0 pada host CentOS 7 dan saya telah menginstal repmgr terhadap PostgreSQL-11.1.Sebelum instalasi, pastikan direktori bin PostgreSQL adalah bagian dari $PATH dan direktori lib PostgreSQL adalah bagian dari $LD_LIBRARY_PATH. Untuk memahami bahwa repmgr diinstal pada PostgreSQL-11.1, saya menampilkan output "make install" di bawah ini:

[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755  repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql  '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'

Mengonfigurasi repmgr untuk Automatic Failover

Sebelum melihat konfigurasi “repmgr”, database harus dikonfigurasi dengan replikasi streaming yang telah kita lihat sebelumnya. Untuk memulainya, kedua database (primer dan standby) harus dikonfigurasi dengan parameter berikut di postgresql.conf:

Primary

[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Standby

[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Parameter di atas adalah untuk mengaktifkan daemon “repmgrd” yang terus berjalan di latar belakang dan memantau replikasi streaming. Tanpa parameter ini, tidak mungkin melakukan failover otomatis. Mengubah parameter ini akan memerlukan restart database.
Selanjutnya, buat file konfigurasi repmgr (misalnya dengan nama repmgr.conf) untuk kedua database. Basis data primer harus memiliki file konfigurasi dengan konten berikut:

node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

Tempatkan file di direktori data, dalam hal ini adalah “/data/pgdata11”.

File konfigurasi database siaga harus memiliki konten berikut:

node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'

failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'

monitoring_history=yes
monitor_interval_secs=5

log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG

promote_check_timeout=5
promote_check_interval=1

master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10

Kedua database tersebut harus terdaftar di repmgr.
Daftar database Primer

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered

Daftarkan Basis Data Siaga

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registered

Jalankan perintah di bawah ini untuk memastikan logging repmgr berfungsi.

[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"

Jika Anda dapat mengamati, saya telah mengonfigurasi log_level ke DEBUG untuk menghasilkan logging terperinci di file repmgr.conf standby. Periksa log untuk status replikasi.
Periksa apakah replikasi berfungsi seperti yang diharapkan menggunakan repmgr:

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2

Pesan di atas mengonfirmasi bahwa replikasi berjalan dengan baik.

Sekarang, jika saya mematikan database utama, daemon repmgrd akan mendeteksi kegagalan database utama dan harus mempromosikan database siaga. Mari kita lihat apakah itu terjadi -Database utama dihentikan:

[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

Basis data siaga harus dipromosikan secara otomatis. Log repmgr akan menunjukkan hal yang sama:

fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name     FROM repmgr.nodes n    WHERE n.upstream_node_id = 1      AND n.node_id != 2      AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name   FROM repmgr.nodes n  WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
  "repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl  -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary

Di atas persis berarti, repmgr tidak dapat terhubung ke database utama dan setelah 5 kali gagal, standby dipromosikan ke database utama baru. Di bawah ini adalah tampilan log database siaga (utama baru) yang dipromosikan:


2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL:  could not connect to the primary server: could not connect to server: Connection refused
                Is the server running on host "xxx.xxx.xx.xx" and accepting
                TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG:  received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG:  redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG:  last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG:  selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG:  archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG:  checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG:  database system is ready to accept connections

Saya hanya menyebutkan parameter penting dalam file konfigurasi repmgr. Ada banyak parameter lain yang dapat dimodifikasi untuk memenuhi berbagai persyaratan. Parameter penting lainnya adalah parameter replica_lag_* seperti yang ditunjukkan di bawah ini:

#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

Repmgr akan memeriksa ambang parameter di atas sebelum mempromosikan standby. Jika jeda replikasi sangat penting, promosi tidak akan dilanjutkan. Itu bagus banget karena kalau standby dipromosiin kalau ada lag akan mengakibatkan data loss.

Aplikasi harus memastikan mereka terhubung kembali ke standby yang baru dipromosikan dengan sukses dalam jangka waktu yang diharapkan. Penyeimbang beban akan memiliki kemampuan untuk mengalihkan koneksi aplikasi saat database utama menjadi tidak responsif. Alternatif lainnya adalah menggunakan alat middleware seperti PgPool-II untuk memastikan semua koneksi berhasil dialihkan.

Untuk memastikan arsitektur ketersediaan tinggi yang berhasil diterapkan dalam produksi, pengujian menyeluruh menyeluruh dari proses lengkap harus dilakukan. Dalam pengalaman saya, kami biasa menyebut latihan ini sebagai DR DRILL. Artinya, setiap 6 bulan atau lebih, operasi peralihan akan dilakukan untuk memastikan standby berhasil dipromosikan dan koneksi aplikasi terhubung kembali ke standby yang dipromosikan dengan sukses. Primer yang ada akan menjadi standby baru. Setelah operasi peralihan berhasil, metrik diturunkan untuk melihat SLA terpenuhi.

Apa itu Peralihan?

Seperti dijelaskan di atas, Switchover adalah kegiatan terencana dimana peran database Primer dan Siaga dialihkan. Artinya, Standby akan menjadi primer dan primer akan menjadi standby. Menggunakan repmgr, ini dapat dicapai. Di bawah ini adalah apa yang repmgr lakukan ketika perintah peralihan dikeluarkan.

$ repmgr -f /etc/repmgr.conf standby switchover
    NOTICE: executing switchover on node "node2" (ID: 2)
    INFO: searching for primary node
    INFO: checking if node 1 is primary
    INFO: current primary node is 1
    INFO: SSH connection to host "node1" succeeded
    INFO: archive mode is "off"
    INFO: replication lag on this standby is 0 seconds
    NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
    NOTICE: stopping current primary node "node1" (ID: 1)
    NOTICE: issuing CHECKPOINT
    DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
    INFO: checking primary status; 1 of 6 attempts
    NOTICE: current primary has been cleanly shut down at location 0/0501460
    NOTICE: promoting standby to primary
    DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
    server promoting
    NOTICE: STANDBY PROMOTE successful
    DETAIL: server "node2" (ID: 2) was successfully promoted to primary
    INFO: setting node 1's primary to node 2
    NOTICE: starting server using  "pg_ctl -D '/data/pgdata11' restart"
    NOTICE: NODE REJOIN successful
    DETAIL: node 1 is now attached to node 2
    NOTICE: switchover was successful
    DETAIL: node "node2" is now primary
    NOTICE: STANDBY SWITCHOVER is complete

Apa Lagi yang Dapat Dilakukan repmgr?

Repmgr dapat membantu membangun database siaga dari awal
Beberapa database siaga dapat dibangun dengan satu master berjalan
Cascading standby dapat dibangun yang menurut saya lebih bermanfaat daripada mengonfigurasi beberapa standby ke satu database master

Bagaimana jika Primer dan Siaga Hilang?

Nah, ini adalah situasi di mana bisnis berpikir tentang memiliki beberapa instans siaga. Jika semuanya hilang, maka, satu-satunya jalan keluar adalah mengembalikan database dari cadangan. Inilah alasan mengapa strategi cadangan yang baik sangat penting. Cadangan harus diuji-dipulihkan, divalidasi secara teratur untuk memastikan cadangan dapat diandalkan. Desain infrastruktur untuk backup harus sedemikian rupa sehingga pemulihan dan pemulihan backup tidak memakan waktu lama. Proses pemulihan dan pemulihan cadangan harus diselesaikan dalam SLA yang ditentukan. SLA untuk pencadangan dirancang berdasarkan RTO (Tujuan Waktu Pemulihan) dan RPO (Tujuan Titik Pemulihan). Artinya, RTO:waktu yang dibutuhkan untuk memulihkan dan memulihkan cadangan harus dalam SLA dan RPO:sampai titik waktu pemulihan yang dilakukan harus dapat diterima, dengan kata lain itu adalah toleransi kehilangan data dan umumnya bisnis mengatakan 0 kehilangan data toleransi.

Kesimpulan

Kesinambungan bisnis untuk PostgreSQL merupakan persyaratan penting untuk lingkungan basis data yang sangat penting. Untuk mencapainya membutuhkan banyak perencanaan dan biaya.
Sumber daya dan Infrastruktur harus dimanfaatkan secara optimal untuk memastikan tersedianya strategi pemulihan bencana yang efisien.
Mungkin ada tantangan dari segi biaya yang perlu diperhatikan
Jika anggaran memungkinkan, pastikan ada beberapa situs DR yang akan di-failover
Jika cadangan akan dipulihkan, pastikan strategi pencadangan yang baik sudah diterapkan.