Sepuluh Tips untuk Memasuki Produksi Dengan PostgreSQL

Masuk ke produksi adalah tugas yang sangat penting yang harus dipikirkan dan direncanakan dengan cermat sebelumnya. Beberapa keputusan yang tidak begitu baik dapat dengan mudah diperbaiki setelahnya, tetapi beberapa lainnya tidak. Jadi selalu lebih baik untuk menghabiskan waktu ekstra itu untuk membaca dokumen resmi, buku, dan penelitian yang dibuat oleh orang lain lebih awal, daripada menyesal kemudian. Ini berlaku untuk sebagian besar penerapan sistem komputer, dan PostgreSQL tidak terkecuali.

Perencanaan Awal Sistem

Beberapa keputusan harus diambil sejak dini, sebelum sistem ditayangkan. DBA PostgreSQL harus menjawab sejumlah pertanyaan:Apakah DB akan berjalan pada bare metal, VM, atau bahkan dalam container? Apakah itu akan berjalan di tempat organisasi atau di cloud? OS mana yang akan digunakan? Apakah penyimpanannya akan menjadi jenis disk berputar atau SSD? Untuk setiap skenario atau keputusan, ada pro dan kontra dan panggilan terakhir akan dilakukan bekerja sama dengan para pemangku kepentingan sesuai dengan kebutuhan organisasi. Secara tradisional orang-orang dulu menjalankan PostgreSQL pada bare metal, tetapi ini telah berubah secara dramatis dalam beberapa tahun terakhir dengan semakin banyak penyedia cloud yang menawarkan PostgreSQL sebagai opsi standar, yang merupakan tanda adopsi yang luas dan hasil dari meningkatnya popularitas PostgreSQL. Terlepas dari solusi spesifik, DBA harus memastikan bahwa data akan aman, artinya database akan mampu bertahan dari crash, dan ini adalah kriteria No1 saat membuat keputusan tentang perangkat keras dan penyimpanan. Jadi ini membawa kita ke tip pertama!

Kiat 1

Apa pun yang diiklankan oleh pengontrol disk atau produsen disk atau penyedia penyimpanan cloud, Anda harus selalu memastikan bahwa penyimpanan tidak berbohong tentang fsync. Setelah fsync kembali OK, data harus aman di media tidak peduli apa yang terjadi setelahnya (crash, kegagalan daya, dll). Satu alat bagus yang akan membantu Anda menguji keandalan cache tulis ulang disk Anda adalah diskchecker.pl.

Baca saja catatannya:https://brad.livejournal.com/2116715.html dan lakukan tesnya.

Gunakan satu mesin untuk mendengarkan peristiwa dan mesin yang sebenarnya untuk menguji. Anda akan melihat:

 verifying: 0.00%
 verifying: 10.65%
…..
 verifying: 100.00%
Total errors: 0

di akhir laporan pada mesin yang diuji.

Perhatian kedua setelah keandalan harus tentang kinerja. Keputusan tentang sistem (CPU, memori), dulunya jauh lebih penting karena cukup sulit untuk mengubahnya nanti. Namun di era cloud saat ini, kita bisa lebih fleksibel tentang sistem yang dijalankan DB. Hal yang sama berlaku untuk penyimpanan, terutama di awal kehidupan suatu sistem dan ketika ukurannya masih kecil. Ketika DB melewati ukuran angka TB, maka semakin sulit untuk mengubah parameter penyimpanan dasar tanpa perlu menyalin database sepenuhnya - atau bahkan lebih buruk, untuk melakukan pg_dump, pg_restore. Tips kedua adalah tentang kinerja sistem.

Kiat 2

Demikian pula untuk selalu menguji janji produsen mengenai keandalan, hal yang sama harus Anda lakukan tentang kinerja perangkat keras. Bonnie++ adalah tolok ukur kinerja penyimpanan paling populer untuk sistem mirip Unix. Untuk pengujian sistem secara keseluruhan (CPU, Memori dan juga penyimpanan) tidak ada yang lebih representatif daripada kinerja DB. Jadi tes kinerja dasar pada sistem baru Anda akan menjalankan pgbench, rangkaian benchmark PostgreSQL resmi berdasarkan TCP-B.

Memulai pgbench cukup mudah, yang harus Anda lakukan adalah:

[email protected]:~$ createdb pgbench
[email protected]:~$ pgbench -i pgbench
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables...
100000 of 100000 tuples (100%) done (elapsed 0.12 s, remaining 0.00 s)
vacuum...
set primary keys...
done.
[email protected]:~$ pgbench pgbench
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
latency average = 2.038 ms
tps = 490.748098 (including connections establishing)
tps = 642.100047 (excluding connections establishing)
[email protected]:~$

Anda harus selalu berkonsultasi dengan pgbench setelah perubahan penting apa pun yang ingin Anda nilai dan bandingkan hasilnya.

Penerapan Sistem, Otomatisasi, dan Pemantauan

Setelah Anda ditayangkan, sangat penting untuk memiliki komponen sistem utama yang didokumentasikan dan dapat direproduksi, memiliki prosedur otomatis untuk membuat layanan dan tugas berulang, dan juga memiliki alat untuk melakukan pemantauan berkelanjutan.

Kiat 3

Salah satu cara praktis untuk mulai menggunakan PostgreSQL dengan semua fitur perusahaan tingkat lanjut adalah ClusterControl oleh Somenines. Seseorang dapat memiliki klaster PostgreSQL kelas perusahaan, hanya dengan menekan beberapa klik. ClusterControl menyediakan semua layanan yang disebutkan di atas dan banyak lagi. Menyiapkan ClusterControl cukup mudah, cukup ikuti petunjuk pada dokumentasi resmi. Setelah Anda menyiapkan sistem Anda (biasanya satu untuk menjalankan CC dan satu lagi untuk PostgreSQL untuk pengaturan dasar) dan melakukan pengaturan SSH, maka Anda harus memasukkan parameter dasar (IP, port nos, dll), dan jika semuanya berjalan dengan baik, Anda harus lihat output seperti berikut:

Dan di layar kluster utama:

Anda dapat login ke server master Anda dan mulai membuat skema Anda! Tentu saja Anda dapat menggunakan cluster yang baru saja Anda buat sebagai basis untuk lebih membangun infrastruktur (topologi) Anda. Ide yang umumnya bagus adalah memiliki tata letak sistem file server yang stabil dan konfigurasi akhir pada server PostgreSQL dan database pengguna/aplikasi Anda sebelum Anda mulai membuat klon dan standby (slave) berdasarkan server baru yang Anda buat.

Tata Letak, Parameter, dan Pengaturan PostgreSQL

Pada fase inisialisasi cluster keputusan yang paling penting adalah apakah akan menggunakan checksum data pada halaman data atau tidak. Jika Anda menginginkan keamanan data maksimum untuk data berharga Anda (masa depan), maka inilah saatnya untuk melakukannya. Jika ada kemungkinan Anda menginginkan fitur ini di masa mendatang dan Anda lalai melakukannya pada tahap ini, Anda tidak akan dapat mengubahnya nanti (tanpa pg_dump/pg_restore). Ini tips selanjutnya:

Kiat 4

Untuk mengaktifkan checksum data, jalankan initdb sebagai berikut:

$ /usr/lib/postgresql/10/bin/initdb --data-checksums <DATADIR>

Perhatikan bahwa ini harus dilakukan pada saat tip 3 yang kami jelaskan di atas. Jika Anda sudah membuat cluster dengan ClusterControl, Anda harus menjalankan kembali pg_createcluster dengan tangan, karena pada saat penulisan ini tidak ada cara untuk memberi tahu sistem atau CC untuk menyertakan opsi ini.

Langkah lain yang sangat penting sebelum Anda masuk ke produksi adalah merencanakan tata letak sistem file server. Sebagian besar distro linux modern (setidaknya yang berbasis debian) memasang semuanya di / tetapi dengan PostgreSQL biasanya Anda tidak menginginkannya. Adalah bermanfaat untuk memiliki tablespace Anda pada volume yang terpisah, untuk memiliki satu volume yang didedikasikan untuk file WAL dan satu lagi untuk pg log. Tapi yang paling penting adalah memindahkan WAL ke disk sendiri. Ini membawa kita ke tip berikutnya.

Kiat 5

Dengan PostgreSQL 10 di Debian Stretch, Anda dapat memindahkan WAL ke disk baru dengan perintah berikut (misalkan disk baru diberi nama /dev/sdb ):

# mkfs.ext4 /dev/sdb
# mount /dev/sdb /pgsql_wal
# mkdir /pgsql_wal/pgsql
# chown postgres:postgres /pgsql_wal/pgsql
# systemctl stop postgresql
# su postgres
$ cd /var/lib/postgresql/10/main/
$ mv pg_wal /pgsql_wal/pgsql/.
$ ln -s /pgsql_wal/pgsql/pg_wal
$ exit
# systemctl start postgresql

Sangat penting untuk menyiapkan lokal dan penyandian basis data Anda dengan benar. Abaikan ini pada fase createb dan Anda akan sangat menyesalinya, karena aplikasi/DB Anda bergerak ke wilayah i18n, l10n. Kiat berikutnya menunjukkan cara melakukannya.

Kiat 6

Anda harus membaca dokumen resmi dan memutuskan pengaturan COLLATE dan CTYPE (createdb --locale=) Anda (bertanggung jawab atas urutan pengurutan dan klasifikasi karakter) serta pengaturan charset (createdb --encoding=). Menentukan UTF8 sebagai pengkodean akan memungkinkan database Anda untuk menyimpan teks multi-bahasa.

Ketersediaan Tinggi PostgreSQL

Sejak PostgreSQL 9.0, ketika replikasi streaming menjadi fitur standar, menjadi mungkin untuk memiliki satu atau lebih hot standby yang hanya dapat dibaca, sehingga memungkinkan kemungkinan untuk mengarahkan lalu lintas hanya-baca ke salah satu slave yang tersedia. Ada rencana baru untuk replikasi multimaster tetapi pada saat penulisan ini (10.3) hanya mungkin untuk memiliki satu master baca-tulis, setidaknya dalam produk sumber terbuka resmi. Untuk tip berikutnya yang berhubungan dengan hal ini.

