Panduan untuk PGpool - Petunjuk &Pengamatan:Bagian Tiga

Di bagian sebelumnya saya berani bermain dengan fitur yang tidak diimplementasikan, berfantasi bagaimana cara kerjanya. Yah HA di tempat pertama adalah masalah desain dan baru kemudian implementasi. Itu tidak memaafkan implementasi yang buruk, juga tidak membuat desain yang naif terlihat pintar. Namun setelah Anda membahas semua skenario yang mungkin dan menemukan aturan terbaik yang memadai untuk sebagian besar kasus, terkadang perubahan kecil yang sangat primitif dapat merusak benteng. Di bawah ini saya ingin sandbox.

Apa Yang Terjadi Saat pgpool Harus Gagal, Tapi Tidak Bisa?

Ketika pemeriksaan kesehatan gagal untuk master, failover_command dipecat untuk menurunkan semua atau mempromosikan budak berikutnya ke primer. Kedengarannya padat. Bagaimana jika gagal sendiri, misalnya koneksi ssh gagal (mis. karena lainnya - admin yang buruk menghapus kunci dari ~/.ssh/authorized_keys). Apa yang kita miliki?

Segera setelah health_check_timeout (default 20) keluar (juga dipengaruhi oleh penundaan coba lagi, maks dihentikan, dan seterusnya) node mati, jadi:

t=# select nid,port,st from dblink('host=localhost port=5433','show pool_nodes') as t (nid int,hostname text,port int,st text,lb_weight float,role text,cnt int,cur_node text,del int);
 nid | port |  st
-----+------+------
   0 | 5400 | down
   1 | 5401 | up
   2 | 5402 | up
(3 rows)

Jadi tidak ada percobaan lagi yang tersisa dan failover gagal. Opsi pertama jelas melakukan failover secara manual. Tetapi jika failover gagal karena beberapa kesalahan bodoh, master kembali ke rel, dan satu-satunya masalah yang Anda miliki adalah pgpool berpikir master sedang offline - Anda mungkin ingin meninggalkan hal-hal seperti dulu sebelum kecelakaan sebagai gantinya - kan? Tentu saja memindahkan master kembali online tidak cukup. Pgpool sudah "merosot" yang utama. Hanya menambahkannya sebagai simpul baru juga tidak akan membantu. Yang terburuk adalah, setelah acara, pgpool tidak akan mencoba memeriksa apakah master lama adalah pg_is_in_recovery() atau bukan, sehingga tidak akan pernah menerimanya sebagai Primer. Menurut bug track Anda harus "Buang file pgpool_status dan jangan mengembalikan status sebelumnya" dengan perintah pgpool -D.

Setelah membuang status, kami menyambung kembali untuk menghindari server menutup sambungan secara tidak terduga dan menjalankan:

t=# select nid,port,st,role from dblink('host=localhost port=5433','show pool_nodes') as t (nid int,hostname text,port int,st text,lb_weight float,role text,cnt int,cur_node text,del int);
 nid | port | st |  role
-----+------+----+---------
   0 | 5400 | up | primary
   1 | 5401 | up | standby
   2 | 5402 | up | standby
(3 rows)

Semua node dicadangkan dan berjalan, pgpool mengenali masternya.

Akhirnya saya ingin membahas beberapa petunjuk dan pengamatan tentang penggunaan pgpool:

Mengubah pengaturan backend sedikit rumit:nama host, port, dan direktori memerlukan pemuatan ulang untuk menambahkan node baru, tetapi memerlukan restart untuk mengedit yang sudah ada. Sementara berat dan bendera dapat diubah hanya dengan memuat ulang.

Jangan bingung nilai kolom load_balance_node dengan konfigurasi. Jika Anda hanya melihat satu simpul dengan benar, itu tidak baik-baik saja - memang demikian. Ini tidak berarti Anda hanya memiliki satu simpul dalam kumpulan penyeimbang - ini hanya menunjukkan simpul mana yang dipilih untuk sesi khusus ini. Di bawah ini adalah hasil kueri dengan ketiga node yang berpartisipasi dalam penyeimbangan pernyataan SELECT, dengan id node 2 dipilih:

t=# show pool_nodes;
 node_id | hostname  | port | status | lb_weight |  role   | select_cnt | load_balance_node | replication_delay
---------+-----------+------+--------+-----------+---------+------------+-------------------+-------------------
 0       | localhost | 5400 | up     | 0.125000  | primary | 61         | false             | 0
 1       | localhost | 5401 | up     | 0.312500  | standby | 8          | false             | 0
 2       | localhost | 5402 | up     | 0.562500  | standby | 11         | true              | 0
(3 rows)

Anda dapat memeriksa simpul mana yang dipilih untuk penyeimbangan beban dengan show pool_nodes, tetapi Anda ingin mengetahuinya untuk kueri Anda, bukan yang "tampilkan", jadi pemeriksaan semacam itu tidak selalu cukup informatif. Anda dapat memantau node mana yang Anda gunakan untuk kueri saat ini, dengan sesuatu seperti:
```
t=# select *,current_setting('port') from now();
              now              | current_setting
-------------------------------+-----------------
 2018-04-09 13:56:17.501779+01 | 5401
(1 row)
```

Penting! Tapi tidak:

t=# select now, setting from now() join pg_settings on name='port';
             now             | setting
-----------------------------+---------
 2018-04-09 13:57:17.5229+01 | 5400
(1 row)

Karena itu akan SELALU mengembalikan port master. Hal yang sama berlaku untuk pg_catalog SELECT.

Seperti yang Anda perhatikan di bagian sebelumnya, saya menggunakan cara yang lebih rumit, daripada hanya menampilkan pool_nodes untuk membuat daftar node dengan status. Saya melakukannya dengan sengaja untuk menunjukkan bagaimana Anda dapat membuat hasilnya dapat dikelola. Menggunakan where membuat kueri lebih panjang, tetapi hasilnya jelas, melewatkan semua yang mengalihkan perhatian untuk tugas khusus kita. Bandingkan:

t=# select nid,port,st,role from dblink('host=localhost port=5433','show pool_nodes') as t (nid int,hostname text,port int,st text,lb_weight float,role text,cnt int,cur_node text,del int);
 nid | port | st |  role
-----+------+----+---------
   0 | 5400 | up | primary
   1 | 5401 | up | standby
   2 | 5402 | up | standby

Dengan output dari show pool_nodes awal...

Anda tidak dapat membandingkan pgbouncer dan pgpool. Tetapi jika Anda melakukannya, yang paling penting untuk diketahui bahwa penguraian kueri di pgpool bergantung pada versi pg. Jadi saat memutakhirkan postgreSQL, Anda juga perlu memutakhirkan pgpool, sementara satu instance pgbouncer dapat memiliki konfigurasi untuk 8,9,10 klaster berbeda dalam file ini yang sama.
Mengapa saya tidak bisa menggunakan hanya skrip failover alih-alih pgpool? Kamu bisa. Tapi pgpool menawarkannya SEPANJANG dengan memcached dan koneksi pooling dan balancing dan split brain control dan diperiksa oleh penggunaan selama beberapa dekade.
Sistem Pelacakan Bug ada - layak untuk dikunjungi jika Anda bekerja dengan pgpool:https://www.pgpool.net/mantisbt/my_view_page.php
Banyak kesalahan ketik dalam dokumentasi, seperti bakance (backend + balance?..), statemnet, diizinkan atau tidak cocok di seluruh versi (pool_nodes dulu int dan sekarang enum, tetapi tautan ke nilai lama di pcp_node-info masih ada) merusak kesan pada produk yang luar biasa ini. Formulir untuk mengirim laporan tentang "bug" yang ditemukan dalam dokumentasi (seperti "kirim koreksi" pada dokumen postgres) akan sangat meningkatkannya.

Kiat penting: sebelum mengandalkan langkah apa pun - periksa. Misalnya. setelah mempromosikan node, Anda tidak dapat mempromosikannya kembali (di sini mempromosikan bukan operasi postgres, melainkan pendaftaran node sebagai master untuk pgpool):

[email protected]:~# sudo -u postgres pcp_promote_node -w -h 127.0.0.1 -U vao -n 1
pcp_promote_node -- Command Successful
[email protected]:~# sudo -u postgres pcp_promote_node -w -h 127.0.0.1 -U vao -n 1
FATAL:  invalid pgpool mode for process recovery request
DETAIL:  specified node is already primary node, can't promote node id 1

Kedengarannya logis dan tampak hebat. Namun, jika Anda menjalankan ini terhadap node yang salah (misalnya, node 0 adalah ! pg_is_in_recovery):

[email protected]:~# for i in $(seq 1 3); do pcp_promote_node -w -h 127.0.0.1 -U vao -n 0; echo $?; done
pcp_promote_node -- Command Successful
0
pcp_promote_node -- Command Successful
0
pcp_promote_node -- Command Successful
0

Yang buruk karena Anda tidak dapat mempromosikan ulang node dan mengharapkan kesalahan, tetapi Anda mendapatkan status keluar 0…

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

Kiat penting:Jangan terlalu banyak bermain. Jangan pernah bermain di prod!

Bermain dengan recovery_1st_stage_command menggunakan pg_rewind, saya berpikir untuk mencoba peretasan monyet lain karena penasaran - menanyakan pgpool_recovery() tanpa argumen (karena saya tetap mengabaikannya dalam pengaturan saya) dan kemudian hanya mencoba melampirkan simpul ke pgpool:

[email protected]:~# psql -p 5433 -h localhost template1 -c "SELECT pgpool_recovery('or_1st.sh', '', '', '')"
 pgpool_recovery
-----------------
 t
(1 row)

[email protected]:~# pcp_attach_node -h 127.0.0.1 -U vao -w -n 1
pcp_attach_node -- Command Successful

Ide bodoh ini membawa saya ke:

[email protected]:~# ps -aef | grep pgpool
postgres 15227     1  0 11:22 ?        00:00:00 pgpool -D
postgres 15240 15227  0 11:22 ?        00:00:00 pgpool: health check process(0)
postgres 15241 15227  0 11:22 ?        00:00:00 pgpool: health check process(1)
postgres 15242 15227  0 11:22 ?        00:00:00 pgpool: health check process(2)
postgres 15648 15227  0 11:24 ?        00:00:00 [pgpool] <defunct>
postgres 16264 15227  0 11:26 ?        00:00:00 pgpool: PCP: wait for connection request
postgres 16266 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>
postgres 16506 16264  0 11:26 ?        00:00:00 pgpool: PCP: processing recovery request
postgres 16560 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>
postgres 16835 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>
postgres 16836 15227  0 11:26 ?        00:00:00 [pgpool] <defunct>

Tidak ada jalan keluar saya harus:

[email protected]:~# kill -9 
[email protected]:~# rm /var/run/pgpoolql/.s.PGSQL.5433
[email protected]:~# rm /var/run/pgpoolql/.s.PGSQL.9898

Di atas 5433 adalah port pgpool dan 9898 adalah port pcp. Jelas setelah crash, file tidak tersapu, jadi Anda harus melakukannya secara manual.

Lakukan membaca dengan cermat dan banyak bermain sebelum membawa pgpool ke produksi. Jauh lebih sulit untuk menemukan bantuan dengan pgpool daripada postgres itu sendiri. Beberapa pertanyaan tidak pernah dijawab. Apalagi jika ditanya di tempat yang salah (saya menjawabnya berdasarkan tempat yang tepat untuk mendapatkan jawaban)...
Jangan lupa timeline terbaru untuk replikasi cascading (bukan petunjuk pgpool, tetapi sering kali orang tidak mengerti bahwa untuk mengambil master baru tidak cukup dengan menentukan titik akhir yang tepat untuk receiver).
Arsitektur dengan diagram dapat ditemukan di sini.

Kesimpulan

Dalam 10 tahun fitur baru yang menjanjikan (pengawas dan ip virtual) dan perbaikan penting (misalnya serialize_accept) muncul, tetapi secara keseluruhan meninggalkan kesan yang kurang dihargai. Dokumen memiliki kesalahan ketik yang telah tinggal di sana selama 10 tahun. Saya tidak percaya tidak ada yang membaca dokumen. Saya tidak percaya tidak ada yang memperhatikan. Anda tidak dapat melaporkannya dengan cara yang mudah. Ada banyak senjata yang dimuat dan disiapkan, tergeletak di situs dokumentasi untuk diambil oleh pengguna pemula, arahkan ke kaki dan tarik pelatuknya. Saya tidak tahu cara memperbaikinya - saya hanya memperingatkan para penembak. Salah menafsirkan satu parameter dapat membuat Anda berada dalam posisi putus asa dalam melakukan reverse engineering untuk menemukan kesalahan Anda. Selama ini pgpool dulu dan tetap merupakan produk untuk pengguna tingkat lanjut. Membaca dokumentasi Saya tidak bisa menahan diri untuk tidak mengingat lelucon Rusia kuno tentang Sherlock Holmes:Sherlock dan Watson terbang di atas balon. Tiba-tiba angin kencang meniup mereka ribuan mil jauhnya. Ketika mereka bisa mendarat, mereka melihat gadis itu sedang menggembalakan domba. Holmes bertanya kepada gadis itu:"Sayang di mana kita?" dan gadis itu menjawab "Kamu ada di balon!". Sherlock berterima kasih dan saat mereka lepas landas mengatakan "Angin membawa kita sangat jauh - kita berada di Rusia". “Tapi bagaimana kamu tahu?” tanya Watson. "Sudah jelas - hanya di Rusia coders menggembalakan domba" jawab Sherlock. "Tapi bagaimana kamu tahu gadis itu pembuat kode?" - “Jelas - dia memberi kami jawaban yang benar-benar tepat dan sama sekali tidak berguna”.