OmniDB adalah alat manajemen database grafis sumber terbuka yang dikembangkan oleh 2ndQuadrant, pemimpin dunia dalam teknologi dan layanan PostgreSQL. OmniDB adalah alat klien universal berbasis browser yang dapat mengelola mesin basis data utama seperti PostgreSQL, MariaDB, MySQL, dan Oracle. Mesin lain yang akan segera didukung termasuk SQLite, Firebird, MS SQL Server, dan IBM DB2.
Seperti perangkat lunak klien basis data yang luar biasa, OmniDB juga memberdayakan pengguna dengan beberapa fitur hebat. Ini termasuk kemampuan untuk membuat dan menyesuaikan dasbor pemantauan kinerja database. Dalam seri artikel dua bagian ini, kita akan mempelajari cara menggunakan unit pemantauan bawaan OmniDB – umumnya dikenal sebagai “widget” dalam istilah dasbor – untuk membangun dasbor pemeriksaan kesehatan kinerja untuk kluster replikasi PostgreSQL 12.
Lingkungan Pengujian
Lingkungan pengujian kami adalah kluster PostgreSQL 12 dua simpul, berjalan di AWS VPC di wilayah us-east-1. VPC mencakup tiga zona ketersediaan dan memiliki tiga subnet. Setiap subnet berada dalam Availability Zone (AZ) yang terpisah. Node utama dan node siaga terletak di dua subnet ini. Node keduanya adalah tipe instans t2.large EC2 dan akan menjalankan PostgreSQL 12 open-source. Node utama akan mereplikasi ke node siaga.
Juga akan ada "node pemantauan" yang menjalankan versi terbaru dari alat manajemen basis data OmniDB 2ndQuadrant. Node ini tidak akan menjadi bagian dari cluster PostgreSQL, tetapi akan dihosting di subnet ketiga VPC, di AZ lain. OmniDB akan dapat terhubung ke master dan node siaga dan memeriksa kinerjanya. Node OmniDB akan menjadi instans t2.medium EC2.
Ketiga node akan menjalankan Red Hat Enterprise Linux (RHEL) 8. Gambar di bawah menunjukkan arsitektur yang disederhanakan:
Skenario Pengujian
Setelah cluster dan OmniDB diatur, kita akan mendaftarkan kedua node PostgreSQL di OmniDB. Kami kemudian akan mengenal beberapa unit pemantauan standar di OmniDB, dan melihat metrik kinerja dari kedua node cluster. Kami kemudian akan menjalankan tes beban di node utama menggunakan pgbench. Idealnya, uji beban harus dimulai dari mesin terpisah, tetapi dalam kasus ini, kami akan menjalankannya secara lokal. Kami kemudian akan melihat bagaimana dasbor pemantauan OmniDB menunjukkan perubahan di berbagai penghitung kinerja saat beban berubah.
Menyiapkan Lingkungan
Langkah 1:Memasang Cluster Replikasi PostgreSQL 12
Untuk membuat cluster PostgreSQL dua simpul, kami mengikuti langkah-langkah yang dijelaskan dalam blog 2ndQuadrant yang diterbitkan sebelumnya. Pembaca dapat memeriksa artikel ini untuk melihat cara kami memasang kluster tiga simpul dengan simpul saksi menggunakan produk Kuadran ke-2 lainnya yang disebut repmgr . Untuk pengaturan kami saat ini, kami mengikuti langkah yang sama menggunakan repmgr untuk membuat kluster dua simpul, bukan tiga simpul. Juga, cluster replikasi tidak akan memiliki node saksi. Untuk menyederhanakannya, artikel ini tidak menunjukkan detail instalasi dan langkah-langkah konfigurasi.
Setelah cluster kami disiapkan, kami dapat mengonfirmasi fungsinya dengan menanyakan tampilan pg_stat_replication dari node utama:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsnFROM pg_stat_replication;
Langkah 2:Memasang dan Mengonfigurasi Server OmniDB
OmniDB diakses menggunakan URL, yang berarti di belakang layar, ia menjalankan server webnya sendiri. Ada dua rasa OmniDB:
- Aplikasi OmniDB :Ini biasanya dijalankan dari workstation dan berperilaku seperti aplikasi desktop biasa. OmniDB menjalankan server web pada port acak, dan tidak diperlukan penyiapan tambahan.
- Server OmniDB :Ini untuk menginstal OmniDB pada server jaringan untuk mode multi-pengguna. Dalam mode server, kita dapat menentukan nomor port untuk mengakses URL, enkripsi SSL URL, load balancing dan reverse proxy, akses passthrough SSH ke node database, dan membuat akun pengguna untuk akses.
Untuk skenario pengujian kami, kami akan menginstal server OmniDB di node OmniDB EC2. Pertama, kami mengunduh paket terbaru dari situs OmniDB:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
Selanjutnya, kita memulai instalasi. Di sini, kami menginstal OmniDB sebagai pengguna root, tetapi Anda dapat menggunakan pengguna lain mana pun asalkan memiliki hak yang benar:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpmMemverifikasi... ################################# #### [100%]Menyiapkan... ######################################################## [100%]Memperbarui / install... 1:omnidb-server-2.17.0-0 ############################################ [ 100%]
Setelah paket terinstal, kita dapat memulai OmniDB dari command prompt:
# server omnidb
Ini menunjukkan server mulai:
Memulai websocket OmniDB...Memeriksa ketersediaan port...Memulai server websocket pada port 25482 .Memulai server OmniDB...Memeriksa ketersediaan port...Memulai server OmniDB 2.17.0 pada 127.0.0.1:8000 .Memulai migrasi database pengguna dari versi 0.0.0 ke versi 2.17.0...OmniDB berhasil memigrasikan database pengguna dari versi 0.0.0 ke versi 2.17.0Buka OmniDB di browser favorit AndaTekan Ctrl+C untuk keluar
Kita dapat melihat OmniDB telah memilih port server web default 8000 dan server websocket default pada port 25482.
Kami menekan Ctrl+C untuk menghentikan proses server dan menelusuri direktori home dari pengguna root. Kita bisa melihat ada folder tersembunyi bernama .omnidb . Di bawah folder ini, ada subdirektori bernama omnidb-server . Di dalam subdirektori omnidb-server, ada beberapa file:
# ls -la ~ …drwxr-xr-x. 3 root root 27 Jun 13 02:49 .omnidb ……# ls -la ~/.omnidb …drwxr-xr-x. 2 root root 106 13 Jun 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ …-rw-r--r--. 1 root root 131072 13 Jun 02:49 db.sqlite3-rw-r--r--. 1 root root 1209 13 Jun 02:49 omnidb.conf -rw-r--r--. 1 root root 116736 13 Jun 02:49 omnidb.db -rw-r--r--. 1 root root 0 Jun 13 02:49 omnidb.db.bak_2.17.0-rw-r--r--. 1 root root 579 13 Jun 02:49 omnidb.log
Setelah proses server dimulai, OmniDB menginisialisasi file-file ini. Basis data metadata OmniDB disebut omnidb.db . Ini adalah database SQLite dan berisi informasi tentang koneksi database, pengguna OmniDB, dan sebagainya. omnidb.conf file berisi opsi konfigurasi untuk server OmniDB. Jika kita membuka file ini di editor, tampilannya seperti berikut:
# File konfigurasi Server OmniDB[server web]# Alamat apa yang didengarkan server web, 0.0.0.0 mendengarkan semua alamat yang terikat ke mesinlistening_address =127.0.0.1 # Port server web, jika port sedang digunakan, port acak lain akan dipilihlistening_port =8000 # Port websocket, jika port sedang digunakan, port acak lain akan dipilihwebsocket_port =25482 # Port Websocket Eksternal, gunakan parameter ini jika OmniDB tidak terlihat langsung oleh klien# external_websocket_port =25482# Parameter keamanan# is_ssl =True memerlukan parameter ssl_certificate_file dan ssl_key_file# Ini sangat disarankan untuk melindungi informasiis_ssl ssl_certificate_file =/path/to/cert_file ssl_key_file =/path/to/key_file # Trusted Origins, gunakan parameter ini jika OmniDB dikonfigurasi dengan SSL dan sedang diakses oleh domain laincsrf_trusted_origins =origin1,origin2,origin3# Jalur url untuk mengakses OmniDB, defaultnya kosongpath = [queryserver]# Jumlah maksimum utas yang dapat digunakan oleh setiap permintaan pencarian objek lanjutanthread_pool_max_workers =2 # Jumlah detik antara setiap permintaan kata sandi prompt. Bawaan:30 menitpwd_timeout_total =1800
OmniDB menjalankan dua proses server. Salah satunya adalah server web yang menampilkan antarmuka pengguna, yang lainnya adalah server websocket. Server websocket digunakan oleh beberapa fitur aplikasi, seperti query, console, dan debugging.
Dari file konfigurasi, kita dapat melihat bahwa secara default server OmniDB menerima lalu lintas lokal (127.0.0.1) pada port server web 8000. Kami akan mengubahnya menjadi SEMUA alamat IP. Kecuali mesin berada di belakang proxy terbalik, sangat disarankan untuk menggunakan enkripsi SSL untuk koneksi HTTP ke server. Dalam contoh kita, kita akan meninggalkan is_ssl parameter ke "False" karena kami akan meruntuhkan mesin ini setelah pengujian kami selesai. Kami juga akan mengubah port server web menjadi 8080, dan menjaga port server websocket ke nilai default 25482.
Setelah perubahan dibuat, file konfigurasi akan terlihat seperti ini:
Pre> [WebServer] listening_address =0.0.0.0listening_port =8080WebSocket_port =25482is_ssl =falsessl_certificate_file =/path/to/cert_filessl_key_file =pound. out -time/to outly3, outerix =fiREOL1, KETICEOL1, KETIR -OUTION =PREOL1, KETIR -OUTION =/TOURICEOR =PREOL1.>Dengan perubahan yang dibuat dan disimpan, kami menjalankan aplikasi lain bernama omnidb-config-server . Alat ini dapat digunakan untuk melakukan beberapa konfigurasi tambahan seperti:
- Mengkosongkan database SQLite database OmniDB
- Setel ulang database lama dan buat yang baru
- Hapus file sementara
- Buat direktori home baru untuk database dan file konfigurasi
- Buat pengguna super untuk masuk ke OmniDB
Meskipun kami akan masuk ke OmniDB menggunakan akun pengguna admin yang dibuat secara default, kami akan membuat pengguna super lain di sini. Ini bisa berguna jika kita ingin membuat akun DBA individual di OmniDB. Cuplikan di bawah menunjukkan ini:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123Membuat superuser...Superuser dibuat.
Dengan pengguna super yang dibuat, kami memulai proses server omnidb lagi:
# omnidb-serverMemulai OmniDB websocket...Memeriksa ketersediaan port...Memulai server websocket pada port 25482.Memulai server OmniDB...Memeriksa ketersediaan port...Memulai server OmniDB 2.17.0 pada 0.0.0.0:8080. Database pengguna versi 2.17.0 sudah cocok dengan versi server.Buka OmniDB di browser favorit AndaTekan Ctrl+C untuk keluar
Sebelum mengakses antarmuka OmniDB, kami juga menambahkan port 8080, dan port 25482 ke grup keamanan instans EC2:
Langkah 3:Mengakses Antarmuka OmniDB
Browsing ke alamat publik dan node OmniDB sekarang menampilkan layar login:
Kami menentukan nama pengguna default "admin" dan kata sandinya, "admin". Ini memungkinkan kita masuk ke antarmuka OmniDB utama. Layar pertama ditunjukkan di bawah ini:
Selanjutnya, kita klik ikon “Kelola Pengguna” di pojok kanan atas layar:
Dan ubah kata sandi default pengguna admin:
Setelah selesai, kami mengklik tombol "Simpan Data" untuk memperbarui kata sandi. Seperti yang Anda lihat, kami juga dapat membuat pengguna baru dari layar ini.
Dari sudut kiri atas layar, kami mengklik tautan "Koneksi", dan kemudian dari kotak dialog yang dihasilkan, klik tombol "Koneksi Baru":
Kami kemudian menentukan detail koneksi untuk node PostgreSQL utama dan klik tombol “Simpan Data”:
Setelah koneksi tersimpan, kita klik ikon koneksi (tanda centang hijau) dari kolom “Actions”.
Ini membuka tab baru yang menunjukkan koneksi database. Seperti yang ditunjukkan di sini, kami terhubung ke node PostgreSQL utama di sini:
Kami mengikuti proses yang sama untuk mendaftarkan node siaga:
Langkah 4:Memulihkan Contoh Basis Data
Kami sekarang memulihkan database sampel di instance PostgreSQL utama. Basis data ini disebut "DVDRental" dan dapat diunduh secara gratis dari situs Tutorial PostgreSQL. Kami telah membuka ritsleting file yang diunduh dan mengekstrak file sumber ke dalam subdirektori di bawah folder /tmp dari node utama:
[[email protected] dvdrental] # ls -latotal 2796drwxr-xr-x. 2 root root 280 16 Jun 11:32 .drwxrwxrwt. 9 root root 257 16 Jun 11:31 ..-rw-------. 1 postgres postgres 57147 12 Mei 2019 3055.dat-rw-------. 1 postgres postgres 8004 12 Mei 2019 3057.dat-rw-------. 1 postgres postgres 483 12 Mei 2019 3059.dat-rw-------. 1 postgres postgres 333094 12 Mei 2019 3061.dat-rw-------. 1 postgres postgres 149469 12 Mei 2019 3062.dat-rw-------. 1 postgres postgres 26321 12 Mei 2019 3063.dat-rw-------. 1 postgres postgres 46786 12 Mei 2019 3065.dat-rw-------. 1 postgres postgres 21762 12 Mei 2019 3067.dat-rw-------. 1 postgres postgres 3596 12 Mei 2019 3069.dat-rw-------. 1 postgres postgres 140422 12 Mei 2019 3071.dat-rw-------. 1 postgres postgres 263 12 Mei 2019 3073.dat-rw-------. 1 postgres postgres 718644 12 Mei 2019 3075.dat-rw-------. 1 postgres postgres 1214420 12 Mei 2019 3077.dat-rw-------. 1 postgres postgres 271 12 Mei 2019 3079.dat-rw-------. 1 postgres postgres 57 12 Mei 2019 3081.dat-rw-------. 1 postgres postgres 45872 12 Mei 2019 restore.sql-rw-------. 1 postgres postgres 55111 12 Mei 2019 toc.dat
Selanjutnya, kita menjalankan perintah shell berikut di instance PostgreSQL utama (PG-Node1). Perintah ini membuat beberapa perubahan pada file restore.sql:
- Hapus semua kemunculan “$$PATH$$/”. Ini memastikan skrip dapat menemukan semua file data di direktori yang sama
- Ubah semua kemunculan “English_United States.1252” menjadi “en_US.UTF-8”. Ini memastikan tidak ada kesalahan karena lokal yang hilang saat skrip dijalankan.
- Ubah perintah “DROP DATBASE dvdrental” menjadi “DROP DATBASE IF EXISTS dvdrental”, sehingga tidak muncul error database yang tidak valid.
# sed -i 's/$$PATH$$\//\/tmp\/dvdrental\//g' /tmp/dvdrental/restore.sql# sed -i 's/English_United States.1252/en_US .UTF-8/g' /tmp/dvdrental/restore.sql# sed -i 's/DROP DATABASE dvdrental;/DROP DATABASE IF EXIST dvdrental;/g' /tmp/dvdrental/restore.sql
Selanjutnya, kita beralih ke pengguna postgres dan menjalankan perintah berikut dari prompt shell:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Ini memulihkan database sampel di node utama. Jika kita cek dari OmniDB, kita bisa melihat database sudah dibuat:
Kesimpulan
Kami sekarang memiliki kluster PostgreSQL yang berfungsi penuh dan instans OmniDB yang berjalan di AWS. OmniDB dapat terhubung ke kedua node cluster. Kami juga telah memulihkan database di node utama yang sedang direplikasi ke standby.
Pengaturan lingkungan sekarang selesai. Di bagian kedua artikel ini, kita akan mulai membuat dasbor pemantauan kinerja untuk instance utama.