Kiat 7

Kami akan menggunakan ClusterControl PGSQL_CLUSTER kami yang dibuat di Tip 3. Pertama, kami membuat mesin kedua yang akan bertindak sebagai budak hanya-baca (hot standby dalam terminologi PostgreSQL). Kemudian kita klik Add Replication slave, dan pilih master kita dan slave baru. Setelah pekerjaan selesai, Anda akan melihat output ini:

Dan cluster sekarang akan terlihat seperti:

Perhatikan ikon hijau "dicentang" pada label "BUDA" di sebelah "MASTER". Anda dapat memverifikasi bahwa replikasi streaming berfungsi, dengan membuat objek database (database, tabel, dll) atau menyisipkan beberapa baris dalam tabel di master dan melihat perubahannya di standby.

Kehadiran read-only standby memungkinkan kita untuk melakukan load balancing untuk klien yang melakukan query pilih-saja antara dua server yang tersedia, master dan slave. Ini membawa kita ke tip 8.

Kiat 8

Anda dapat mengaktifkan penyeimbangan beban antara dua server menggunakan HAProxy. Dengan ClusterControl ini cukup mudah dilakukan. Anda klik Manage->Load Balancer. Setelah memilih server HAProxy Anda, ClusterControl akan menginstal semuanya untuk Anda:xinetd pada semua instance yang Anda tentukan dan HAProxy pada server yang ditunjuk HAProxy Anda. Setelah pekerjaan selesai dengan sukses, Anda akan melihat:

Perhatikan tanda centang hijau HAPROXY di sebelah SLAVES. Sekarang Anda dapat menguji apakah HAProxy berfungsi:

[email protected]:~$ psql -h localhost -p 5434
psql (10.3 (Debian 10.3-1.pgdg90+1))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
 inet_server_addr
------------------
 192.168.1.61
(1 row)
--
-- HERE STOP PGSQL SERVER AT  192.168.1.61
--
postgres=# select inet_server_addr();
FATAL:  terminating connection due to administrator command
SSL connection has been closed unexpectedly
The connection to the server was lost. Attempting reset: Succeeded.
postgres=# select inet_server_addr();
 inet_server_addr
------------------
 192.168.1.60
(1 row)
postgres=#

Kiat 9

Selain mengonfigurasi untuk HA dan load balancing, selalu bermanfaat untuk memiliki semacam kumpulan koneksi di depan server PostgreSQL. Pgpool dan Pgbouncer adalah dua proyek yang berasal dari komunitas PostgreSQL. Banyak server aplikasi perusahaan juga menyediakan kumpulan mereka sendiri. Pgbouncer telah sangat populer karena kesederhanaan, kecepatan, dan fitur "pengumpulan transaksi", di mana, koneksi ke server dibebaskan setelah transaksi berakhir, sehingga dapat digunakan kembali untuk transaksi berikutnya yang mungkin berasal dari sesi yang sama atau berbeda . Pengaturan penyatuan transaksi merusak beberapa fitur penyatuan sesi, tetapi secara umum konversi ke penyiapan siap "pengumpulan transaksi" mudah dan kekurangannya tidak begitu penting dalam kasus umum. Penyiapan umum adalah mengonfigurasi kumpulan server aplikasi dengan koneksi semi-persisten:Kumpulan koneksi yang lebih besar per pengguna atau per aplikasi (yang terhubung ke pgbouncer) dengan waktu tunggu idle yang lama. Dengan cara ini waktu koneksi dari aplikasi menjadi minimal sementara pgbouncer akan membantu menjaga koneksi ke server sesedikit mungkin.

Satu hal yang kemungkinan besar akan menjadi perhatian setelah Anda menggunakan PostgreSQL adalah memahami dan memperbaiki kueri yang lambat. Alat pemantauan yang kami sebutkan di blog sebelumnya seperti pg_stat_statements dan juga layar alat seperti ClusterControl akan membantu Anda mengidentifikasi dan mungkin menyarankan ide untuk memperbaiki kueri yang lambat. Namun begitu Anda mengidentifikasi kueri yang lambat, Anda harus menjalankan EXPLAIN atau EXPLAIN ANALYZE untuk melihat dengan tepat biaya dan waktu yang terlibat dalam rencana kueri. Tips berikutnya adalah tentang alat yang sangat berguna untuk melakukan itu.

Kiat 10

Anda harus menjalankan EXPLAIN ANALYZE di database Anda, lalu copy output dan paste di alat online explain analyze depesz dan klik submit. Kemudian Anda akan melihat tiga tab:HTML, TEXT dan STATS. HTML berisi biaya, waktu dan jumlah loop untuk setiap node dalam rencana. Tab STATS menunjukkan statistik jenis per node. Anda harus mengamati kolom “% kueri”, sehingga Anda tahu di mana tepatnya kueri Anda bermasalah.

Saat Anda semakin akrab dengan PostgreSQL, Anda akan menemukan lebih banyak kiat sendiri!