RDBMS dengan MariaDB

Bab 19 menutup pembahasannya melalui sebuah fork: Widenius menyalin source code MySQL pada tahun 2009 lalu mengembangkannya secara independen menjadi MariaDB setelah Oracle mengakuisisi Sun Microsystems. Bab 20 melanjutkan pembahasan tersebut dengan mempraktikkan secara langsung RDBMS hasil fork tersebut, yang saat ini justru menjadi pilihan default dan lebih diutamakan oleh Ubuntu dibandingkan MySQL di sejumlah tooling resminya. Kita akan menginstal MariaDB 11.8, mengenal toolchain command line native-nya yang sudah meninggalkan penamaan mysql*, mengelola user dan privilege melalui fitur role yang tidak dimiliki oleh MySQL, serta memahami satu breaking change penting pada mariadb-dump yang dapat menyebabkan proses restore database gagal total jika tidak diantisipasi.

20.1 Instalasi MariaDB 11.8 di Ubuntu 26.04

Ubuntu 26.04 LTS menyediakan MariaDB 11.8 secara langsung dari repository resminya, tanpa perlu menambahkan repository pihak ketiga milik MariaDB Foundation. MariaDB 11.8 merupakan rilis Long Term Support (LTS) dengan dukungan keamanan hingga Juni 2028, menggantikan MariaDB 11.4 sebagai versi LTS sebelumnya. Rilis ini membawa banyak fitur baru dibandingkan versi 11.4, mulai dari tipe data VECTOR untuk kebutuhan pencarian similarity berbasis AI, default character set utf8mb4 untuk dukungan Unicode penuh termasuk emoji, hingga plugin autentikasi baru bernama PARSEC.

20.1.1 Instalasi Paket dari Repository Ubuntu

Langkah Praktik

1. Perbarui daftar paket, lalu pasang MariaDB server.

   sudo apt update
   sudo apt install mariadb-server

   Paket mariadb-server mengunduh mariadb-server-core dan mariadb-client sebagai dependency, mengikuti pola meta-package yang sama seperti mysql-server pada Bagian 19.2.1.
2. Proses instalasi secara otomatis membuat data directory di /var/lib/mysql, yakni path yang sama persis dengan MySQL karena keduanya berbagi warisan struktur data yang sama sejak sebelum terjadi fork. Konfirmasikan bahwa service telah berjalan melalui unit mariadb.service.

   sudo systemctl status mariadb

3. Konfirmasikan versi yang benar-benar terpasang.

   mariadb --version

   Output yang muncul kurang lebih berformat mariadb from 11.8.x-MariaDB, dengan angka minor yang dapat berbeda tergantung waktu terakhir repository Ubuntu disinkronkan.

Verifikasi dan Troubleshooting

• Output systemctl status yang normal menampilkan status active (running). Jika gagal untuk start, periksa log melalui perintah sudo journalctl -u mariadb -n 50.
• Catatan lapangan yang sangat penting: MariaDB dan MySQL berbagi data directory /var/lib/mysql serta port default 3306 yang sama persis. Kedua service ini tidak boleh berjalan secara bersamaan di dalam satu server yang sama. Jika mesin lab yang digunakan masih menyisakan instalasi MySQL dari Bab 19, hentikan dan hapus terlebih dahulu paket tersebut sebelum memasang MariaDB, atau gunakan VM/container terpisah untuk masing-masing bab database pada Bagian V ini.

  sudo systemctl stop mysql
  sudo apt purge mysql-server mysql-client mysql-common

• Berbeda dari MySQL yang menamai binary daemon-nya sebagai mysqld di seluruh versi, MariaDB menamai daemon-nya sebagai mariadbd, dengan mysqld tetap disediakan sebagai symlink untuk kompatibilitas, mengikuti pola yang sama seperti symlink command line tools yang dibahas pada Bagian 20.2.

20.1.2 Mengamankan Instalasi dengan mariadb-secure-installation

Sejak MariaDB 10.4, plugin autentikasi unix_socket telah aktif secara default untuk account root@localhost, sama seperti auth_socket di MySQL yang telah kita praktikkan pada Bagian 19.2.2. Konsekuensinya, script pengaman instalasi bawaan MariaDB tidak perlu lagi menanyakan hal terkait migrasi ke unix_socket seperti pada versi-versi lama, karena kondisi tersebut sudah otomatis terpenuhi sejak proses instalasi selesai.

Langkah Praktik

