High Availability Yang Kantong Friendly: Database dengan Galera Cluster, ProxySQL, dan Keepalived di Ubuntu 26.04 Bagian 3

4 Juni 2026 5 Min Read

Ini adalah tulisan lanjutan dari membangun server database High Availability. Bagian 1 bisa dibaca kembali disini: High Availability Yang Kantong Friendly: Database dengan Galera Cluster, ProxySQL, dan Keepalived di Ubuntu 26.04, Bagian Kedua bisa dibaca disini: High Availability Yang Kantong Friendly: Database dengan Galera Cluster, ProxySQL, dan Keepalived di Ubuntu 26.04 Bagian 2

Tahap 3: Saatnya Pembuktian

Jadi, ketiga node sudah di set sesuai dengan posisinya masing-masing. Sekarang waktunya pembuktian apakah konfigurasi kita sudah benar atau tidak dan tujuan kita membuat High Availability berhasil.

Semua mesin sudah siap, konfigurasi sudah pas. Sekarang mari kita hidupkan satu per satu sesuai urutan yang aman untuk klaster.

Langkah 1: Inisiasi Jantung Database (Hanya di Node 1)

Masuk ke terminal Node 1, lalu bangun cluster baru:

sudo galera_new_cluster
sudo systemctl enable mariadb

Langkah 2: Gabungkan node database (Node 2 & Node 3)

Masuk ke terminal Node 2, lalu jalankan MariaDB (dia akan otomatis mencari Node 1 berdasarkan konfigurasi wsrep_cluster_address yang sudah ada):

sudo systemctl start mariadb
sudo systemctl enable mariadb

Lakukan hal yang sama di Node 3:

sudo systemctl start mariadb
sudo systemctl enable mariadb

Lalu bagaimana kita tahu kalau cluster sudah berjalan?

Untuk melakukan verifikasi, kita bisa masuk ke MariaDB di Node 1 (mariadb -u root -p)

sudo mariadb

Kemudian jalankan perintah:

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.014 sec)

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_ready';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wsrep_ready   | ON    |
+---------------+-------+
1 row in set (0.010 sec)

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_local_state_comment';
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+
1 row in set (0.003 sec)

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_connected';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| wsrep_connected | ON    |
+-----------------+-------+
1 row in set (0.005 sec)

Cara baca 4 Variabel Kunci untuk Cek Status Cluster

wsrep_cluster_size
Menunjukkan jumlah node yang saat ini aktif bergabung di dalam cluster. Sukses jika kita sudah menyalakan 3 VM VirtualBox, nilainya harus 3. Jika nilainya masih 1, berarti node lain belum berhasil terhubung.

wsrep_local_state_comment
Menunjukkan status kesehatan node tempat Anda mengetikkan perintah saat ini. Sukses jika bernilai Synced. Artinya node ini sehat, sinkron, dan siap melakukan proses baca/tulis data. Jika nilainya Joiner atau Initializing, berarti node tersebut masih dalam proses menyedot data/sinkronisasi awal.

wsrep_connected
Menunjukkan apakah node ini terhubung ke jaringan klaster (GCOMM). Sukses jika bernilai ON.

wsrep_ready
Menunjukkan apakah database siap menerima query dari aplikasi Anda. Sukses jika bernilai ON.

Jika status diatas masih kurang meyakinkan, maka kita bisa melakukan uji sinkronisasi data. Tes sederhana yang bis akita lakukan adalah, dengan login ke MariaDB di node 1, kemudian membuat sebuah database:

MariaDB [(none)]> create database test_db;
Query OK, 1 row affected (0.131 sec)

Kemudian pindah ke node 2 & 3, login ke MariaDB lalu cek apakah databasenya ada:

MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test_db            |
+--------------------+
5 rows in set (0.005 sec)

Jika database test_db otomatis muncul di sana, artinya infrastruktur High Availability untuk aplikasi kita sudah 100% berjalan dan aktif.

Langkah 3: Nyalakan ProxySQL & Eksekusi Skrip SQL (Di Ketiga Node)

Jalankan perintah ini di Node 1, Node 2, dan Node 3:

sudo systemctl start proxysql
sudo systemctl enable proxysql

Setelah ProxySQL menyala, masuk ke admin interface ProxySQL di masing-masing node untuk mengeksekusi skrip inisiasi yang sudah kita siapkan di folder home sebelumnya:

mariadb -u admin -padmin -h 127.0.0.1 -P 6032 < ~/inisiasi_proxysql.sql

Langkah 4: Hidupkan Web Server Nginx & PHP-FPM (Di Ketiga Node)

Jalankan di Node 1, Node 2, dan Node 3:

sudo systemctl start nginx php-fpm
sudo systemctl enable nginx php-fpm

Langkah 5: Aktifkan Jaring Pengaman Jaringan (Di Ketiga Node)

Terakhir, nyalakan Keepalived di Node 1, Node 2, dan Node 3:

sudo systemctl start keepalived
sudo systemctl enable keepalived

Tahap Verifikasi Akhir

Untuk memastikan semuanya sukses, jalankan perintah ini di Node 1:

ip a show enp0s8

Seharusnya kita bisa melihat IP 192.168.56.20 menempel pada interface tersebut sebagai IP sekunder (Floating IP). Jika kita mematikan Node 1, IP tersebut akan otomatis berpindah ke Node 2 saat kita mengeceknya dengan perintah yang sama di Node 2.

Kita juga bisa melakukan tes lain dengan menggunakan Web Server (Nginx) yang sudah kita install sebelumnya. Langkah ini dilakukan secara visual server mana yang sedang melayani request dari Floating IP saat pengujian failover. Caranya adalah:

Buka browser di PC, lalu akses Floating IP: http://192.168.56.20.
Browser Anda seharusnya memunculkan tulisan: Halo dari NODE 1 (kredensial Keepalived Node 1 adalah yang tertinggi, yaitu 255).
Sekarang, matikan layanan Keepalived di Node 1 untuk pura-pura crash: sudo systemctl stop keepalived
Kembali ke browser Anda dan tekan Refresh (F5).
Tampilan di browser Anda akan otomatis berubah menjadi: Halo dari NODE 2!

Atau bisa juga menggunakan curl dari command node manapun.

curl http://192.168.56.20
<h1>Halo dari NODE 1</h1>

matikan service keepalived di node 1

sudo systemctl stop keepalived

Kemudian jalankan curl kembali, seharusnya sekarang menjadi:

curl http://192.168.56.20
<h1>Halo dari NODE 2</h1>

Ini membuktikan bahwa Keepalived sukses menggeser IP ke Node 2 secara instan tanpa membuat user mendapati error page not found.

Penutup: Implementasi Riil di Cloud VPS (VirtualBox vs Production)

Infrastruktur Hyper-Converged High Availability yang kita bangun di VirtualBox ini sudah berjalan 100% sempurna secara lokal. Namun, saat Anda bermigrasi ke penyedia Cloud VPS Publik (misalnya IDCloudHost), ada satu tantangan jaringan yang wajib diketahui.

Di dunia nyata, kita tidak bisa asal menunjuk satu IP publik kosong untuk dijadikan Floating IP di file keepalived.conf. Sistem hypervisor modern milik provider VPS mengunci ketat jalur jaringan mereka (Anti-IP Spoofing) demi keamanan. Jika memaksakan protokol VRRP Keepalived murni, IP tersebut akan diblokir oleh jaringan data center.

Ada dua jalan keluar best practice untuk membawa arsitektur ini ke skala produksi:

Opsi 1: Menyewa “Floating IP / Reserved IP” Resmi dari Provider (Pendekatan API)

Hampir semua provider Cloud VPS menyediakan fitur bernama Floating IP, Reserved IP, atau Elastic IP. Biayanya bervariasi (kisaran $1 – $2 per bulan, atau mungkin gratis selama IP tersebut aktif menempel pada VPS Anda atau tergantung kebijakan provider).

Cara Kerjanya: Di level OS, Keepalived tidak lagi bertugas menggeser IP secara mandiri. Sebagai gantinya, saat Node 1 mati, Keepalived akan mengeksekusi sebuah skrip otomatis (Notification Script) yang memicu API resmi dari provider cloud tersebut untuk memindahkan rute Floating IP publik ke Node 2 di level jaringan internal mereka (Software-Defined Network).

Opsi 2: Menggunakan Round-Robin DNS (Opsi Paling “Kantong Friendly”)

Jika tidak ingin mengeluarkan biaya tambahan sepeser pun untuk menyewa Floating IP publik, kita bisa memanfaatkan fitur Round-Robin DNS (Multi-A Record).

Cara Kerjanya: Di dasbor DNS (misalnya Cloudflare), kita cukup membuat 3 buah A Record dengan nama domain yang sama (misal: sekolahawan.id), tetapi masing-masing diarahkan ke IP Publik asli dari Node 1, Node 2, dan Node 3.

Sebenarnya, jika kita mengaktifkan proxy Cloudflare, Cloudflare memiliki fitur basic failover otomatis. Jika salah satu IP VPS mendadak mati atau tidak merespons request HTTP, Cloudflare cukup pintar untuk menyisihkan IP tersebut sementara waktu dan langsung melemparkan seluruh traffic pengguna ke 2 IP VPS lainnya yang masih hidup.

Dengan Opsi 2 ini, kita bahkan tidak perlu menginstal Keepalived di level publik, dan beban traffic pengunjung web server sudah otomatis terbagi rata (load balancing) sejak dari pintu gerbang DNS.

Kesimpulan

Filosofi “High Availability yang Kantong Friendly” bukan berarti kita memotong standar keamanan. Dengan menyatukan Nginx, PHP-FPM, ProxySQL, dan MariaDB Galera Cluster ke dalam 3 node multifungsi (RAM 2GB / 2 vCPU), kita berhasil memangkas biaya sewa server hingga 50% sekaligus menciptakan sistem yang tangguh, anti-tumbang, dan siap menangani ribuan transaksi di Indonesia.

Selamat mencoba, dan mari bangun infrastruktur Indonesia yang efisien dan tepat guna.

Tags: