Page cover

PostgreSQL → Getting to Know Your Cluster

Sumber: Luca Ferrari, Enrico Pirozzi - Learn PostgreSQL Use, manage, and build secure and scalable databases with PostgreSQL 16 (2023) - Chapter 2

Untuk menjadi pengguna dan administrator yang mahir dalam mengelola klaster PostgreSQL, Anda harus memahami cara kerja PostgreSQL terlebih dahulu. Sebagai Sistem Manajemen Basis Data (DBMS) tingkat enterprise, PostgreSQL adalah sistem yang kompleks. Namun, berkat desain dan implementasi yang sangat baik, setelah Anda memahami konsep dasar dan terminologi PostgreSQL, segalanya akan menjadi lebih jelas dan mudah dipahami. Bab ini melanjutkan dari dasar yang telah dibahas pada bab sebelumnya dan memperkenalkan terminologi serta konsep tambahan PostgreSQL, sekaligus mengajarkan cara berinteraksi dengan klaster. Anda juga akan diperkenalkan dengan psql, klien berbasis command-line yang disertakan bersama PostgreSQL, yang merupakan cara rekomendasi untuk terhubung ke basis data Anda. Meskipun Anda bebas menggunakan klien SQL lain yang kompatibel dengan PostgreSQL, semua kode dan contoh dalam bab ini akan berjalan tanpa masalah di klien lain, tetapi kami menyarankan Anda meluangkan waktu untuk mempelajari psql. Sebagai bagian dari distribusi PostgreSQL, psql dijamin berfungsi dalam situasi apa pun dan merupakan cara default untuk terhubung ke klaster. psql adalah klien berbasis teks; jika Anda lebih nyaman menggunakan klien grafis, Anda dapat mencoba pgAdmin4, salah satu klien grafis PostgreSQL yang paling terkenal.

Bab ini mencakup topik utama berikut:

  • Mengelola klaster Anda

  • Menghubungkan ke klaster

  • Menjelajahi tata letak disk PGDATA

  • Menjelajahi file konfigurasi dan parameter

Persyaratan Teknis

Pengetahuan yang diperlukan untuk bab ini meliputi:

  • Cara menginstal paket biner di mesin Unix

  • Terminologi dasar PostgreSQL (dari bab sebelumnya)

  • Penggunaan dasar command-line Unix

  • Pernyataan SQL dasar yang dibahas dalam bab ini, seperti SELECT

Contoh-contoh dalam bab ini dapat dijalankan pada image Docker standalone, yang tersedia di repositori GitHub buku ini: https://github.com/PacktPublishing/Learn-PostgreSQL-Second-Edition. Untuk petunjuk instalasi dan penggunaan image Docker yang tersedia untuk buku ini, silakan lihat instruksi di Bab 1, Pengenalan PostgreSQL.

Mengelola Klaster Anda

Klaster PostgreSQL adalah kumpulan dari beberapa basis data yang semuanya berjalan di bawah layanan atau instance PostgreSQL yang sama. Mengelola klaster berarti mampu memulai, menghentikan, mengendalikan, dan mendapatkan informasi tentang status instance PostgreSQL.

Dari perspektif sistem operasi, PostgreSQL adalah layanan yang dapat dimulai, dihentikan, dan tentu saja, dipantau. Seperti yang Anda lihat di bab sebelumnya, biasanya ketika Anda menginstal PostgreSQL, Anda juga mendapatkan serangkaian alat dan skrip khusus sistem operasi untuk mengintegrasikan PostgreSQL dengan manajemen layanan sistem operasi Anda. Biasanya, Anda akan menemukan file layanan sistem atau alat spesifik sistem operasi lainnya, seperti pg_ctlcluster, yang disertakan dengan Debian GNU/Linux dan turunannya.

PostgreSQL menyediakan alat khusus bernama pg_ctl, yang membantu dalam mengelola klaster dan proses terkait yang berjalan. Bagian ini memperkenalkan Anda pada penggunaan dasar pg_ctl dan proses-proses yang mungkin Anda temui dalam klaster yang sedang berjalan. Tidak peduli sistem manajemen layanan apa yang digunakan oleh sistem operasi Anda, pg_ctl akan selalu tersedia bagi administrator PostgreSQL untuk mengendalikan instance basis data.

pg_ctl

Utilitas command-line pg_ctl memungkinkan Anda melakukan berbagai tindakan pada klaster, terutama menginisialisasi, memulai, memulai ulang, menghentikan, dan sebagainya. pg_ctl menerima perintah yang akan dijalankan sebagai argumen pertama, diikuti oleh argumen spesifik lainnya—perintah utama adalah sebagai berikut:

  • start, stop, dan restart menjalankan tindakan yang sesuai pada klaster.

  • status melaporkan status saat ini (berjalan atau tidak) dari klaster.

  • initdb (atau init secara singkat) menjalankan inisialisasi klaster, yang mungkin menghapus data yang sudah ada sebelumnya.

  • reload menyebabkan server PostgreSQL memuat ulang konfigurasi, yang berguna saat Anda ingin menerapkan perubahan konfigurasi.

  • promote digunakan ketika klaster berjalan sebagai server replika (yaitu, node standby) dan, mulai sekarang, harus dilepaskan dari primary asli menjadi independen (replikasi akan dijelaskan di bab-bab berikutnya).

Secara umum, pg_ctl berinteraksi terutama dengan postmaster (proses pertama yang diluncurkan dalam klaster), yang kemudian “mengalihkan” perintah ke proses lain yang ada. Misalnya, ketika pg_ctl memulai instance server, itu membuat proses postmaster berjalan, yang kemudian menyelesaikan semua aktivitas startup, termasuk meluncurkan proses utilitas lainnya (seperti yang dijelaskan secara singkat di bab sebelumnya). Sebaliknya, ketika pg_ctlmenghentikan klaster, itu mengeluarkan perintah halt ke postmaster, yang kemudian meminta proses aktif lainnya untuk keluar, menunggu mereka selesai.

Catatan: Proses postmaster adalah proses pertama yang terkait dengan PostgreSQL yang diluncurkan dalam instance; pada beberapa sistem, ada proses yang dinamakan “postmaster,” sedangkan pada sistem operasi lain, hanya ada proses yang dinamakan “postgres.” Proses pertama yang diluncurkan, terlepas dari namanya, disebut sebagai postmaster. Nama postmaster hanyalah nama yang digunakan untuk mengidentifikasi proses di antara yang lain (khususnya, proses pertama yang diluncurkan dalam klaster).

pg_ctl perlu tahu di mana lokasi PGDATA, dan ini dapat ditentukan dengan menetapkan variabel lingkungan bernama PGDATA atau dengan menentukannya di command line melalui flag -D.

Berinteraksi dengan status klaster (misalnya, untuk menghentikannya) adalah tindakan yang tidak boleh dilakukan oleh setiap pengguna; biasanya, hanya administrator sistem operasi yang harus dapat berinteraksi dengan layanan, termasuk PostgreSQL.

PostgreSQL, untuk mengurangi efek samping dari eskalasi hak istimewa, tidak mengizinkan klaster dijalankan oleh pengguna dengan hak istimewa, seperti root. Oleh karena itu, PostgreSQL dijalankan oleh pengguna “normal”, biasanya dinamakan postgres di semua sistem operasi. Pengguna tanpa hak istimewa ini memiliki direktori PGDATA dan menjalankan proses postmaster, dan oleh karena itu, juga semua proses yang diluncurkan oleh postmaster itu sendiri. pg_ctl harus dijalankan oleh pengguna sistem operasi tanpa hak istimewa yang sama yang akan menjalankan klaster.

