Rumah  >  Artikel  >  Tutorial sistem  >  DBA menemui masalah baharu dengan PostgreSQL

DBA menemui masalah baharu dengan PostgreSQL

WBOY
WBOYke hadapan
2024-01-13 09:06:11807semak imbas

DBA menemui masalah baharu dengan PostgreSQL

Seperti biasa, pengguna yang menaik taraf atau memulakan kluster baharu akan melihat prestasi yang lebih baik (cth., imbasan indeks selari yang lebih baik, gabungan gabungan dan subkueri yang tidak berkaitan, pengagregatan lebih pantas, gabungan lebih pintar pada pelayan jauh) dan pengagregatan), ini semua berfungsi di luar kotak , tetapi dalam artikel ini saya ingin bercakap tentang sesuatu yang tidak berfungsi di luar kotak dan sebenarnya memerlukan anda mengambil beberapa langkah untuk mendapat manfaat daripadanya. Ciri yang diserlahkan di bawah disusun daripada perspektif DBA dan tidak lama lagi akan ada artikel yang merangkumi perubahan daripada perspektif pembangun.

Naik Taraf Nota

Mula-mula beberapa petua untuk menaik taraf daripada persediaan sedia ada - terdapat beberapa perkara kecil yang boleh menyebabkan masalah apabila berhijrah daripada 9.6 atau lebih lama, jadi pastikan anda menguji peningkatan pada salinan berasingan dan jalankan melalui keluaran sebelum melakukan peningkatan sebenar Semua mungkin soalan dalam huraian. Kelemahan yang paling ketara ialah:

Semua fungsi yang mengandungi "xlog" telah dinamakan semula untuk menggunakan "wal" dan bukannya "xlog".

Penamaan terakhir mungkin dikelirukan dengan log pelayan biasa, jadi ini adalah perubahan "untuk berjaga-jaga". Jika menggunakan mana-mana alat sandaran/replikasi/HA pihak ketiga, pastikan ia adalah terkini.

Folder pg_log yang menyimpan log pelayan (mesej ralat/amaran, dsb.) telah dinamakan semula kepada "log".

Pastikan anda mengesahkan bahawa penghuraian log atau skrip grep anda (jika ada) berfungsi.

Secara lalai, pertanyaan akan menggunakan sehingga 2 proses latar belakang.

Jika anda menggunakan nilai lalai 10 dalam tetapan postgresql.conf pada mesin dengan bilangan CPU yang rendah, anda mungkin melihat lonjakan dalam penggunaan sumber kerana pemprosesan selari didayakan secara lalai - ini adalah perkara yang baik kerana ia sepatutnya bermakna untuk pertanyaan yang lebih pantas. Jika anda mahukan gelagat lama, tetapkan max_parallel_workers_per_gather kepada 0.

Secara lalai, sambungan replikasi untuk localhost didayakan.

Untuk memudahkan perkara seperti ujian, localhost dan sambungan replikasi soket Unix tempatan kini didayakan dalam mod "amanah" (tiada kata laluan) dalam pg_hba.conf! Oleh itu, pastikan anda menukar konfigurasi jika pengguna bukan DBA lain mempunyai akses kepada mesin pengeluaran sebenar.

Kegemaran saya dari perspektif DBA

Salinan logik

Ciri yang telah lama ditunggu-tunggu ini memerlukan persediaan mudah dengan kehilangan prestasi yang minimum apabila anda hanya mahu menyalin satu jadual, sebahagian daripada jadual atau semua jadual, yang juga bermakna bahawa versi utama berikutnya boleh dinaik taraf dengan masa henti sifar! Dari segi sejarah (memerlukan Postgres 9.4+), ini boleh dilakukan dengan menggunakan sambungan pihak ketiga atau penyelesaian berasaskan pencetus perlahan. Bagi saya ini adalah 10 ciri terbaik.

Isytihar partition

Cara pengurusan partition sebelum ini melibatkan pewarisan dan penciptaan pencetus untuk mengubah hala sisipan ke jadual yang betul, yang menjengkelkan, apatah lagi impak prestasi. Pada masa ini disokong ialah skema pembahagian "julat" dan "senarai". Jika sesiapa kehilangan pembahagian "cincang" dalam sesetengah enjin pangkalan data, anda boleh menggunakan pembahagian "senarai" dengan ungkapan untuk mencapai fungsi yang sama.

Indeks cincang yang tersedia

Indeks cincang kini dilog WAL dan oleh itu selamat ranap, dan telah memperoleh beberapa peningkatan prestasi, menjadikannya lebih pantas daripada indeks B-tree standard pada data yang lebih besar untuk carian mudah. Saiz indeks yang lebih besar juga disokong.

Statistik pengoptimum rentas lajur

Statistik sedemikian perlu dibuat secara manual pada set lajur jadual untuk menunjukkan bahawa nilai sebenarnya bergantung antara satu sama lain dalam beberapa cara. Ini akan menangani pertanyaan perlahan di mana perancang berpendapat terdapat sangat sedikit data yang dikembalikan (produk kebarangkalian selalunya menghasilkan bilangan yang sangat kecil) dan dengan itu mengakibatkan prestasi yang lemah dengan jumlah data yang besar (cth. memilih gabungan "gelung bersarang").

Syot kilat selari pada replika

Kini boleh menggunakan berbilang proses (-bendera kerja) dalam pg_dump untuk mempercepatkan sandaran pada pelayan siap sedia.

Selaraskan tingkah laku pekerja pemprosesan selari dengan lebih baik

Rujuk kepada max_parallel_workers dan min_parallel_table_scan_size/min_parallel_index_scan_size parameter. Saya mengesyorkan meningkatkan nilai lalai untuk dua yang terakhir sedikit (8MB, 512KB).

Peranan pemantauan terbina dalam baharu untuk penggunaan alat yang lebih mudah

Peranan baharu pg_monitor, pg_read_all_settings, pg_read_all_stats dan pg_stat_scan_tables memudahkan anda melaksanakan pelbagai tugas pemantauan - yang sebelum ini perlu dilakukan menggunakan akaun superuser atau beberapa fungsi pembungkus SECURITY DEFINER.

Slot replikasi sementara (setiap sesi) untuk penjanaan replika yang lebih selamat

Sambungan Sumbangan baharu untuk menyemak kesahihan indeks B-tree

Dua semakan pintar ini mendedahkan ketidakkonsistenan struktur dan kandungan yang tidak diliputi oleh pengesahan peringkat halaman. Semoga lebih mendalam dalam masa terdekat.

Alat pertanyaan Psql kini menyokong cawangan asas (jika/elif/else)

Sebagai contoh, perkara berikut akan membolehkan satu skrip penyelenggaraan/pemantauan dengan cawangan versi tertentu (dengan nama lajur yang berbeza untuk paparan pg_stat* dsb.) dan bukannya banyak skrip khusus versi.

SELECT :VERSION_NAME = '10.0' AS is_v10 \gset
\if :is_v10
SELECT 'yippee' AS msg;
\else
SELECT 'time to upgrade!' AS msg;
\endif

Itu sahaja kali ini! Sudah tentu terdapat banyak perkara lain yang tidak disenaraikan, jadi untuk DBA yang berdedikasi, saya pasti akan mengesyorkan agar anda melihat rekod keluaran yang lebih komprehensif. Terima kasih banyak kepada 300+ orang yang menyumbang kepada keluaran ini!

Atas ialah kandungan terperinci DBA menemui masalah baharu dengan PostgreSQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Artikel ini dikembalikan pada:linuxprobe.com. Jika ada pelanggaran, sila hubungi admin@php.cn Padam