1. Buktikan terlebih dahulu cara kerja unix_socket dengan masuk sebagai root tanpa menggunakan password.

   sudo mariadb

   Ketik exit untuk keluar setelah prompt MariaDB [(none)]> muncul.
2. Jalankan script pengamanan instalasi.

   sudo mariadb-secure-installation

3. Script akan menampilkan serangkaian pertanyaan Y/n secara berurutan. Jawablah sesuai tabel berikut untuk lingkungan lab yang aman untuk dipraktikkan.

   Enter current password for root (enter for none): [langsung Enter]
   Change the root password? [Y/n] n
   Remove anonymous users? [Y/n] Y
   Disallow root login remotely? [Y/n] Y
   Remove test database and access to it? [Y/n] Y
   Reload privilege tables now? [Y/n] Y

   Menjawab n pada pertanyaan penggantian password root merupakan pilihan yang tepat di sini, karena root telah dikunci melalui unix_socket dan tidak membutuhkan password untuk digunakan secara lokal oleh Sysadmin.

Verifikasi dan Troubleshooting

• Pesan penutup Thanks for using MariaDB! menandakan bahwa seluruh langkah telah berhasil diterapkan.
• Perintah mysql_secure_installation tanpa prefix mariadb- tetap dapat digunakan dan menghasilkan output yang identik, karena keduanya saat ini hanyalah dua nama untuk binary yang sama, sebagaimana dibahas lebih mendalam pada Bagian 20.2.
• Sama seperti catatan pada Bagian 19.2.2, account dengan password tetap wajib disiapkan secara terpisah dari root untuk kebutuhan tool berbasis web seperti phpMyAdmin pada Bab 22, karena unix_socket hanya berfungsi untuk koneksi lokal melalui Unix socket, bukan melalui TCP.

20.2 Toolchain Native dan Symlink mysql* yang Mulai Ditinggalkan

Sysadmin yang terbiasa mengetik perintah mysql, mysqldump, atau mysqladmin pada server MySQL akan menemukan hal yang berbeda saat mengetikkan perintah yang sama di server MariaDB modern. Sejak MariaDB 10.5, mayoritas command line tools telah diubah namanya menjadi mariadb-* agar identitas proyek terpisah semakin jelas dari MySQL, sebagai bagian dari upaya MariaDB Foundation dalam membangun ekosistemnya sendiri setelah lebih dari satu dekade mempertahankan kompatibilitas penuh dengan nama-nama lama.

20.2.1 Perubahan Nama Command Line Tools Sejak MariaDB 10.5

Tabel berikut merangkum pemetaan nama lama ke nama baru yang perlu diingat oleh Sysadmin saat menulis script atau dokumentasi baru untuk server MariaDB.

Ubuntu tetap memasang seluruh nama lama tersebut sebagai symlink yang mengarah ke binary baru, sehingga script lama, tool pihak ketiga, maupun kebiasaan mengetik Sysadmin yang sudah berlangsung bertahun-tahun tidak langsung rusak setelah instalasi MariaDB selesai.

20.2.2 Membuktikan Symlink dan Peringatan Deprecation

Langkah Praktik

1. Periksa secara langsung target symlink mysql di dalam direktori binary.

   ls -la /usr/bin/mysql /usr/bin/mariadb

   Output menunjukkan bahwa /usr/bin/mysql merupakan symlink yang mengarah ke /usr/bin/mariadb, bukan binary yang terpisah.
2. Jalankan perintah lama untuk melihat peringatan deprecation yang muncul.

   mysql --version

   mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
   mariadb from 11.8.x-MariaDB

Verifikasi dan Troubleshooting

• Peringatan tersebut tampil ke stderr dan tidak menghentikan eksekusi perintah, sehingga script otomasi lama yang masih memanggil mysql atau mysqldump tetap berfungsi dengan normal untuk saat ini, hanya saja outputnya menjadi sedikit berisik karena adanya baris peringatan tambahan.
• Catatan lapangan: karena peringatan ini secara eksplisit menyebutkan rencana removal di masa depan, kebiasaan menulis script backup, monitoring, atau CI/CD baru sebaiknya langsung menggunakan nama mariadb-* sejak awal, bukan menunda migrasi hingga symlink tersebut benar-benar dihapus dari repository resmi.
• Jika suatu tool pihak ketiga (misalnya panel hosting atau tool migrasi database) gagal mem-parsing output akibat baris peringatan tambahan ini, opsi paling aman adalah memanggil binary mariadb-* secara langsung pada konfigurasi tool tersebut, bukan mematikan peringatannya.

