Biarkan saya mencoba menggambarkannya secara singkat sebelum patch ini, Anda semua tahu bahwa Standby adalah komponen penting dalam mencapai pemulihan bencana yang cepat dan aman. Di PostgreSQL, konsep pemulihan sebagian besar berkaitan dengan garis waktu untuk mengidentifikasi serangkaian segmen WAL sebelum dan sesudah PITR atau promosi Standby untuk menghindari tumpang tindih segmen WAL. ID Timeline dikaitkan dengan nama file segmen WAL (Misalnya:- Dalam $PGDATA/pg_xlog/0000000C0000000200000009E segmen "0000000C" adalah ID timeline). Dalam Replikasi Streaming, Primer dan Slave akan mengikuti ID timeline yang sama, namun ketika Standby mendapat promosi sebagai master baru oleh Switchover, ia menabrak ID timeline dan Primer lama menolak untuk memulai kembali sebagai Standby karena perbedaan ID timeline dan melemparkan pesan kesalahan sebagai:
FATAL: requested timeline 10 is not a child of this server's history
DETAIL: Latest checkpoint is at 2/9A000028 on timeline 9, but in the history of the requested timeline, the server forked off from that timeline at 2/99017E68.
Jadi, Standby baru harus dibangun dari awal, jika ukuran database besar maka waktu yang lebih lama untuk membangun kembali dan untuk periode ini Primer yang baru dipromosikan akan berjalan tanpa Standby. Ada juga masalah lain seperti, ketika Peralihan terjadi, Primer melakukan shutdown bersih, proses Walsender mengirimkan semua catatan WAL yang luar biasa ke standby tetapi tidak menunggu mereka direplikasi sebelum keluar. Walreceiver gagal menerapkan catatan WAL yang luar biasa karena mendeteksi penutupan koneksi dan keluar.
Hari ini, dengan dua pembaruan perangkat lunak utama di PostgreSQL 9.3, kedua masalah tersebut ditangani dengan sangat baik oleh penulis dan sekarang Streaming Replication Standby mengikuti peralihan garis waktu secara konsisten. Kami sekarang dapat dengan mulus dan tanpa rasa sakit mengalihkan tugas antara Utama dan Siaga hanya dengan memulai ulang dan secara signifikan mengurangi waktu pembuatan ulang Siaga.
Catatan:Switchover/Switchback tidak dapat dilakukan jika Arsip WAL tidak dapat diakses oleh kedua server dan dalam proses Switchover Database primer harus melakukan shutdown bersih (mode normal atau cepat).
Untuk demo, mari kita mulai dengan penyiapan Replikasi Streaming (wiki untuk menyiapkan SR) yang telah saya konfigurasikan di VM lokal saya antara dua cluster (5432 sebagai Primer dan 5433 sebagai Siaga) berbagi lokasi arsip WAL yang sama, karena kedua cluster harus memiliki akses lengkap urutan arsip WAL. Lihat cuplikan yang dibagikan di bawah ini dengan detail penyiapan dan ID linimasa saat ini untuk pemahaman konsep yang lebih baik.
Pada tahap ini setiap orang harus memiliki pemahaman yang kuat bahwa Switchover dan Switchback adalah kegiatan yang direncanakan. Sekarang SR setup di tempat kita dapat bertukar tugas utama dan siaga seperti gambar di bawah ini:
Langkah peralihan:
Langkah 1. Lakukan shutdown bersih dari Primary[5432] (-m fast or smart)
[postgres@localhost:/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data stop -mf
waiting for server to shut down.... done
server stopped
Langkah 2. Periksa status sinkronisasi dan status pemulihan Siaga[5433] sebelum mempromosikannya:
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c 'select pg_last_xlog_receive_location() "receive_location",
pg_last_xlog_replay_location() "replay_location",
pg_is_in_recovery() "recovery_status";'
receive_location | replay_location | recovery_status
------------------+-----------------+-----------------
2/9F000A20 | 2/9F000A20 | t
(1 row)
Siaga dalam sinkronisasi lengkap. Pada tahap ini kita aman untuk mempromosikannya sebagai Pratama.
Langkah 3. Buka Siaga sebagai Utama baru dengan pg_ctl mempromosikan atau membuat file pemicu.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ grep trigger_file data_slave/recovery.conf
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_down.txt
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
f
(1 row)
In Logs:
2014-12-29 00:16:04 PST-26344-- [host=] LOG: trigger file found: /tmp/primary_down.txt
2014-12-29 00:16:04 PST-26344-- [host=] LOG: redo done at 2/A0000028
2014-12-29 00:16:04 PST-26344-- [host=] LOG: selected new timeline ID: 14
2014-12-29 00:16:04 PST-26344-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:16:04 PST-26344-- [host=] LOG: archive recovery complete
2014-12-29 00:16:04 PST-26342-- [host=] LOG: database system is ready to accept connections
2014-12-29 00:16:04 PST-31874-- [host=] LOG: autovacuum launcher started
Siaga telah dipromosikan sebagai master dan garis waktu baru diikuti yang dapat Anda perhatikan di log.
Langkah 4. Mulai ulang Pratama lama sebagai siaga dan izinkan untuk mengikuti garis waktu baru dengan meneruskan “recovery_target_timline='latest'” di file $PGDATA/recovery.conf.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ cat data/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5433 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_131_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data start
server starting
Jika Anda membuka recovery.conf, sangat jelas bahwa Pratama lama mencoba menyambung ke port 5433 sebagai Siaga baru yang menunjuk ke lokasi Arsip WAL yang umum dan dimulai.
In Logs:
2014-12-29 00:21:17 PST-32315-- [host=] LOG: database system was shut down at 2014-12-29 00:12:23 PST
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: entering standby mode
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D00000002000000A0" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: consistent recovery state reached at 2/A0000090
2014-12-29 00:21:17 PST-32315-- [host=] LOG: record with zero length at 2/A0000090
2014-12-29 00:21:17 PST-32310-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:21:17 PST-32325-- [host=] LOG: started streaming WAL from primary at 2/A0000000 on timeline 14
Langkah 5. Verifikasi status Siaga baru.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5432 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
t
(1 row)
Keren, tanpa pengaturan ulang apa pun, kami telah mengembalikan Pratama lama sebagai Siaga baru.
Langkah beralih kembali:
Langkah 1. Lakukan shutdown bersih dari Pratama baru [5433]:
[postgres@localhost:/opt/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave stop -mf
waiting for server to shut down.... done
server stopped
Langkah 2. Periksa status sinkronisasi dari Siaga baru [5432] sebelum mempromosikan.
Langkah 3. Buka Siaga baru [5432] sebagai Utama dengan membuat file pemicu atau pg_ctl promote.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_131_down.txt
Langkah 4. Mulai ulang menghentikan Pratama baru [5433] sebagai Siaga baru.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ more data_slave/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5432 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave start
server starting
Anda dapat memverifikasi log Siaga baru.
In logs:
[postgres@localhost:/opt/PostgreSQL/9.3/data_slave/pg_log~]$ more postgresql-2014-12-29_003655.log
2014-12-29 00:36:55 PST-919-- [host=] LOG: database system was shut down at 2014-12-29 00:34:01 PST
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: entering standby mode
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E00000002000000A1" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: consistent recovery state reached at 2/A1000090
2014-12-29 00:36:55 PST-919-- [host=] LOG: record with zero length at 2/A1000090
2014-12-29 00:36:55 PST-914-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:36:55 PST-929-- [host=] LOG: started streaming WAL from primary at 2/A1000000 on timeline 15
2014-12-29 00:36:56 PST-919-- [host=] LOG: redo starts at 2/A1000090
Sangat bagus, tanpa banyak waktu kami telah mengalihkan tugas server Primer dan Siaga. Anda bahkan dapat melihat peningkatan ID timeline dari log untuk setiap promosi.
Seperti orang lain semua posting saya adalah bagian dari berbagi pengetahuan, komentar atau koreksi sangat diharapkan.