Catatan untuk pengguna Docker: Jika Anda menggunakan image Docker, PostgreSQL sudah berjalan sebagai layanan utama. Ini berarti bahwa mengeluarkan perintah stop atau restart akan memaksa Anda keluar dari container karena shutdown-nya. Selain itu, dalam container Docker, layanan PostgreSQL akan sudah berjalan tanpa perlu intervensi manual.

Perintah status hanya meminta informasi dari klaster, sehingga cukup aman sebagai titik awal untuk memahami apa yang sedang terjadi:

$ pg_ctl status
pg_ctl: server is running (PID: 1)
/usr/lib/postgresql/16/bin/postgres

Perintah ini melaporkan bahwa server sedang berjalan, dengan Pengenal Proses (PID) sama dengan satu (nomor ini akan berbeda di mesin Anda). Selain itu, perintah ini melaporkan file executable yang digunakan untuk meluncurkan server, dalam contoh di atas, /usr/lib/postgresql/16/bin/postgres.

Jika server tidak berjalan karena alasan apa pun, perintah pg_ctl akan melaporkan pesan yang sesuai untuk menunjukkan bahwa tidak dapat menemukan instance PostgreSQL yang dimulai:

$ pg_ctl status
pg_ctl: no server running

Untuk melaporkan status klaster, pg_ctl perlu tahu di mana basis data menyimpan datanya sendiri—yaitu, di mana PGDATA berada di disk. Ada dua cara untuk membuat pg_ctl mengetahui lokasi PGDATA:

  • Menetapkan variabel lingkungan bernama PGDATA, yang berisi jalur direktori data.

  • Menggunakan flag command-line -D untuk menentukan jalur ke direktori data.

Hampir setiap perintah terkait klaster PostgreSQL mencari nilai PGDATA sebagai variabel lingkungan atau sebagai opsi command-line -D.

Dalam contoh sebelumnya, tidak ada PGDATA yang ditentukan, dan ini karena diasumsikan bahwa nilai PGDATA telah ditentukan oleh variabel lingkungan.

Sangat mudah untuk memverifikasi ini—misalnya, dalam container Docker:

$ echo $PGDATA
/postgres/16/data
$ pg_ctl status
pg_ctl: server is running (PID: 1)
/usr/lib/postgresql/16/bin/postgres

Jika pengaturan Anda tidak menyertakan variabel lingkungan PGDATA, Anda selalu dapat menetapkannya secara manual sebelum meluncurkan pg_ctl atau perintah lain terkait klaster:

$ export PGDATA=/postgres/16/data
$ pg_ctl status
pg_ctl: server is running (PID: 1)

Argumen command-line, yang ditentukan dengan -D, selalu memiliki prioritas lebih tinggi dibandingkan variabel lingkungan PGDATA, jadi jika Anda tidak menetapkan atau salah mengkonfigurasi variabel PGDATA tetapi memberikan nilai yang benar di command line, semuanya akan berfungsi dengan baik:

$ export PGDATA=/postgres/data # PGDATA salah!
$ pg_ctl status -D /postgres/16/data
pg_ctl: server is running (PID: 1)
/usr/lib/postgresql/16/bin/postgres "-D" "/postgres/16/data"

Konsep yang sama tentang PGDATA dan argumen opsional -D berlaku untuk hampir semua perintah “tingkat rendah” yang bertindak terhadap klaster dan menjelaskan bahwa, dengan set executable yang sama, Anda dapat menjalankan beberapa instance PostgreSQL di mesin yang sama, selama Anda menjaga direktori PGDATA masing-masing terpisah.

Peringatan: Jangan gunakan direktori PGDATA yang sama untuk beberapa versi PostgreSQL. Meskipun mungkin tergoda, di mesin uji Anda sendiri, untuk memiliki satu direktori PGDATA yang dapat digunakan secara bergantian oleh instance PostgreSQL 16 dan PostgreSQL 15, ini tidak akan berfungsi seperti yang diharapkan dan Anda berisiko kehilangan semua data Anda. Untungnya, PostgreSQL cukup pintar untuk melihat bahwa PGDATA telah dibuat dan digunakan oleh versi yang berbeda dan menolak untuk beroperasi, tetapi harap berhati-hati untuk tidak berbagi direktori PGDATA yang sama dengan instance yang berbeda.

pg_ctl dapat digunakan untuk memulai dan menghentikan klaster dengan perintah yang sesuai. Misalnya, Anda dapat memulai instance dengan perintah start (dengan asumsi variabel lingkungan PGDATA telah ditetapkan):

$ pg_ctl start
waiting for server to start....
[27765] LOG: starting PostgreSQL 16.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 12.1.0, 64-bit
[27765] LOG: listening on IPv6 address "::1", port 5432
[27765] LOG: listening on IPv4 address "127.0.0.1", port 5432
[27765] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
[27768] LOG: database system was shut down at 2023-07-19 07:20:24 EST
[27765] LOG: database system is ready to accept connections
done
server started

Catatan untuk pengguna Docker: Perintah start, stop, dan restart tidak berfungsi pada image Docker dari repositori buku ini karena container tersebut menjalankan PostgreSQL sebagai proses utama; oleh karena itu, menghentikan (atau memulai ulang) akan menyebabkan container keluar. Demikian pula, tidak perlu memulai layanan karena layanan akan dimulai secara otomatis setelah container dimulai.

Perintah pg_ctl meluncurkan proses postmaster, yang mencetak beberapa baris log sebelum mengalihkan log ke file log yang sesuai. Pesan server started di akhir mengonfirmasi bahwa server telah dimulai. Selama startup, PID dari postmaster dilaporkan dalam tanda kurung siku; dalam contoh di atas, postmaster adalah nomor proses sistem operasi 27765.

Sekarang, jika Anda menjalankan pg_ctl lagi untuk memeriksa server, Anda akan melihat bahwa server telah dimulai:

$ pg_ctl status
pg_ctl: server is running (PID: 27765)
/usr/pgsql-16/bin/postgres

Seperti yang Anda lihat, server sekarang berjalan dan pg_ctl menunjukkan PID dari postmaster yang berjalan (27765), serta baris perintah executable (dalam kasus ini, /usr/pgsql-16/bin/postgres).

Ingat: Proses postmaster adalah proses pertama yang dimulai dalam klaster. Baik proses backend maupun postmasterdijalankan dari executable postgres, dan postmaster hanyalah akar dari semua proses PostgreSQL, dengan tujuan utama untuk mengendalikan semua proses lainnya.

Sekarang klaster sedang berjalan, mari kita hentikan. Seperti yang bisa Anda bayangkan, stop adalah perintah yang digunakan untuk menginstruksikan pg_ctl tentang tindakan yang akan dilakukan:

$ pg_ctl stop
waiting for server to shut down....
[27765] LOG: received fast shutdown request
[27765] LOG: aborting any active transactions
[27765] LOG: background worker "logical replication launcher" (PID 27771) exited with exit code 1
[27766] LOG: shutting down
[27766] LOG: checkpoint starting: shutdown immediate
[27766] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.035 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=237 kB; lsn=0/1529DC8, redo lsn=0/1529DC8
[27765] LOG: database system is shut down
done
server stopped

Selama shutdown, sistem mencetak beberapa pesan untuk memberi tahu administrator tentang apa yang sedang terjadi, dan segera setelah server berhenti, pesan server stopped mengonfirmasi bahwa klaster tidak lagi berjalan.

Menghentikan klaster bisa jauh lebih bermasalah daripada memulainya, dan untuk alasan itu, Anda dapat memberikan argumen tambahan ke perintah stop agar pg_ctl bertindak sesuai. Ada tiga cara untuk menghentikan klaster:

  • Mode smart: Klaster PostgreSQL akan menunggu dengan lembut sampai semua klien yang terhubung memutuskan koneksi dan baru kemudian akan mematikan klaster.

  • Mode fast: Akan segera memutuskan semua klien dan mematikan server tanpa harus menunggu.

  • Mode immediate: Akan menghentikan semua proses PostgreSQL, termasuk koneksi klien, dan mematikan klaster dengan cara “kotor”, yang berarti server akan memerlukan aktivitas khusus saat restart untuk membersihkan data “kotor” tersebut (lebih lanjut tentang ini di bab berikutnya).

Dalam hal apa pun, setelah perintah stop dikeluarkan, server tidak akan menerima koneksi baru dari klien, dan tergantung pada mode stop yang Anda pilih, koneksi yang ada akan dihentikan. Mode stop default, jika tidak ada yang ditentukan, adalah fast, yang memaksa pemutusan segera dari klien tetapi memastikan integritas data.

Jika Anda ingin mengubah mode stop, Anda dapat menggunakan flag -m, dengan menentukan nama mode, seperti berikut:

$ pg_ctl stop -m smart
waiting for server to shut down........................ done
server stopped

Dalam contoh di atas, perintah pg_ctl akan menunggu, mencetak titik setiap detik sampai semua klien memutuskan koneksi dari server. Sementara itu, jika Anda mencoba terhubung ke klaster yang sama dari klien lain, Anda akan menerima error, karena server telah memasuki prosedur penghentian:

$ psql
psql: error: could not connect to server: FATAL: the database system is shutting down

Anda dapat menentukan hanya huruf pertama dari mode stop alih-alih kata lengkap; jadi, misalnya, s untuk smart, iuntuk immediate, dan f untuk fast.

Proses PostgreSQL

Anda telah mempelajari bahwa postmaster adalah akar dari semua proses PostgreSQL, tetapi seperti yang dijelaskan di Bab 1, Pengenalan PostgreSQL, PostgreSQL akan meluncurkan beberapa proses berbeda saat startup. Proses-proses ini bertanggung jawab untuk menjaga klaster tetap beroperasi dan dalam kondisi baik. Bagian ini memberikan gambaran tentang proses utama yang dapat Anda temukan dalam klaster yang sedang berjalan, memungkinkan Anda untuk mengenali masing-masing dan tujuannya.

Jika Anda memeriksa klaster yang sedang berjalan dari perspektif sistem operasi, Anda akan melihat beberapa proses yang terkait dengan PostgreSQL:

$ pstree -p postgres
postgres(1)─┬─postgres(34)
            ├─postgres(35)
            ├─postgres(37)
            ├─postgres(38)
            └─postgres(39)
$ ps -C postgres -af
postgres 1 0 0 11:08 ? 00:00:00 postgres
postgres 34 1 0 11:08 ? 00:00:00 postgres: checkpointer
postgres 35 1 0 11:08 ? 00:00:00 postgres: background writer
postgres 37 1 0 11:08 ? 00:00:00 postgres: walwriter
postgres 38 1 0 11:08 ? 00:00:00 postgres: autovacuum launcher
postgres 39 1 0 11:08 ? 00:00:00 postgres: logical replication launcher

Catatan: Nomor PID yang dilaporkan dalam contoh ini merujuk ke container Docker, di mana proses PostgreSQL pertama memiliki PID sama dengan 1. Di mesin lain, Anda akan mendapatkan nomor PID yang berbeda.

Seperti yang Anda lihat, proses dengan PID 1 adalah proses yang menelurkan beberapa proses anak lainnya dan karenanya merupakan proses PostgreSQL pertama dan utama yang diluncurkan, dan biasanya disebut postmaster. Proses lainnya adalah sebagai berikut:

  • checkpointer: Proses yang bertanggung jawab untuk menjalankan checkpoint, yaitu titik waktu di mana basis data memastikan bahwa semua data benar-benar disimpan secara permanen di disk.

  • background writer: Bertanggung jawab untuk membantu mendorong data dari memori ke penyimpanan permanen.

  • walwriter: Bertanggung jawab untuk menulis Write-Ahead Logs (WAL), log yang diperlukan untuk memastikan keandalan data bahkan dalam kasus crash basis data.

  • logical replication launcher: Proses yang bertanggung jawab untuk menangani replikasi logis.

Tergantung pada konfigurasi klaster yang tepat, mungkin ada proses lain yang aktif:

  • Background workers: Proses yang dapat disesuaikan oleh pengguna untuk melakukan tugas latar belakang.

  • WAL receiver dan/atau WAL sender: Proses yang terlibat dalam menerima data dari atau mengirim data ke klaster lain dalam skenario replikasi.

Berikut adalah contoh daftar proses dengan koneksi klien:

$ ps -C postgres -af
postgres 1 0 0 11:08 ? 00:00:00 postgres
postgres 34 1 0 11:08 ? 00:00:00 postgres: checkpointer
postgres 35 1 0 11:08 ? 00:00:00 postgres: background writer
postgres 37 1 0 11:08 ? 00:00:00 postgres: walwriter
postgres 38 1 0 11:08 ? 00:00:00 postgres: autovacuum launcher
postgres 39 1 0 11:08 ? 00:00:00 postgres: logical replication launcher
postgres 40 1 0 04:35 ? 00:00:00 postgres: postgres postgres [local] idle

Banyak konsep dan tujuan dari daftar proses di atas akan menjadi lebih jelas seiring Anda melanjutkan bab-bab buku ini, tetapi untuk saat ini, cukup tahu bahwa PostgreSQL memiliki beberapa proses lain yang selalu aktif tanpa mempedulikan koneksi klien yang masuk.

Ketika klien terhubung ke klaster Anda, proses baru akan ditelurkan: proses ini, yang disebut backend process, bertanggung jawab untuk melayani permintaan klien (artinya menjalankan kueri dan mengembalikan hasil). Anda dapat melihat dan menghitung koneksi dengan memeriksa daftar proses.

Jika Anda membandingkan daftar di atas dengan yang sebelumnya, Anda akan melihat bahwa ada proses lain dengan PID 40: proses ini adalah proses backend. Secara khusus, proses ini mewakili koneksi klien ke basis data bernama postgres.

Catatan: PostgreSQL menggunakan pendekatan proses untuk konkurensi alih-alih pendekatan multi-thread. Ada berbagai alasan untuk ini: terutama isolasi dan portabilitas yang ditawarkan oleh pendekatan multi-proses. Selain itu, pada perangkat keras dan perangkat lunak modern, mem-fork proses tidak lagi merupakan operasi yang mahal.

Oleh karena itu, setelah PostgreSQL berjalan, ada pohon proses yang berakar pada postmaster. Tujuan dari yang terakhir adalah untuk menelurkan proses baru ketika ada kebutuhan untuk menangani koneksi basis data baru, serta memantau semua proses pemeliharaan untuk memastikan bahwa klaster berjalan dengan baik.

Menghubungkan ke Klaster

Setelah PostgreSQL berjalan, ia menunggu koneksi basis data yang masuk untuk dilayani; segera setelah koneksi masuk, PostgreSQL melayaninya dengan menghubungkan klien ke basis data yang tepat. Ini berarti bahwa untuk berinteraksi dengan klaster, Anda perlu terhubung ke sana. Namun, Anda tidak terhubung ke seluruh klaster; sebaliknya, Anda meminta PostgreSQL untuk berinteraksi dengan salah satu basis data yang dilayani klaster. Oleh karena itu, ketika Anda terhubung ke klaster, Anda perlu terhubung ke basis data tertentu. Ini juga berarti bahwa klaster harus memiliki setidaknya satu basis data sejak awal keberadaannya.

Ketika Anda menginisialisasi klaster dengan perintah initdb, PostgreSQL membangun tata letak filesystem dari direktori PGDATA dan membuat dua basis data template, yang dinamakan template0 dan template1. Basis data template digunakan sebagai titik awal untuk mengkloning basis data baru lainnya, yang kemudian dapat digunakan oleh pengguna normal untuk terhubung. Dalam klaster PostgreSQL yang baru diinstal, Anda biasanya akan memiliki basis data postgres, yang digunakan untuk memungkinkan pengguna administrator basis data postgres untuk terhubung dan berinteraksi dengan klaster.

Untuk terhubung ke salah satu basis data, baik template maupun yang dibuat pengguna, Anda memerlukan klien untuk terhubung. PostgreSQL menyediakan psql, klien command-line yang memungkinkan Anda untuk terhubung, berinteraksi dengan, dan mengelola basis data serta klaster itu sendiri.

Klien lain memang ada, tetapi tidak akan dibahas dalam buku ini. Anda bebas memilih klien yang paling Anda sukai, karena setiap perintah, kueri, dan contoh yang ditunjukkan dalam buku ini akan berjalan tanpa terkecuali di setiap klien yang kompatibel.

Meskipun terhubung secara interaktif ke klaster adalah tugas penting bagi administrator basis data, seringkali, pengembang memerlukan aplikasi mereka sendiri untuk terhubung ke klaster. Untuk mencapai ini, aplikasi memerlukan apa yang disebut connection string, sebuah URI yang menunjukkan semua parameter yang diperlukan untuk terhubung ke basis data.

Bagian ini akan menjelaskan semua konsep di atas, mulai dari basis data template, kemudian menunjukkan penggunaan dasar psql dan connection string.

Basis Data Template

Basis data template1 adalah basis data pertama yang dibuat ketika sistem diinisialisasi, dan kemudian dikloning ke template0. Ini berarti bahwa kedua basis data tersebut, setidaknya pada awalnya, identik, dan tujuan template0 adalah bertindak sebagai salinan aman untuk membangun kembali jika secara tidak sengaja rusak atau dihapus.

Anda dapat memeriksa basis data yang tersedia menggunakan perintah psql -l. Pada instalasi yang baru, Anda akan mendapatkan tiga basis data berikut:

$ psql -l
List of databases
Name      | Owner   | Encoding | Collate       | Ctype       | ICU Locale | Locale Provider | Access privileges
-----------+---------+----------+---------------+-------------+------------+-----------------+-------------------
postgres  | postgres | UTF8     | it_IT.UTF-8   | it_IT.UTF-8 |            | libc            |
template0 | postgres | UTF8     | it_IT.UTF-8   | it_IT.UTF-8 |            | libc            | =c/postgres + ...
template1 | postgres | UTF8     | it_IT.UTF-8   | it_IT.UTF-8 |            | libc            | =c/postgres + ...
(3 rows)

Catatan untuk pengguna Docker: Dalam image Docker, Anda juga akan melihat basis data forumdb, yang telah dibuat secara otomatis untuk memungkinkan Anda berinteraksi dengan contoh lain.

Menarik untuk dicatat bahwa, di samping dua basis data template, ada basis data ketiga yang dibuat selama proses instalasi: basis data postgres. Basis data ini milik pengguna postgres, yang secara default adalah satu-satunya administrator basis data yang dibuat selama proses inisialisasi. Basis data ini adalah ruang umum yang digunakan untuk koneksi alih-alih basis data template.

Nama template menunjukkan tujuan sebenarnya dari kedua basis data ini: ketika Anda membuat basis data baru, PostgreSQL mengkloning basis data template sebagai dasar umum. Ini mirip dengan membuat direktori home pengguna di sistem Unix: sistem mengkloning direktori skeleton dan menetapkan salinan baru ke pengguna. PostgreSQL melakukan hal yang sama—mengkloning template1 dan menetapkan basis data yang baru dibuat ke pengguna yang memintanya.

Ini juga berarti bahwa objek apa pun yang Anda masukkan ke template1, Anda akan menemukan objek yang sama di basis data yang baru dibuat. Ini bisa sangat berguna untuk menyediakan basis data dasar yang umum dan membuat semua basis data lain memiliki atribut dan objek yang sama.

Namun, Anda tidak dipaksa untuk menggunakan template1 sebagai template dasar; faktanya, Anda dapat membuat basis data Anda sendiri dan menggunakannya sebagai template untuk basis data lain. Namun, perlu diingat bahwa, secara default (dan terutama pada sistem yang baru diinisialisasi), basis data template1 adalah yang dikloning untuk basis data pertama yang Anda buat.

Perbedaan lain antara template1 dan template0, selain yang pertama menjadi default untuk basis data baru, adalah bahwa Anda tidak dapat terhubung ke yang terakhir. Ini untuk mencegah kerusakan yang tidak disengaja pada template0(salinan aman).

Penting untuk dicatat bahwa klaster (dan semua basis data yang ditentukan pengguna) dapat berfungsi bahkan tanpa basis data template—basis data template1 dan template0 tidak fundamental untuk basis data lain untuk berjalan. Namun, jika Anda kehilangan template, Anda akan diminta untuk menggunakan basis data lain sebagai template setiap kali Anda melakukan tindakan yang membutuhkannya, seperti membuat basis data baru.

Peringatan: Basis data template tidak dimaksudkan untuk koneksi interaktif, dan Anda tidak boleh terhubung ke basis data template kecuali Anda perlu menyesuaikannya. PostgreSQL akan menampilkan error jika ada koneksi aktif ke basis data template saat digunakan sebagai skeleton untuk basis data lain.

Klien Command-Line psql

Perintah psql adalah antarmuka command-line yang disertakan dengan setiap instalasi PostgreSQL. Meskipun Anda tentu saja dapat menggunakan antarmuka pengguna grafis untuk terhubung dan berinteraksi dengan basis data, pengetahuan dasar tentang psql wajib untuk mengelola klaster PostgreSQL. Faktanya, versi spesifik psql disertakan dengan setiap rilis PostgreSQL; oleh karena itu, ini adalah klien paling mutakhir yang berbicara dengan bahasa yang sama (yaitu, protokol) dari klaster. Selain itu, klien ini ringan dan berguna bahkan dalam situasi darurat ketika GUI tidak tersedia.