20.3 Manajemen User, Privilege, dan Role

Skenario pada bagian ini meneruskan kebutuhan Developer yang sama seperti pada Bab 18 dan 19: database aplikasi bernama webapp_db, kali ini di instance MariaDB, beserta account terpisah dari root. MariaDB mewarisi model account 'user'@'host' milik MySQL yang telah dibahas pada Bagian 19.3.1 secara utuh, namun menambahkan satu fitur yang justru tidak dimiliki oleh MySQL edisi Community: role penuh untuk pengelompokan privilege yang reusable.

20.3.1 Membuat Database dan User Aplikasi

Langkah Praktik

1. Masuk ke MariaDB sebagai root melalui socket.

   sudo mariadb

2. Buat database baru untuk aplikasi.

   CREATE DATABASE webapp_db;

3. Buat account baru khusus untuk koneksi lokal. Ganti nilai password contoh ini dengan password yang kuat milik sendiri sebelum dipraktikkan di server sungguhan.

   CREATE USER 'webapp_user'@'localhost' IDENTIFIED BY 'M4riaAmanSekali!2026';
   GRANT ALL PRIVILEGES ON webapp_db.* TO 'webapp_user'@'localhost';

4. Keluar dari sesi root, lalu uji login menggunakan account baru.

   exit
   mariadb -u webapp_user -p webapp_db

Verifikasi dan Troubleshooting

• Login yang berhasil ditandai dengan prompt yang berubah menjadi MariaDB [webapp_db]>. Jalankan perintah SELECT DATABASE(), CURRENT_USER(); untuk memastikan sesi benar-benar terhubung sebagai webapp_user@localhost.
• Account baru yang dibuat melalui perintah CREATE USER ... IDENTIFIED BY menggunakan plugin mysql_native_password secara default, berbeda dari root yang menggunakan unix_socket. Perilaku ini konsisten dengan penjelasan pada Bagian 20.1.2: unix_socket hanya secara otomatis digunakan untuk root@localhost bawaan instalasi, bukan untuk account yang dibuat secara manual setelahnya.
• Pesan error yang muncul mengikuti format yang identik dengan MySQL pada Bagian 19.3.2, karena MariaDB mewarisi seluruh kode error dari basis MySQL sebelum terjadinya fork.

20.3.2 Role-Based Access Control dengan CREATE ROLE

MySQL Community baru mendapatkan fitur role pada versi 8.0, sedangkan MariaDB sudah memilikinya sejak versi 10.0.5. Role memisahkan definisi sekumpulan privilege dari account yang menggunakannya, sehingga Sysadmin cukup mengubah privilege pada satu tempat (role) daripada mengulang perintah GRANT yang sama di banyak account satu per satu. Pola ini sangat membantu saat mengelola tim Developer yang jumlah anggotanya terus bertambah.

Langkah Praktik

1. Sebagai root, buat role baru untuk kebutuhan akses read-only.

   sudo mariadb

   CREATE ROLE 'app_readonly';
   GRANT SELECT ON webapp_db.* TO 'app_readonly';

2. Buat account baru untuk anggota tim reporting, lalu berikan role tersebut kepadanya.

   CREATE USER 'webapp_readonly'@'localhost' IDENTIFIED BY 'B4caSajaMaria!2026';
   GRANT 'app_readonly' TO 'webapp_readonly'@'localhost';

3. Jadikan role ini aktif secara otomatis setiap kali webapp_readonly login, tanpa perlu mengetikkan SET ROLE secara manual pada setiap sesi.

   SET DEFAULT ROLE 'app_readonly' FOR 'webapp_readonly'@'localhost';

Verifikasi dan Troubleshooting

• Login sebagai webapp_readonly, lalu periksa role yang sedang aktif pada sesi yang berjalan.

  mariadb -u webapp_readonly -p webapp_db -e "SELECT CURRENT_ROLE();"

  Hasilnya harus menampilkan app_readonly, bukan NULL, yang membuktikan bahwa default role bekerja tanpa perlu mengeksekusi SET ROLE secara manual.
• Privilege yang diberikan ke sebuah role tidak secara otomatis berlaku bagi user yang memegangnya kecuali role tersebut sedang aktif di sesi, baik melalui default role seperti di atas maupun melalui perintah SET ROLE 'app_readonly'; yang dijalankan secara manual di awal sesi. Kekeliruan umum bagi Sysadmin yang baru berpindah dari MySQL adalah lupa mengaktifkan default role, kemudian bingung mengapa GRANT ke role terasa tidak berpengaruh pada user yang memegangnya.
• Menambahkan privilege baru ke role yang sudah ada, misalnya GRANT SELECT ON another_db.* TO 'app_readonly';, secara otomatis berlaku untuk seluruh user yang memegang role tersebut tanpa perlu mengulangi GRANT satu per satu ke setiap account. Hal ini menjadi keunggulan utama role dibandingkan pemberian privilege secara langsung ke user seperti pada Bagian 20.3.1.

20.3.3 Audit Privilege dengan SHOW GRANTS

Proses audit mengenai hak akses user menjadi jauh lebih penting ketika jumlah user dan role sudah bertambah banyak, terutama menjelang proses compliance atau audit keamanan yang dibahas lebih mendalam pada Bab 34.

SHOW GRANTS FOR 'webapp_readonly'@'localhost';
SHOW GRANTS FOR 'app_readonly';

Verifikasi dan Troubleshooting

• Perintah pertama menampilkan privilege langsung milik webapp_readonly beserta role yang dipegangnya, sedangkan perintah kedua menampilkan isi privilege role app_readonly itu sendiri, yang merupakan cara cepat untuk memisahkan antara privilege langsung dan privilege yang diperoleh melalui role.
• Login sebagai webapp_readonly lalu mencoba perintah INSERT harus gagal dengan pesan ERROR 1142 (42000): INSERT command denied to user. Hal ini membuktikan bahwa privilege read-only benar-benar diterapkan melalui role, bukan sekadar tampil di SHOW GRANTS tanpa efek nyata.

20.4 Breaking Change Format mariadb-dump Sejak Versi 11.0

Nama mysqldump secara resmi dihapus total pada MariaDB 11.0 dan digantikan oleh mariadb-dump sebagai satu-satunya nama native, konsisten dengan pola rename yang telah dibahas pada Bagian 20.2.1. Perubahan nama itu sendiri sebenarnya tidak berbahaya karena symlink kompatibilitas tetap tersedia, namun terdapat satu perubahan lain yang jauh lebih berisiko secara diam-diam menggagalkan proses restore database jika Sysadmin tidak menyadarinya terlebih dahulu.

20.4.1 Sandbox Mode: Mitigasi Celah Keamanan pada Proses Restore

Mulai dari MariaDB 10.5.25, 10.6.18, 10.11.8, 11.0.6, 11.1.5, 11.2.4, 11.4.2, dan seluruh rilis setelahnya termasuk versi 11.8 yang kita gunakan pada bab ini, mariadb-dump secara otomatis menyisipkan satu baris directive khusus pada baris pertama setiap file dump yang dihasilkan.

/*!999999\- enable the sandbox mode */

Directive ini adalah mitigasi resmi yang dilacak MariaDB lewat tiket internal MDEV-21778, menutup celah keamanan pada client dump yang secara teori memungkinkan file dump hasil rekayasa pihak tidak bertanggung jawab menjalankan perintah shell berbahaya saat file tersebut di-restore melalui client command line. Sejumlah laporan keamanan pihak ketiga mengaitkan celah ini dengan CVE-2024-21096 milik client mysqldump Oracle MySQL, mengingat mariadb-dump mewarisi basis kode yang sama sebelum fork, meskipun MariaDB sendiri tidak secara eksplisit mencantumkan nomor CVE tersebut di pengumuman resminya. Saat directive ini dibaca oleh mariadb client versi yang mendukungnya, sesi restore akan langsung masuk ke sandbox mode yang memblokir seluruh perintah client seperti \! atau system yang dapat menyentuh shell, sehingga file dump yang disusupi perintah berbahaya tidak akan pernah bisa mengeksekusinya.

Langkah Praktik

1. Buat dump dari database webapp_db yang telah dibuat pada Bagian 20.3.1. Sertakan opsi --single-transaction agar dump tabel InnoDB diambil dari satu snapshot transaksi yang konsisten, tanpa mengunci tabel dan menghentikan sementara akses webapp_user yang mungkin sedang menulis data.

   mariadb-dump -u root --single-transaction webapp_db > webapp_db.sql

   Catatan dari lapangan: melewatkan opsi ini di server production yang tabelnya masih aktif menerima transaksi adalah kesalahan yang sering luput disadari Sysadmin baru, karena dump tetap berhasil dibuat tanpa mengunci tabel secara eksplisit, hanya saja konsistensi datanya tidak terjamin jika ada transaksi yang berjalan bersamaan.
2. Periksa baris pertama file hasil dump untuk membuktikan bahwa directive sandbox mode benar-benar ada.

   head -n 3 webapp_db.sql

Verifikasi dan Troubleshooting

• Baris pertama file harus berbunyi tepat /*!999999\- enable the sandbox mode */. Format komentar /*!999999 ... */ ini sebenarnya merupakan trik lama MySQL/MariaDB untuk menyembunyikan perintah dari versi server yang terlalu tua untuk mengenalnya, yang di sini digunakan untuk tujuan keamanan, bukan sekadar kompatibilitas fitur seperti biasanya.
• Masalah muncul ketika file dump ini di-restore menggunakan client yang lebih tua dari versi yang disebutkan di atas, atau menggunakan client mysql/mysqldump bawaan MySQL. Kedua jenis client tersebut tidak mengenali sintaks \- di dalam directive tersebut dan akan langsung mengeluarkan error, lalu menghentikan seluruh proses restore hanya karena satu baris pertama yang gagal di-parsing.

  ERROR 1064 (42000) at line 1: You have an error in your SQL syntax

• Skenario ini paling sering menjebak Sysadmin yang memindahkan dump dari server MariaDB baru ke server MySQL lama, ke server MariaDB versi lawas yang belum di-patch, atau ke tool migrasi pihak ketiga yang internalnya masih memanggil client mysql klasik. Kombinasi backup script otomatis dan proses restore yang jarang diuji secara berkala, sebagaimana diingatkan pada Bagian 23 nanti, membuat masalah ini sering kali baru terdeteksi justru di saat restore darurat sedang sangat dibutuhkan.

20.4.2 Menangani Ketidakcocokan Saat Restore

Cara paling aman untuk menghindari masalah ini adalah memastikan proses restore menggunakan client mariadb yang versinya telah mendukung sandbox mode, idealnya versi yang sama atau lebih baru dari server yang menghasilkan file dump tersebut. Jika target restore memang harus berupa MySQL atau MariaDB versi lawas yang belum mendukung directive ini, baris pertama tersebut dapat dihapus sebelum proses restore dijalankan.

Langkah Praktik

1. Hapus baris pertama file dump sebelum restore dengan menggunakan perintah tail untuk melewatinya.

   tail -n +2 webapp_db.sql | mariadb -u root webapp_db

2. Pola yang sama berlaku jika penghapusan directive dilakukan secara langsung pada saat proses dump, bukan saat restore. Pola ini berguna untuk pipeline backup yang memang ditargetkan untuk kompatibilitas ke sistem lama.

   mariadb-dump -u root webapp_db | tail -n +2 > webapp_db_compat.sql

Verifikasi dan Troubleshooting

• Setelah proses restore berhasil, konfirmasikan bahwa seluruh tabel dan data benar-benar utuh dengan membandingkan jumlah baris pada tabel penting, bukan hanya mengandalkan ketiadaan pesan error.
• Menghapus directive sandbox mode berarti melepaskan lapisan mitigasi keamanan yang baru saja dijelaskan pada Bagian 20.4.1. Langkah ini hanya boleh dilakukan untuk file dump yang sumbernya benar-benar terpercaya, misalnya hasil backup terjadwal milik server sendiri, bukan file dump yang diterima dari pihak luar atau sumber yang belum diverifikasi.
• Solusi jangka panjang yang lebih baik daripada terus-menerus memotong baris pertama adalah menyeragamkan versi client di seluruh pipeline backup dan restore, termasuk pada server staging maupun tool migrasi pihak ketiga, agar directive sandbox mode ini dikenali secara konsisten di semua tempat.

Sampai di sini, server telah menjalankan MariaDB 11.8 lengkap dengan database webapp_db yang dikelola melalui kombinasi account dan role, terpisah secara rapi dari root yang terkunci melalui unix_socket, serta proses backup yang aman dari masalah format mariadb-dump terbaru. Bab 21 melanjutkan Bagian V dengan pendekatan yang berbeda: MongoDB sebagai database NoSQL berbasis dokumen, bukan lagi tabel dan baris seperti tiga RDBMS relasional yang telah kita pelajari di PostgreSQL, MySQL, dan MariaDB.