psql menerima beberapa opsi untuk terhubung ke basis data, terutama berikut:

  • -d: Nama basis data

  • -U: Nama pengguna

  • -h: Host (baik alamat IPv4 atau IPv6 atau nama host)

Jika tidak ada opsi yang ditentukan, psql mengasumsikan bahwa pengguna sistem operasi Anda mencoba terhubung ke basis data dengan nama yang sama, dan pengguna basis data dengan nama yang cocok dengan sistem operasi pada koneksi lokal. Lihat koneksi berikut:

$ id
uid=999(postgres) gid=999(postgres) groups=999(postgres),101(ssl-cert)
$ psql
psql (16.0)
Type "help" for help.
postgres=#

Ini berarti bahwa pengguna sistem operasi saat ini (postgres) telah meminta psql untuk terhubung ke basis data bernama postgres melalui pengguna PostgreSQL bernama postgres di mesin lokal. Secara eksplisit, koneksi tersebut bisa diminta sebagai berikut:

$ psql -U postgres -d postgres
psql (16.0)
Type "help" for help.
postgres=#

Hal pertama yang perlu diperhatikan adalah bahwa setelah koneksi terbentuk, prompt perintah berubah: psql melaporkan basis data tempat pengguna terhubung (postgres) dan tanda untuk menunjukkan bahwa mereka adalah superuser (#). Jika pengguna bukan administrator basis data, tanda > ditempatkan di akhir prompt.

Jika Anda perlu terhubung ke basis data yang dinamakan berbeda dari nama pengguna sistem operasi Anda, Anda perlu menentukannya:

$ psql -d template1
psql (16.0)
Type "help" for help.
template1=#

Demikian pula, jika Anda perlu terhubung ke basis data yang tidak sesuai dengan nama pengguna sistem operasi Anda dengan pengguna PostgreSQL yang berbeda dari nama pengguna sistem operasi Anda, Anda harus secara eksplisit memberikan kedua parameter ke psql:

$ id
uid=999(postgres) gid=999(postgres) groups=999(postgres),101(ssl-cert)
$ psql -d template1 -U luca
psql (16.0)
Type "help" for help.
template1=>

Seperti yang Anda lihat dari contoh di atas, pengguna sistem operasi postgres telah terhubung ke basis data template1dengan pengguna PostgreSQL luca. Karena yang terakhir bukan administrator sistem, prompt perintah diakhiri dengan tanda >.

Untuk keluar dari psql dan menutup koneksi ke basis data, Anda harus mengetik \q atau quit dan tekan Enter (Anda juga dapat menekan CTRL + D untuk keluar di mesin Unix dan Linux):

$ psql -d template1 -U luca
psql (16.0)
Type "help" for help.
template1=> \q
$

Memasukkan Pernyataan SQL melalui psql

Setelah Anda terhubung ke basis data melalui psql, Anda dapat mengeluarkan pernyataan apa pun yang Anda inginkan. Pernyataan harus diakhiri dengan titik koma, menunjukkan bahwa tombol Enter berikutnya akan menjalankan pernyataan. Berikut adalah contoh di mana tombol Enter telah ditekankan:

$ psql -d template1 -U luca
psql (16.0)
Type "help" for help.
template1=> SELECT current_time; <ENTER>
 current_time
--------------------
06:04:57.435155-05
(1 row)

Catatan: SQL adalah bahasa yang tidak peka terhadap huruf besar-kecil, jadi Anda dapat memasukkan pernyataan dalam huruf besar, huruf kecil, atau campuran. Aturan yang sama berlaku untuk nama kolom, yang tidak peka terhadap huruf besar-kecil. Jika Anda perlu memiliki pengenal dengan huruf besar-kecil tertentu, Anda perlu mengutipnya dalam tanda kutip ganda.

Cara lain untuk menjalankan pernyataan adalah dengan mengeluarkan perintah \g, lagi-lagi diikuti oleh <ENTER>. Ini berguna saat terhubung melalui emulator terminal yang memiliki tombol yang dipetakan ulang:

template1=> SELECT current_time \g <ENTER>
 current_time
--------------------
06:07:03.328744-05
(1 row)

Hingga Anda mengakhiri pernyataan dengan titik koma atau \g, psql akan menyimpan konten yang Anda ketik dalam buffer kueri, sehingga Anda juga dapat mengedit beberapa baris teks sebagai berikut:

template1=> SELECT
template1-> current_time
template1-> ;
 current_time
--------------------
06:07:28.908215-05
(1 row)

Perhatikan bagaimana prompt perintah psql berubah pada baris-baris setelah yang pertama: perbedaan ini ada untuk mengingatkan Anda bahwa Anda sedang mengedit pernyataan multi-baris dan psql belum menemukan terminator pernyataan (baik titik koma atau \g).

Salah satu fitur berguna dari buffer kueri psql adalah kemampuan untuk mengedit konten buffer kueri di editor eksternal. Jika Anda mengeluarkan perintah \e, editor favorit Anda akan muncul dengan konten kueri yang terakhir diedit. Anda kemudian dapat mengedit dan menyempurnakan pernyataan SQL Anda sebanyak yang Anda inginkan, dan setelah Anda keluar dari editor, psql akan membaca apa yang Anda hasilkan dan menjalankannya. Editor yang digunakan dipilih dengan variabel lingkungan sistem operasi EDITOR.

Anda juga dapat menjalankan semua pernyataan yang termasuk dalam file atau mengedit file sebelum menjalankannya. Sebagai contoh, anggap file test.sql memiliki konten berikut:

$ cat test.sql
SELECT current_database();
SELECT current_time;
SELECT current_role;

File tersebut memiliki tiga pernyataan SQL yang sangat sederhana. Untuk menjalankan seluruh file sekaligus, Anda dapat menggunakan perintah khusus \i diikuti oleh nama file:

template1=> \i test.sql
current_database
------------------
template1
(1 row)

current_time
--------------------
06:08:43.077305-05
(1 row)

current_role
--------------
luca
(1 row)

Seperti yang Anda lihat, klien telah menjalankan, satu per satu, setiap pernyataan dalam file. Jika Anda perlu mengedit file tanpa meninggalkan psql, Anda dapat mengeluarkan \e test.sql untuk membuka editor favorit Anda, membuat perubahan, dan kembali ke koneksi psql.

Catatan: SQL tidak peka terhadap huruf besar-kecil dan spasi: Anda dapat menulisnya dalam huruf besar semua atau huruf kecil semua, dengan spasi horizontal dan vertikal sebanyak yang Anda inginkan. Dalam buku ini, kata kunci SQL akan ditulis dalam huruf besar dan pernyataan akan diformat untuk dibaca dengan jelas.

Sekilas tentang Perintah psql

Setiap perintah spesifik untuk psql dimulai dengan karakter backslash (\). Anda dapat mendapatkan bantuan tentang pernyataan SQL dan perintah PostgreSQL melalui perintah khusus \h, setelah itu Anda dapat menentukan pernyataan spesifik yang Anda inginkan bantuan:

template1=> \h SELECT
Command: SELECT
Description: retrieve rows from a table or view
Syntax:
[ WITH [ RECURSIVE ] with_query [, ...] ]
SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ]
[ * | expression [ [ AS ] output_name ] [, ...] ]
...
URL: https://www.postgresql.org/docs/16/sql-select.html

Bantuan yang ditampilkan, karena alasan ruang, singkat. Anda dapat menemukan deskripsi yang jauh lebih rinci dan contoh penggunaan di dokumentasi online. Untuk alasan ini, di akhir layar bantuan, ada referensi tautan ke dokumentasi online.

Jika Anda memerlukan bantuan dengan perintah psql, Anda dapat mengeluarkan perintah \?:

template1=> \?
General
\copyright              show PostgreSQL usage and distribution terms
\crosstabview [COLUMNS] execute query and display results in crosstab
\errverbose             show most recent error message at maximum verbosity
\g [FILE] or ;          execute query (and send results to file or |pipe)
\gdesc                  describe result of query, without executing it
...

Ada juga banyak perintah introspeksi, seperti, misalnya, \d untuk mendaftar semua tabel yang ditentukan pengguna. Perintah khusus ini, di balik layar, adalah cara untuk menjalankan kueri terhadap katalog sistem PostgreSQL, yang pada gilirannya adalah registri tentang semua objek yang ada di basis data. Perintah introspeksi akan ditunjukkan nanti dalam buku ini dan berguna sebagai pintasan untuk mendapatkan gambaran tentang objek mana yang didefinisikan dalam basis data saat ini.

Banyak fitur psql akan dijelaskan lebih rinci seiring Anda melanjutkan buku ini, tetapi ada baiknya meluangkan waktu untuk membiasakan diri dengan klien command-line yang sangat efisien dan kaya ini.

Memperkenalkan Connection String

Di bagian sebelumnya, Anda telah mempelajari cara menentukan opsi koneksi dasar, seperti -d dan -U untuk basis data dan pengguna, masing-masing. psql juga menerima connection string LibPQ.

LibPQ adalah pustaka dasar yang dapat digunakan setiap aplikasi untuk terhubung ke klaster PostgreSQL dan, misalnya, digunakan dalam klien C dan C++, serta konektor non-asli.

Connection string dalam LibPQ adalah URI yang terdiri dari beberapa bagian:

postgresql://username@host:port/database

Di sini, kita memiliki:

  • postgresql adalah string tetap yang menentukan protokol yang dirujuk oleh URI.

  • username adalah nama pengguna PostgreSQL yang digunakan saat terhubung ke basis data.

  • host adalah nama host (atau alamat IP) untuk terhubung.

  • port adalah port TCP/IP yang didengarkan oleh server (secara default, 5432).

  • database adalah nama basis data yang ingin Anda hubungkan.

Bagian username, port, dan database dapat dihilangkan jika diatur ke default (username sama dengan username sistem operasi).

Koneksi berikut semuanya setara:

$ psql -d template1 -U luca -h localhost
$ psql postgresql://luca@localhost/template1
$ psql postgresql://luca@localhost:5432/template1

Memecahkan Masalah Koneksi Umum

Ada beberapa masalah umum saat menangani koneksi basis data, dan bagian ini menjelaskannya untuk memudahkan tugas Anda dalam terhubung ke klaster.

Harap dicatat bahwa solusi yang diberikan di sini hanya untuk tujuan pengujian dan bukan untuk penggunaan produksi. Semua pengaturan keamanan akan dijelaskan di bab-bab berikutnya, jadi tujuan dari subbagian berikut hanya untuk membantu Anda membuat lingkungan uji Anda dapat digunakan.

Basis Data “foo” Tidak Ada

Ini berarti Anda salah mengeja nama basis data dalam connection string atau Anda mencoba terhubung tanpa menentukan nama basis data.

Misalnya, koneksi berikut gagal ketika dijalankan oleh pengguna sistem operasi bernama luca karena, secara default, diasumsikan bahwa pengguna luca mencoba terhubung ke basis data dengan nama yang sama (yaitu, luca) karena tidak ada yang ditentukan secara eksplisit:

$ psql
psql: error: could not connect to server: FATAL: database "luca" does not exist

Solusinya adalah memberikan nama basis data yang ada melalui opsi -d atau membuat basis data dengan nama yang sama dengan pengguna.

Connection Refused

Ini biasanya berarti ada masalah koneksi jaringan, jadi baik host yang Anda coba hubungi tidak dapat dijangkau atau klaster tidak mendengarkan di jaringan.

Sebagai contoh, bayangkan PostgreSQL berjalan di mesin bernama venkman dan kita mencoba terhubung dari host lain di jaringan yang sama:

$ psql -h venkman -U luca template1
psql: error: could not connect to server: could not connect to server: Connection refused
Is the server running on host "venkman" (192.168.222.123) and accepting TCP/IP connections on port 5432?

Dalam kasus ini, klaster basis data berjalan di host jarak jauh tetapi tidak menerima koneksi dari luar. Biasanya, Anda harus memperbaiki konfigurasi server atau terhubung ke mesin jarak jauh (misalnya, melalui SSH) dan membuka koneksi lokal dari sana.

Untuk menyelesaikan masalah dengan cepat, Anda harus mengedit file postgresql.conf (biasanya terletak di bawah direktori PGDATA) dan memastikan opsi listen_addresses memiliki tanda bintang (*) atau nama kartu jaringan eksternal Anda sehingga server akan mendengarkan di semua alamat jaringan yang tersedia:

listen_addresses = '*'

Setelah restart layanan, dengan menggunakan perintah restart yang dikeluarkan ke pg_ctl, klien akan dapat terhubung. Harap dicatat bahwa mengaktifkan server untuk mendengarkan di semua alamat jaringan yang tersedia mungkin bukan solusi optimal dan dapat mengekspos server pada risiko dalam lingkungan produksi. Nanti dalam buku ini, Anda akan belajar cara mengkonfigurasi properti koneksi untuk server Anda secara spesifik.

Tidak Ada Entri pg_hba.conf

Kesalahan ini berarti server aktif dan berjalan dan dapat menerima permintaan Anda, tetapi kontrol Host-Based Access (HBA) bawaan PostgreSQL tidak mengizinkan Anda masuk.

Catatan: Kesalahan ini seharusnya tidak pernah terjadi di container Docker yang digunakan untuk bab ini, karena konfigurasinya sudah mengizinkan koneksi tepercaya. Namun, instalasi PostgreSQL lain akan lebih ketat; oleh karena itu, mengetahui tentang jenis pesan kesalahan ini dapat membantu Anda dengan cepat mengetahui di mana masalah konfigurasinya.

Sebagai contoh, koneksi berikut ditolak:

$ psql -h localhost -U luca template1
psql: error: could not connect to server: FATAL: no pg_hba.conf entry for host "127.0.0.1", user "luca", database "template1", SSL off

Alasan untuk ini adalah bahwa, saat memeriksa file pg_hba.conf, tidak ada aturan untuk mengizinkan pengguna lucamasuk di antarmuka localhost. Jadi, misalnya, menambahkan satu baris seperti berikut ke file pg_hba.conf dapat memperbaiki masalah:

host all luca 127.0.0.1/32 trust

Anda perlu memuat ulang konfigurasi untuk menerapkan perubahan. Format setiap baris dalam file pg_hba.conf akan dibahas nanti, tetapi untuk saat ini, anggap saja bahwa baris di atas menginstruksikan klaster untuk menerima koneksi apa pun yang masuk dari localhost melalui pengguna luca.

Menjelajahi Tata Letak Disk PGDATA

Di bagian sebelumnya, Anda telah melihat cara menginstal PostgreSQL dan terhubung ke sana, tetapi kami belum melihat bagian penyimpanan dari klaster. Karena tujuan PostgreSQL, seperti halnya basis data relasional lainnya, adalah untuk menyimpan data secara permanen, klaster memerlukan semacam penyimpanan permanen. Secara khusus, PostgreSQL memanfaatkan filesystem yang mendasarinya untuk menyimpan datanya sendiri. Semua hal terkait PostgreSQL terkandung dalam direktori yang dikenal sebagai PGDATA.

Direktori PGDATA bertindak sebagai wadah disk yang menyimpan semua data klaster, termasuk data pengguna dan konfigurasi klaster.

Berikut adalah contoh konten PGDATA untuk klaster PostgreSQL 16 yang sedang berjalan:

$ ls -1 /postgres/16/data
base
global
pg_commit_ts
pg_dynshmem
pg_hba.conf
pg_ident.conf
pg_logical
pg_multixact
pg_notify
pg_replslot
pg_serial
pg_snapshots
pg_stat
pg_stat_tmp
pg_subtrans
pg_tblspc
pg_twophase
PG_VERSION
pg_wal
pg_xact
postgresql.auto.conf
postgresql.conf
postmaster.opts
postmaster.pid

Direktori PGDATA terstruktur dalam beberapa file dan subdirektori. File utama adalah sebagai berikut:

  • postgresql.conf adalah file konfigurasi utama, digunakan secara default saat layanan dimulai.

  • postgresql.auto.conf adalah file konfigurasi yang disertakan secara otomatis yang digunakan untuk menyimpan pengaturan yang diubah secara dinamis melalui instruksi SQL.

  • pg_hba.conf adalah file HBA yang menyediakan konfigurasi mengenai koneksi basis data yang tersedia.

  • PG_VERSION adalah file teks yang berisi nomor versi mayor (berguna saat memeriksa direktori untuk memahami versi klaster mana yang telah mengelola direktori PGDATA).

  • postmaster.pid adalah PID dari proses postmaster, proses pertama yang diluncurkan dalam klaster.

Direktori utama yang tersedia di PGDATA adalah sebagai berikut:

  • base adalah direktori yang berisi semua data pengguna, termasuk basis data, tabel, dan objek lainnya.

  • global adalah direktori yang berisi objek yang berlaku untuk seluruh klaster.

  • pg_wal adalah direktori yang berisi file Write-Ahead Logs (WAL).

  • pg_stat dan pg_stat_tmp adalah, masing-masing, penyimpanan informasi statistik permanen dan sementara tentang status dan kesehatan klaster.

Tentu saja, semua file dan direktori di PGDATA penting untuk klaster bekerja dengan baik, tetapi sejauh ini, daftar di atas adalah daftar “inti” objek yang fundamental dalam PGDATA itu sendiri. File dan direktori lain akan dibahas di bab-bab berikutnya.

Objek di Direktori PGDATA

PostgreSQL tidak menamakan objek di disk, seperti tabel, dengan cara yang mnemonik atau mudah dibaca manusia; sebaliknya, setiap file dinamakan dengan pengenal numerik. Anda dapat melihat ini dengan melihat, misalnya, subdirektori base:

$ ls -1 /postgres/16/data/base
1
16386
4
5

Seperti yang Anda lihat dari kode di atas, direktori base berisi empat objek, dinamakan 1, 4, 5, dan 16386. Harap dicatat bahwa angka-angka ini bisa berbeda di mesin Anda. Secara khusus, masing-masing di atas adalah direktori yang berisi file lain, seperti yang ditunjukkan di sini:

$ ls -1 /postgres/16/data/base/16386 | head
112
113
1247
1247_fsm
1247_vm
1249
1249_fsm
1249_vm
1255
1255_fsm

Seperti yang Anda lihat, setiap file dinamakan dengan pengenal numerik. Secara internal, PostgreSQL menyimpan katalog khusus yang memungkinkan basis data untuk mencocokkan nama mnemonik dengan pengenal numerik, dan sebaliknya. Pengenal integer ini dinamakan OID (atau, Object Identifier); istilah ini adalah istilah historis yang saat ini sesuai dengan apa yang disebut filenode. Kedua istilah ini akan digunakan secara bergantian di bagian ini.

Ada utilitas khusus yang memungkinkan Anda untuk memeriksa direktori PGDATA dan mengekstrak nama mnemonik: oid2name. Misalnya, jika Anda menjalankan utilitas oid2name, Anda akan mendapatkan daftar semua basis data yang tersedia seperti berikut:

$ oid2name
All databases:
    Oid      Database Name   Tablespace
----------------------------------
  16390      forumdb         pg_default
      5      postgres        pg_default
      4      template0       pg_default
      1      template1       pg_default

Seperti yang Anda lihat, nomor Oid dalam keluaran oid2name mencerminkan nama direktori yang sama yang terdaftar di direktori base; setiap subdirektori memiliki nama yang sesuai dengan basis data.

Anda bahkan dapat melangkah lebih jauh dan memeriksa satu file dengan masuk ke direktori basis data, menentukan basis data tempat Anda akan mencari nama objek dengan flag -d:

$ cd /postgres/16/data/base/1
$ oid2name -d template1 -f 3395
From database "template1":
  Filenode      Table Name
-------------------------------------
    3395        pg_init_privs_o_c_o_index

Seperti yang Anda lihat dari contoh di atas, file 3395 di direktori /postgres/16/data/base/1 sesuai dengan tabel bernama pg_init_privs_o_c_o_index. Oleh karena itu, ketika PostgreSQL perlu berinteraksi dengan tabel seperti ini, ia akan mencari disk ke file /postgres/16/data/base/1/3395.

Dari contoh di atas, seharusnya jelas bahwa setiap tabel SQL disimpan sebagai file dengan nama numerik. Namun, PostgreSQL tidak mengizinkan satu file lebih besar dari 1 GB, jadi apa yang terjadi jika tabel tumbuh melebihi batas itu? PostgreSQL “menempelkan” file lain dengan ekstensi numerik yang menunjukkan potongan berikutnya sebesar 1 GB data. Dengan kata lain, jika tabel Anda disimpan di file 123, gigabyte kedua akan disimpan di file 123.1, dan jika diperlukan gigabyte penyimpanan lain, file lain, 123.2, akan dibuat. Oleh karena itu, filenode mengacu pada file pertama yang terkait dengan tabel tertentu, tetapi lebih dari satu file dapat disimpan di disk.

Tablespaces

PostgreSQL berpura-pura menemukan semua datanya dalam direktori PGDATA, tetapi itu tidak berarti bahwa klaster Anda “terkunci” di direktori ini. Faktanya, PostgreSQL memungkinkan “melarikan diri” dari direktori PGDATA melalui tablespaces. Tablespace adalah direktori yang bisa berada di luar direktori PGDATA dan juga dapat berada di penyimpanan yang berbeda. Tablespaces dipetakan ke direktori PGDATA melalui tautan simbolik yang disimpan di subdirektori pg_tblspc. Dengan cara ini, proses PostgreSQL tidak perlu mencari di luar PGDATA, tetapi masih dapat mengakses penyimpanan “eksternal”. Tablespace dapat digunakan untuk mencapai tujuan yang berbeda, seperti memperbesar penyimpanan data atau menyediakan performa penyimpanan yang berbeda untuk objek tertentu. Misalnya, Anda dapat membuat tablespace di disk lambat untuk menyimpan objek dan tabel yang jarang diakses, sambil menyimpan penyimpanan cepat dalam tablespace lain untuk objek yang sering diakses.

Anda tidak perlu membuat tautan sendiri: PostgreSQL menyediakan fitur TABLESPACE untuk mengelola ini, dan klaster akan membuat dan mengelola tautan yang sesuai di bawah subdirektori pg_tblspc.

Misalnya, berikut adalah direktori PGDATA yang memiliki tiga tablespaces berbeda:

$ ls -l /postgres/16/data/pg_tblspc/
lrwxrwxrwx 1 postgres postgres 22 Jan 19 13:08 16384 -> /data/tablespaces/ts_a
lrwxrwxrwx 1 postgres postgres 22 Jan 19 13:08 16385 -> /data/tablespaces/ts_b
lrwxrwxrwx 1 postgres postgres 22 Jan 19 13:08 16386 -> /data/tablespaces/ts_c

Seperti yang Anda lihat dari contoh di atas, ada tiga tablespaces yang terhubung ke penyimpanan /data. Anda dapat memeriksanya dengan oid2name dan flag -s:

$ oid2name -s
All tablespaces:
    Oid      Tablespace Name
------------------------
   1663      pg_default
   1664      pg_global
  16384      ts_a
  16385      ts_b
  16386      ts_c

Seperti yang Anda lihat, pengenal numerik dari tautan simbolik dipetakan ke nama mnemonik dari tablespaces. Dari contoh di atas, Anda dapat mengamati bahwa ada juga dua tablespaces khusus:

  • pg_default adalah tablespace default yang sesuai dengan “tidak ada”, penyimpanan default yang digunakan untuk setiap objek ketika tidak ada yang ditentukan secara eksplisit. Dengan kata lain, setiap objek yang disimpan langsung di bawah direktori PGDATA terhubung ke tablespace pg_default.

  • pg_global adalah tablespace yang digunakan untuk objek yang berlaku untuk seluruh sistem.

Secara default, kedua tablespaces di atas merujuk langsung ke direktori PGDATA, yang berarti klaster tanpa tablespace kustom sepenuhnya terkandung dalam direktori PGDATA.

Menjelajahi File Konfigurasi dan Parameter

File konfigurasi utama untuk PostgreSQL adalah postgresql.conf, sebuah file berbasis teks yang mengatur klaster saat dimulai.

Biasanya, saat mengubah konfigurasi klaster, Anda harus mengedit file postgresql.conf untuk menulis pengaturan baru dan, tergantung pada konteks pengaturan yang Anda edit, mengeluarkan sinyal SIGHUP klaster (yaitu, memuat ulang konfigurasi) atau memulai ulang.

Setiap parameter konfigurasi dikaitkan dengan konteks, dan tergantung pada konteks, Anda dapat menerapkan perubahan dengan atau tanpa restart klaster. Konteks yang tersedia adalah sebagai berikut:

  • internal: Sekelompok parameter yang ditetapkan saat kompilasi dan oleh karena itu tidak dapat diubah saat runtime.

  • postmaster: Semua parameter yang memerlukan klaster untuk dimulai ulang (yaitu, membunuh proses postmasterdan memulainya lagi) untuk mengaktifkannya.

  • sighup: Semua parameter konfigurasi yang dapat diterapkan dengan sinyal SIGHUP yang dikirim ke proses postmaster, yang setara dengan mengeluarkan sinyal reload di manajer layanan sistem operasi.

  • backend dan superuser-backend: Semua parameter yang dapat diatur saat runtime tetapi akan diterapkan pada koneksi normal atau administratif berikutnya.

  • user dan superuser: Sekelompok pengaturan yang dapat diubah saat runtime dan segera aktif untuk koneksi normal dan administratif.

Parameter konfigurasi akan dijelaskan nanti dalam buku ini, tetapi berikut adalah contoh file konfigurasi minimal dengan beberapa pengaturan berbeda:

$ cat /postgres/16/data/postgresql.conf
shared_buffers = 512MB
maintenance_work_mem = 128MB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
work_mem = 32MB
min_wal_size = 1GB
max_wal_size = 2GB

File postgresql.auto.conf memiliki sintaks yang sama dengan file postgresql.conf utama tetapi secara otomatis ditimpa oleh PostgreSQL ketika konfigurasi diubah saat runtime langsung dalam sistem, melalui pernyataan administratif khusus seperti ALTER SYSTEM. File postgresql.auto.conf selalu dimuat pada saat terakhir, sehingga menimpa pengaturan lain. Dalam instalasi baru, file ini kosong, yang berarti tidak akan menimpa pengaturan kustom lainnya.

Anda tidak terikat untuk memiliki satu file konfigurasi, dan, faktanya, ada direktif khusus yang dapat digunakan untuk menyertakan file konfigurasi lain. Konfigurasi klaster akan dijelaskan secara rinci di bab berikutnya.

File HBA PostgreSQL (pg_hba.conf) adalah file teks lain yang berisi izin koneksi: ini mencantumkan basis data, pengguna, dan jaringan yang diizinkan untuk terhubung ke klaster Anda. Metode HBA dapat dianggap sebagai firewall yang tertanam dalam PostgreSQL. Sebagai contoh, berikut adalah kutipan dari file pg_hba.conf:

host    all    luca     192.168.222.1/32    md5
hostssl all    enrico   192.168.222.1/32    md5

Secara singkat, baris di atas berarti bahwa pengguna luca dapat terhubung ke basis data apa pun di klaster dari mesin dengan alamat IPv4 192.168.222.1, sedangkan pengguna enrico dapat terhubung ke basis data apa pun dari mesin yang sama tetapi hanya pada koneksi yang dienkripsi SSL. Semua aturan pg_hba.conf yang tersedia akan dijelaskan secara rinci di bab berikutnya, tetapi untuk saat ini, cukup ketahui bahwa file ini bertindak sebagai “daftar aturan firewall” untuk koneksi yang masuk.

Ringkasan

PostgreSQL dapat menangani beberapa basis data dalam satu klaster, yang disajikan dari penyimpanan disk yang terkandung dalam satu direktori bernama PGDATA. Klaster menjalankan banyak proses berbeda; salah satunya, khususnya, dinamakan postmaster dan bertugas menelurkan proses lain, satu per koneksi klien, dan melacak status proses pemeliharaan.

Konfigurasi klaster dikelola melalui file konfigurasi berbasis teks, yang utama adalah postgresql.conf. Anda dapat memfilter koneksi pengguna yang masuk melalui aturan yang ditempatkan di file teks pg_hba.conf.

Anda dapat berinteraksi dengan status klaster melalui alat pg_ctl atau, tergantung pada sistem operasi Anda, melalui program lain yang disediakan, seperti service atau systemctl.

Bab ini telah memberikan informasi yang relevan sehingga Anda tidak hanya dapat menginstal PostgreSQL tetapi juga memulai dan menghentikannya secara teratur, mengintegrasikannya dengan sistem operasi Anda, dan terhubung ke klaster.

Di bab berikutnya, Anda akan belajar cara mengelola pengguna dan koneksi.

PreviousPostgreSQL → IntroductionNextPostgreSQL → Managing Users and Connections

Last updated