Database merupakan salah satu komponen paling penting dalam infrastruktur aplikasi modern. Website, sistem informasi akademik, aplikasi keuangan, layanan internal perusahaan, hingga platform pembelajaran membutuhkan database yang dapat menyimpan dan menyediakan data secara konsisten.

Masalah muncul ketika database utama mengalami gangguan. Kerusakan storage, kesalahan konfigurasi, lonjakan beban, pemeliharaan server, atau kegagalan sistem operasi dapat menyebabkan aplikasi tidak dapat mengakses data.

Salah satu pendekatan untuk mengurangi risiko tersebut adalah menggunakan MariaDB Replication dengan arsitektur Master-Replica.

Melalui mekanisme replikasi, perubahan data pada server utama dapat dikirimkan ke server replika. Server replika kemudian dapat dimanfaatkan untuk kebutuhan pembacaan data, pelaporan, backup terencana, dan sebagai kandidat pengganti server utama ketika terjadi gangguan.

Namun, ada hal penting yang perlu dipahami: MariaDB Replication tidak secara otomatis menjamin high availability atau melakukan failover. Replikasi dan pengalihan peran server merupakan dua mekanisme berbeda yang harus dirancang dan dikelola secara terpisah.

Artikel ini membahas cara membangun replikasi MariaDB pada Linux, menggunakan Debian 12/13 atau Ubuntu Server sebagai contoh lingkungan implementasi. Pembahasan mencakup konfigurasi server utama, konfigurasi replika, sinkronisasi data awal, monitoring, troubleshooting, serta prosedur failover manual.

1. Memahami MariaDB Replication Master-Replica

Apa itu MariaDB Replication?

MariaDB Replication adalah mekanisme untuk menyalin perubahan data dari satu server database ke server database lainnya.

Dalam arsitektur sederhana, terdapat dua komponen utama:

• Master atau primary: server yang menerima operasi penulisan data dan menghasilkan binary log.
• Replica: server yang membaca perubahan dari primary, kemudian menerapkannya pada database lokal.

Istilah master-slave banyak ditemukan pada dokumentasi lama. Dalam pembahasan ini, istilah master-replica digunakan untuk menjelaskan arsitektur yang sama, dengan primary dan replica sebagai istilah alternatif yang lebih umum digunakan saat ini.

Sebagai contoh, sebuah aplikasi akademik memiliki database utama pada DB01 dan server replika pada DB02.

Ketika aplikasi memasukkan data siswa baru ke DB01, perubahan tersebut dicatat dalam binary log. DB02 mengambil log yang diperlukan, membaca event perubahan, kemudian menerapkannya sehingga database replika mengikuti perubahan pada server utama.

Bagaimana alur replikasi bekerja?

Secara umum, proses replikasi berjalan melalui tiga tahapan.

1. Primary mencatat perubahan database ke binary log.
2. Replica I/O thread mengambil event log dari primary dan menyimpannya sebagai relay log.
3. Replica SQL thread atau mekanisme penerapan paralel memproses event tersebut pada database replika.

Alur sederhananya:

Aplikasi → Primary MariaDB → Binary Log → Replica I/O Thread → Relay Log → Replica SQL Thread → Database Replica

Mekanisme tersebut memungkinkan perubahan data dikirimkan tanpa aplikasi harus menulis data yang sama ke kedua server secara langsung.

Perbedaan replikasi dan backup

Keduanya sering dianggap sama, padahal tujuan dan karakteristiknya berbeda.

Aspek	Replication	Backup
Tujuan	Menyalin perubahan data ke server lain	Menyediakan salinan untuk pemulihan
Mekanisme	Mengirim dan menerapkan event log	Membuat salinan data pada titik tertentu
Perlindungan dari penghapusan tidak sengaja	Terbatas; perubahan dapat ikut direplikasi	Dapat membantu jika tersedia backup sebelum insiden
Pemulihan data historis	Bergantung pada log dan desain pemulihan	Bergantung pada retensi backup dan binary log
Ketergantungan	Memerlukan jalur komunikasi dan konfigurasi replikasi	Memerlukan media penyimpanan backup yang dapat diakses

Jika tabel penting terhapus pada primary, penghapusan tersebut dapat ikut diterapkan pada replica. Karena itu, replica tidak boleh diperlakukan sebagai satu-satunya backup.

Strategi yang baik menggabungkan replikasi, backup terpisah, retensi data, dan pengujian pemulihan secara berkala.

2. Topologi Laboratorium

Untuk memudahkan praktik, gunakan dua server Linux dengan jaringan privat.

Parameter	DB01	DB02
Peran awal	Primary	Replica
IP contoh	192.168.10.11	192.168.10.12
Database	MariaDB	MariaDB
Port database	TCP 3306	TCP 3306
Binary log	Aktif	Tidak wajib untuk replikasi satu arah sederhana
Read-only	Tidak	Ya, sesuai kebijakan
Fungsi	Membaca dan menulis data aplikasi	Replika, pelaporan, dan kandidat failover

Alamat IP di atas merupakan alamat dokumentasi untuk laboratorium. Ganti dengan alamat jaringan yang benar pada lingkungan Anda.

Pastikan kedua server memiliki konektivitas jaringan, versi MariaDB yang kompatibel, kapasitas storage memadai, sinkronisasi waktu, serta aturan firewall yang sesuai.

Untuk implementasi produksi, tentukan terlebih dahulu kebutuhan RPO (Recovery Point Objective) dan RTO (Recovery Time Objective).

RPO menjelaskan berapa banyak kehilangan data yang masih dapat diterima. RTO menjelaskan berapa lama layanan boleh mengalami gangguan sebelum kembali beroperasi.

3. Persiapan Server MariaDB

Langkah 1: Memeriksa sistem operasi dan versi MariaDB

Jalankan pada kedua server:

cat /etc/os-release
mariadb --version
systemctl status mariadb

Pastikan MariaDB telah terpasang dan layanan berjalan.

Jika belum terpasang pada Debian atau Ubuntu, instal paket yang tersedia dari repositori tepercaya:

sudo apt update
sudo apt install mariadb-server mariadb-client
sudo systemctl enable --now mariadb

Versi MariaDB dari repositori distribusi dapat berbeda. Sebaiknya gunakan versi yang telah diuji dan didukung untuk aplikasi yang dijalankan.

Langkah 2: Memeriksa jaringan

Dari DB02, uji konektivitas menuju DB01:

ping -c 4 192.168.10.11

Jika ping tidak diizinkan, gunakan pemeriksaan TCP:

nc -vz 192.168.10.11 3306

Kegagalan koneksi dapat disebabkan oleh firewall, layanan yang hanya mendengarkan pada loopback, alamat IP yang salah, atau routing yang belum benar.

Jangan membuka port 3306 ke seluruh internet. Batasi koneksi database hanya dari jaringan dan host yang diperlukan.

4. Konfigurasi MariaDB pada Primary

Langkah 1: Mengaktifkan binary logging

Lokasi konfigurasi dapat berbeda menurut distribusi dan paket MariaDB. Pada Debian/Ubuntu, konfigurasi tambahan biasanya dapat diletakkan dalam berkas seperti /etc/mysql/mariadb.conf.d/60-replication.cnf.

Buat atau edit berkas konfigurasi pada DB01:

sudo nano /etc/mysql/mariadb.conf.d/60-replication.cnf

Tambahkan konfigurasi berikut pada bagian [mariadb]:

[mariadb]
server_id=101
log_bin=/var/log/mysql/mariadb-bin
binlog_format=ROW

Penjelasan:

• server_id=101: identitas unik server dalam topologi replikasi.
• log_bin: mengaktifkan binary log dan menentukan lokasi berkas log.
• binlog_format=ROW: mencatat perubahan dalam format berbasis baris yang umumnya lebih aman untuk replikasi perubahan data yang kompleks.

Pastikan server_id berbeda pada setiap server dalam topologi.

Jika binary log sudah diaktifkan melalui konfigurasi lain, periksa konfigurasi yang efektif sebelum menambahkan parameter duplikat.

Langkah 2: Memastikan direktori log dapat digunakan

Periksa direktori dan konfigurasi logging:

sudo ls -ld /var/log/mysql
sudo mariadb -e "SHOW VARIABLES LIKE 'log_bin';"
sudo mariadb -e "SHOW VARIABLES LIKE 'log_bin_basename';"

Jika binary log diaktifkan untuk pertama kali, MariaDB mungkin perlu membuat berkas log saat layanan dimulai kembali.

Langkah 3: Memulai ulang MariaDB

Terapkan konfigurasi:

sudo systemctl restart mariadb
sudo systemctl status mariadb

Verifikasi:

SHOW VARIABLES LIKE 'server_id';
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW MASTER STATUS;

Pada versi MariaDB tertentu, SHOW MASTER STATUS dapat menjadi istilah yang masih digunakan untuk memeriksa posisi binary log. Dukungan nama perintah dan kolom keluaran bergantung pada versi. Periksa dokumentasi versi yang terpasang sebelum menggunakan sintaks alternatif.

Pastikan log_bin bernilai ON dan status binary log menampilkan file serta posisi yang valid.

Jika binary log belum aktif, jangan melanjutkan konfigurasi replica sebelum masalah tersebut diselesaikan.

5. Membuat Akun Replikasi

Akun replikasi digunakan oleh DB02 untuk mengambil binary log dari DB01.

Masuk ke MariaDB pada DB01:

sudo mariadb

Buat akun khusus untuk replikasi:

CREATE USER 'repl_user'@'192.168.10.12'
IDENTIFIED BY 'GANTI_DENGAN_PASSWORD_KUAT';

GRANT REPLICATION SLAVE ON *.*
TO 'repl_user'@'192.168.10.12';

SHOW GRANTS FOR 'repl_user'@'192.168.10.12';

Ganti alamat host sesuai IP sumber koneksi DB02 dan gunakan password acak yang kuat.

Batasi akun tersebut berdasarkan alamat host. Hindari penggunaan akun administrator untuk koneksi replikasi.

Simpan kredensial dengan aman. Dalam produksi, gunakan pengelolaan rahasia yang sesuai, pembatasan hak akses file konfigurasi, dan enkripsi koneksi bila diperlukan.

6. Menyiapkan Data Awal

Replikasi membutuhkan titik awal yang konsisten. Jika database sudah berisi data, jangan langsung mengaktifkan replikasi tanpa memastikan kondisi data awal pada DB02.

Terdapat dua pendekatan umum:

• Database baru: konfigurasi replikasi dapat dilakukan sebelum aplikasi mulai menulis data.
• Database yang sudah berjalan: ambil backup konsisten dari DB01, kemudian pulihkan backup tersebut pada DB02 sambil mencatat posisi binary log atau menggunakan mekanisme GTID yang telah direncanakan.

Untuk database yang aktif, backup harus mempertimbangkan transaksi berjalan, jenis storage engine, dan perubahan data selama proses pengambilan backup.

Jangan menggunakan hasil ekspor yang tidak konsisten sebagai dasar replikasi produksi.

Contoh menggunakan mariadb-dump

Untuk database laboratorium yang relatif kecil, Anda dapat membuat dump dengan opsi transaksi konsisten untuk tabel transaksional:

sudo mariadb-dump \
  --all-databases \
  --single-transaction \
  --master-data=2 \
  > /root/mariadb-initial.sql

Opsi --master-data=2 biasanya menyertakan informasi posisi binary log dalam bentuk komentar SQL. Periksa isi dump untuk memperoleh posisi yang sesuai.

Catatan penting:

• --single-transaction terutama memberikan konsistensi untuk tabel transaksional seperti InnoDB.
• DDL, perubahan skema bersamaan, dan tabel nontransaksional memerlukan pertimbangan tambahan.
• Dump seluruh database dapat berisi akun dan objek sistem, bergantung pada versi dan metode ekspor. Tinjau proses pemulihan sebelum digunakan pada server yang telah dikonfigurasi.
• Lindungi file dump karena dapat mengandung data sensitif.

Salin file ke DB02 melalui jalur transfer yang aman:

scp /root/mariadb-initial.sql \
  root@192.168.10.12:/root/

Setelah memastikan posisi binary log dan menyiapkan DB02, pulihkan dump pada server replika:

sudo mariadb < /root/mariadb-initial.sql

Perintah pemulihan ini merupakan contoh untuk dump yang memang dibuat dan disiapkan untuk dipulihkan pada server tersebut. Jangan mengimpor dump seluruh database secara membabi buta pada replica yang sudah berisi data penting.

7. Konfigurasi MariaDB pada Replica

Langkah 1: Mengatur server_id

Pada DB02, buat atau edit berkas konfigurasi:

sudo nano /etc/mysql/mariadb.conf.d/60-replication.cnf

Tambahkan:

[mariadb]
server_id=102
relay_log=/var/log/mysql/mariadb-relay-bin
read_only=ON

server_id=102 harus unik. relay_log menentukan lokasi relay log, sedangkan read_only=ON membantu mencegah penulisan biasa pada replica.

Perlu diketahui bahwa read_only bukan pengganti pengamanan hak akses. Akun dengan hak istimewa tertentu dapat melewati pembatasan ini, bergantung pada versi dan konfigurasi. Pengguna aplikasi biasa sebaiknya tidak memiliki hak tulis pada DB02.

Langkah 2: Memulai ulang layanan

sudo systemctl restart mariadb
sudo systemctl status mariadb

Periksa nilai konfigurasi:

SHOW VARIABLES LIKE 'server_id';
SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'relay_log%';

Pastikan nilai server_id tidak sama dengan DB01.

Langkah 3: Menghubungkan replica dengan primary

Masuk ke MariaDB pada DB02:

sudo mariadb

Untuk konfigurasi berbasis posisi binary log, gunakan file dan posisi yang diperoleh dari backup konsisten. Berikut contoh ilustratif:

CHANGE MASTER TO
  MASTER_HOST='192.168.10.11',
  MASTER_PORT=3306,
  MASTER_USER='repl_user',
  MASTER_PASSWORD='GANTI_DENGAN_PASSWORD_KUAT',
  MASTER_LOG_FILE='mariadb-bin.000001',
  MASTER_LOG_POS=12345;

START SLAVE;

Nilai MASTER_LOG_FILE dan MASTER_LOG_POS di atas hanyalah contoh. Jangan menyalin angka tersebut secara langsung ke lingkungan Anda. Gunakan posisi aktual dari backup yang dipulihkan.

Nama file binary log juga harus cocok dengan nama yang dilaporkan primary. Jangan mengasumsikan nomor file selalu 000001.

Sintaks dan nama status replikasi dapat berbeda pada versi MariaDB. Pastikan perintah sesuai dengan versi yang digunakan.

Untuk lingkungan produksi, pertimbangkan penggunaan GTID apabila sesuai dengan kebutuhan, versi, dan rancangan pemulihan. GTID dapat menyederhanakan identifikasi transaksi, tetapi tidak menghilangkan kebutuhan untuk mengelola konsistensi data dan prosedur promosi replica.

Langkah 4: Memeriksa status replikasi

Jalankan pada DB02:

SHOW SLAVE STATUS\G

Periksa kolom penting berikut:

• Slave_IO_Running: menunjukkan status thread yang mengambil event dari primary.
• Slave_SQL_Running: menunjukkan status thread yang menerapkan event.
• Seconds_Behind_Master: perkiraan keterlambatan replikasi, jika tersedia dan dapat dihitung.
• Last_IO_Error: pesan kesalahan saat mengambil event.
• Last_SQL_Error: pesan kesalahan saat menerapkan event.
• Master_Log_File dan Read_Master_Log_Pos: posisi log yang telah dibaca.
• Relay_Master_Log_File dan Exec_Master_Log_Pos: posisi log yang berkaitan dengan eksekusi.

Pada topologi yang sehat, kedua thread umumnya berjalan dan tidak ada kesalahan yang belum ditangani.

Namun, status thread berjalan tidak selalu membuktikan bahwa seluruh data sudah identik. Pemeriksaan harus mencakup keterlambatan, error, serta validasi data sesuai kebutuhan aplikasi.

8. Menguji Replikasi Data

Setelah kedua thread berjalan, lakukan pengujian pada database laboratorium.

Pada DB01:

CREATE DATABASE IF NOT EXISTS lab_replikasi;

CREATE TABLE IF NOT EXISTS lab_replikasi.uji_data (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nama VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

INSERT INTO lab_replikasi.uji_data (nama)
VALUES ('Pengujian Replikasi');

Kemudian pada DB02:

SELECT * FROM lab_replikasi.uji_data;

Jika data muncul, itu merupakan indikasi awal bahwa perubahan telah direplikasi.

Lakukan pengujian tambahan dengan memperbarui dan menghapus data di database laboratorium, kemudian pastikan hasilnya sesuai pada DB02. Jangan menggunakan tabel produksi untuk eksperimen yang dapat merusak data.

Periksa pula apakah database yang dikecualikan, filter replikasi, atau konfigurasi khusus memengaruhi hasil pengujian.

9. Monitoring MariaDB Replication

Monitoring bukan sekadar memastikan layanan MariaDB aktif. Administrator perlu mengetahui apakah replikasi berjalan, apakah ada penundaan, dan apakah replica benar-benar siap digunakan.

Monitoring melalui SQL

Pada DB02, jalankan:

SHOW SLAVE STATUS\G

Perhatikan status thread, error terakhir, posisi log, dan keterlambatan replikasi.

Seconds_Behind_Master bukan ukuran sempurna untuk seluruh kondisi. Nilainya dapat menjadi NULL, tidak mencerminkan semua transaksi yang belum diterapkan, atau tampak rendah meskipun ada masalah tertentu. Gunakan beberapa indikator secara bersamaan.

Pada DB01, periksa status binary log:

SHOW MASTER STATUS;
SHOW BINARY LOGS;

Perintah tersebut membantu memastikan binary log tersedia dan melihat file log yang ada. Jangan menghapus binary log secara manual ketika replica masih mungkin membutuhkannya.

Monitoring melalui systemd dan log

Pada kedua server:

sudo systemctl status mariadb
sudo journalctl -u mariadb --since "30 minutes ago"

Perintah tersebut membantu mendeteksi kegagalan layanan, masalah autentikasi, kesalahan konfigurasi, dan gangguan saat MariaDB dimulai.

Monitoring kapasitas storage

Binary log dan relay log dapat bertambah seiring aktivitas database. Periksa penggunaan disk secara berkala:

df -h
sudo du -sh /var/log/mysql

Kapasitas disk yang penuh dapat menghentikan operasi database atau mengganggu proses replikasi.

Terapkan kebijakan retensi binary log berdasarkan kebutuhan pemulihan dan kemampuan replica untuk mengejar ketertinggalan. Retensi yang terlalu pendek dapat membuat replica tertinggal tidak dapat melanjutkan replikasi karena log yang diperlukan sudah dihapus.

Monitoring dengan Prometheus dan Grafana

Untuk infrastruktur yang lebih besar, monitoring terpusat dapat digunakan untuk memantau:

• Ketersediaan layanan MariaDB.
• Status thread replikasi.
• Keterlambatan replikasi.
• Jumlah koneksi.
• Query rate dan latensi.
• Penggunaan CPU, RAM, dan storage.
• Pertumbuhan binary log.
• Jumlah serta jenis error.

Pengumpulan metrik dapat dilakukan melalui exporter atau integrasi monitoring yang sesuai dengan versi MariaDB dan kebijakan keamanan. Nama metrik berbeda antar-exporter, sehingga dashboard harus disesuaikan dengan metrik yang benar-benar tersedia.

Jangan menganggap sebuah dashboard menunjukkan kondisi sehat hanya karena grafik terisi. Buat alert untuk status thread berhenti, error replikasi, disk hampir penuh, keterlambatan yang melewati ambang operasional, dan kegagalan koneksi.

10. Failover Manual: Memindahkan Peran Primary ke Replica

Failover adalah proses mengalihkan layanan dari primary yang gagal ke server pengganti.

Pada replikasi satu arah, promosi replica bukan proses otomatis. Administrator perlu memastikan kondisi data, menghentikan atau mengisolasi primary lama, dan mengarahkan aplikasi ke server baru.

Skenario

DB01 mengalami kegagalan hardware. DB02 masih aktif dan telah menerima sebagian besar perubahan database.

Tujuannya adalah menjadikan DB02 sebagai primary baru dengan risiko kehilangan data seminimal mungkin.

Langkah 1: Memastikan kondisi primary lama

Jika DB01 masih dapat diakses, periksa apakah database benar-benar gagal atau hanya mengalami gangguan jaringan.

Hindari mempromosikan DB02 ketika DB01 masih menerima penulisan aktif tanpa mekanisme fencing. Jika kedua server menerima penulisan secara bersamaan, data dapat menyimpang dan menimbulkan konflik.

Jika DB01 tidak dapat diakses, tentukan apakah ada kemungkinan server tersebut masih aktif melayani aplikasi melalui jalur jaringan lain.

Langkah 2: Mengisolasi primary lama

Pastikan DB01 tidak dapat menerima penulisan baru sebelum DB02 dipromosikan.

Isolasi dapat dilakukan melalui penghentian layanan, pemutusan akses aplikasi, atau mekanisme fencing yang sesuai dengan lingkungan.

Jika server lama tidak dapat dikendalikan, jangan menganggapnya otomatis aman. Periksa jalur akses aplikasi, jaringan, proxy, dan kemungkinan server lama kembali aktif.

Langkah 3: Memeriksa replica

Pada DB02:

SHOW SLAVE STATUS\G

Periksa error, posisi yang sudah diterapkan, dan indikasi transaksi yang tertinggal.

Jika primary lama masih dapat dijangkau dengan aman, evaluasi apakah masih ada event yang dapat diambil. Jika primary sudah hilang, gunakan informasi status terakhir dan log yang tersedia untuk memperkirakan risiko kehilangan data.

Jangan mempromosikan replica hanya karena layanan MariaDB berjalan.

Langkah 4: Menghentikan replikasi

Setelah dipastikan bahwa replica yang dipilih siap dipromosikan dan tidak ada lagi event yang harus diambil dari primary lama, hentikan replikasi:

STOP SLAVE;

Perintah ini menghentikan thread replikasi, tetapi tidak dengan sendirinya membuktikan bahwa semua transaksi telah diterapkan. Validasi kondisi data tetap diperlukan.

Langkah 5: Menjadikan DB02 sebagai primary

Ubah konfigurasi DB02 agar tidak lagi beroperasi sebagai replica. Hapus atau sesuaikan konfigurasi read_only sesuai rancangan operasional, kemudian mulai ulang layanan bila perubahan konfigurasi memerlukannya.

Jika read_only=ON berasal dari konfigurasi file, ubah menjadi:

read_only=OFF

Setelah itu, terapkan konfigurasi sesuai prosedur perubahan layanan dan periksa nilai efektifnya.

Jangan langsung mengizinkan aplikasi menulis sebelum memastikan primary lama telah terisolasi, status replikasi sudah dipahami, dan server baru siap menerima beban kerja.

Langkah 6: Mengarahkan aplikasi ke DB02

Jika aplikasi menggunakan alamat database tetap, ubah konfigurasi koneksi atau gunakan endpoint database yang dapat dipindahkan.

Contoh parameter aplikasi:

DB_HOST=192.168.10.12
DB_PORT=3306
DB_NAME=nama_database
DB_USER=app_user
DB_PASSWORD=GANTI_DENGAN_SECRET_APLIKASI

Sesuaikan nama variabel dengan aplikasi yang digunakan. Jangan menaruh kredensial produksi di repositori kode atau dokumentasi publik.

Jika menggunakan DNS, virtual IP, proxy, atau load balancer, lakukan perubahan endpoint melalui prosedur yang telah diuji.

Langkah 7: Memvalidasi layanan

Setelah aplikasi diarahkan ke DB02:

1. Uji koneksi database.
2. Uji operasi baca.
3. Uji operasi tulis dengan transaksi yang aman.
4. Periksa log aplikasi dan database.
5. Pastikan tidak ada penulisan yang masih diarahkan ke primary lama.
6. Pantau performa dan kapasitas server baru.

Catat waktu pemulihan, dampak terhadap pengguna, dan perkiraan kehilangan data jika ada.

Langkah 8: Menyiapkan server pengganti

Setelah DB02 menjadi primary, DB01 tidak boleh langsung diaktifkan kembali sebagai primary lama.

Server lama perlu diperiksa, data direkonsiliasi, lalu dibangun kembali sebagai replica dari primary yang sekarang aktif. Proses ini membutuhkan konfigurasi replikasi baru dan titik awal data yang konsisten.

Jangan menghubungkan kembali server lama dengan konfigurasi lama tanpa memastikan peran dan kondisi datanya. Langkah tersebut berisiko menghasilkan dua primary yang sama-sama menerima penulisan.

11. Kesalahan yang Sering Terjadi

Binary log tidak aktif

Penyebab: parameter log_bin belum diterapkan atau konfigurasi yang diedit bukan konfigurasi yang dibaca oleh MariaDB.

Dampak: replica tidak dapat mengambil perubahan yang diperlukan.

Solusi: periksa konfigurasi efektif, log layanan, dan hasil SHOW VARIABLES LIKE 'log_bin';.

Server ID duplikat

Penyebab: primary dan replica menggunakan server_id yang sama.

Dampak: replikasi dapat gagal atau identitas server tidak dapat dibedakan dengan benar.

Solusi: tetapkan ID unik untuk setiap server dan verifikasi setelah konfigurasi diterapkan.

Kesalahan autentikasi

Penyebab: password salah, host akun tidak cocok, atau grant tidak memadai.

Dampak: I/O thread gagal terhubung ke primary.

Solusi: periksa akun, hak akses, alamat sumber, dan error koneksi tanpa membuka akses database secara berlebihan.

Posisi binary log tidak sesuai

Penyebab: file atau posisi log yang digunakan tidak berasal dari backup yang dipulihkan.

Dampak: replikasi gagal atau perubahan data terlewat maupun diterapkan secara tidak benar.

Solusi: ambil posisi dari prosedur backup yang konsisten dan lakukan inisialisasi ulang bila diperlukan.

Replica tertinggal

Penyebab: beban penulisan tinggi, jaringan lambat, query penerapan terhambat, atau kapasitas server tidak memadai.

Dampak: laporan pada replica menjadi tidak mutakhir dan promosi dapat kehilangan lebih banyak data.

Solusi: analisis query, kapasitas CPU, I/O storage, bandwidth, serta error replikasi. Jangan sekadar menonaktifkan pemeriksaan tanpa memahami akar masalah.

Disk penuh akibat binary log

Penyebab: retensi tidak dikelola atau replikasi berhenti terlalu lama.

Dampak: operasi database terganggu dan replica mungkin tidak bisa mengejar ketertinggalan.

Solusi: gunakan retensi terencana, alert kapasitas, dan prosedur penghapusan log yang aman sesuai dokumentasi versi MariaDB.

Failover dilakukan terlalu cepat

Penyebab: administrator langsung mempromosikan replica setelah kehilangan koneksi ke primary.

Dampak: risiko kehilangan transaksi, split-brain, dan ketidakkonsistenan data.

Solusi: lakukan isolasi primary lama, evaluasi transaksi tertinggal, validasi replica, dan jalankan checklist failover.

12. Best Practice untuk Lingkungan Produksi

Untuk menjaga keandalan layanan database, terapkan praktik berikut.

Keamanan

• Batasi port 3306 ke host yang membutuhkan akses.
• Gunakan akun aplikasi dan replikasi terpisah.
• Terapkan password kuat dan manajemen secret.
• Evaluasi TLS untuk koneksi database lintas jaringan.
• Jangan mengekspos database langsung ke internet.

Konsistensi data

• Tentukan metode backup awal yang konsisten.
• Gunakan GTID jika sesuai dengan rancangan.
• Uji pemulihan data dan validasi integritas secara berkala.
• Pantau error serta keterlambatan, bukan hanya status layanan.

Ketersediaan

• Tentukan RPO dan RTO secara eksplisit.
• Dokumentasikan prosedur failover dan failback.
• Siapkan mekanisme fencing untuk mencegah dua primary aktif.
• Uji skenario kehilangan jaringan, server mati, dan disk penuh.

Observabilitas

• Gunakan monitoring terpusat.
• Buat alert untuk kegagalan thread, lag, error, dan kapasitas disk.
• Simpan log dengan retensi yang sesuai.
• Lakukan simulasi gangguan di lingkungan pengujian.

Perencanaan kapasitas

• Evaluasi CPU, RAM, IOPS, bandwidth, dan ukuran database.
• Pastikan replica memiliki kapasitas untuk mengambil alih beban primary.
• Periksa kompatibilitas versi, konfigurasi, plugin, dan kebutuhan aplikasi.

MariaDB Replication satu arah tidak otomatis menyediakan pemilihan primary baru, pengalihan endpoint, fencing, atau pencegahan split-brain. Jika aplikasi membutuhkan failover otomatis dan target pemulihan yang ketat, evaluasi solusi high availability yang sesuai, seperti MariaDB Galera Cluster, MaxScale, atau orkestrasi database yang telah diuji. Setiap pilihan memiliki batasan, persyaratan, dan model konsistensi yang berbeda.

13. Checklist Sebelum Implementasi

Gunakan checklist berikut sebelum menerapkan replikasi pada lingkungan produksi.

• Versi MariaDB dan sistem operasi telah diverifikasi.
• Konektivitas dan firewall antarserver sudah diuji.
• server_id setiap server unik.
• Binary log aktif pada primary.
• Akun replikasi dibatasi berdasarkan host.
• Backup awal konsisten dan telah diuji pemulihannya.
• Posisi binary log atau GTID telah diverifikasi.
• Kedua thread replikasi berjalan tanpa error.
• Data hasil replikasi telah diuji.
• Monitoring dan alert telah dikonfigurasi.
• Retensi binary log dan kapasitas disk telah direncanakan.
• Prosedur failover dan failback telah didokumentasikan.
• Primary lama dapat diisolasi sebelum promosi replica.
• Backup terpisah tersedia di luar server database.

Kesimpulan

MariaDB Replication Master-Replica merupakan pendekatan yang berguna untuk menyalin perubahan database ke server lain, mendukung kebutuhan pembacaan data, dan menyiapkan kandidat pemulihan ketika primary mengalami gangguan.

Implementasi yang baik membutuhkan konfigurasi binary log, identitas server yang unik, akun replikasi terbatas, backup awal yang konsisten, serta pemantauan terhadap status thread dan keterlambatan replikasi.

Hal terpenting adalah memahami bahwa replikasi bukan backup dan bukan pula failover otomatis. Prosedur promosi replica harus memperhitungkan transaksi yang belum diterapkan, isolasi primary lama, perubahan endpoint aplikasi, serta pembangunan ulang server pengganti.

Mulailah dengan laboratorium dua server, uji skenario kegagalan, dokumentasikan hasilnya, kemudian terapkan perubahan ke lingkungan produksi melalui prosedur yang terkontrol.

Apakah Anda menggunakan MariaDB Replication untuk aplikasi sekolah, server kampus, website, atau layanan bisnis?

Bagikan pengalaman, kendala konfigurasi, atau strategi failover yang Anda gunakan melalui kolom komentar. Jika artikel ini bermanfaat, bagikan kepada rekan sysadmin dan administrator database lainnya. Jelajahi juga artikel terkait Linux Server, MySQL, MariaDB, monitoring Prometheus, dan high availability untuk memperdalam pemahaman infrastruktur database.

Frequently Asked Questions (FAQ)

1. Apa itu MariaDB Replication Master-Replica?

MariaDB Replication Master-Replica adalah mekanisme untuk menyalin perubahan data dari server primary ke server replica melalui binary log dan proses replikasi.

2. Apakah MariaDB Replication otomatis melakukan failover?

Tidak. Replikasi standar tidak otomatis mempromosikan replica atau mengalihkan koneksi aplikasi. Failover memerlukan prosedur manual atau solusi orkestrasi tambahan.

3. Apa perbedaan MariaDB Replication dan Galera Cluster?

Replikasi standar umumnya menggunakan primary dan replica dengan aliran perubahan satu arah. Galera Cluster menggunakan replikasi berbasis sertifikasi untuk mendukung beberapa node yang dapat menerima penulisan, dengan persyaratan kuorum dan karakteristik operasional tersendiri.

4. Apakah server replica dapat digunakan untuk membaca data?

Ya. Replica dapat digunakan untuk pelaporan atau query baca jika hak akses, konfigurasi, dan kebutuhan konsistensi aplikasi mendukungnya. Perlu diperhatikan bahwa data replica dapat tertinggal dari primary.

5. Apa fungsi binary log dalam MariaDB Replication?

Binary log mencatat perubahan database yang diperlukan untuk replikasi dan dapat mendukung pemulihan berbasis titik waktu apabila dikombinasikan dengan backup yang sesuai.

6. Mengapa Slave_IO_Running bernilai No?

Penyebabnya dapat berupa koneksi jaringan gagal, kredensial salah, hak akses tidak memadai, binary log tidak tersedia, atau masalah kompatibilitas. Periksa Last_IO_Error untuk mengetahui penyebab spesifik.

7. Mengapa Slave_SQL_Running bernilai No?

Biasanya terdapat kesalahan ketika replica menerapkan event dari relay log, misalnya konflik data, tabel tidak ditemukan, atau masalah skema. Periksa Last_SQL_Error sebelum mengambil tindakan perbaikan.

8. Apa arti Seconds_Behind_Master?

Nilai ini merupakan perkiraan keterlambatan replica terhadap primary dalam satuan detik. Nilainya bukan jaminan bahwa seluruh data sudah identik dan dapat bernilai NULL pada kondisi tertentu.

9. Apakah MariaDB Replication dapat digunakan untuk backup?

Replikasi dapat membantu menyediakan salinan data pada server lain, tetapi tidak menggantikan backup terpisah. Penghapusan atau kerusakan logis dapat ikut direplikasi.

10. Apa yang harus dilakukan sebelum mempromosikan replica menjadi primary?

Pastikan primary lama telah diisolasi, evaluasi transaksi yang belum diterapkan, verifikasi kondisi data, hentikan replikasi sesuai prosedur, lalu alihkan endpoint aplikasi dan lakukan pengujian layanan.

11. Apakah MariaDB Replication mendukung GTID?

Ya. MariaDB menyediakan mekanisme Global Transaction ID (GTID) yang dapat membantu mengidentifikasi posisi transaksi dan menyederhanakan pengelolaan replikasi. Konfigurasi harus disesuaikan dengan versi dan topologi yang digunakan.

12. Bagaimana cara memonitor MariaDB Replication secara terpusat?

Gunakan metrik MariaDB atau exporter yang sesuai, lalu tampilkan melalui Prometheus dan Grafana. Pantau status replikasi, lag, error, penggunaan resource, dan kapasitas disk serta buat alert berdasarkan kebutuhan operasional.

Database yang andal bukan hanya tentang server yang selalu aktif, tetapi juga tentang kesiapan menghadapi kegagalan.

Dengan memahami MariaDB Replication Master-Replica, Anda dapat membangun fondasi database yang lebih terstruktur, memantau kesehatan replikasi, dan menyiapkan prosedur pemulihan yang terukur.

💬 Diskusi di kolom komentar:
Apakah Anda sudah menerapkan MariaDB Replication di server produksi? Apa tantangan terbesar Anda: konfigurasi replikasi, replication lag, monitoring, atau failover?

📌 Simpan artikel ini sebagai referensi konfigurasi server database.

🔗 Bagikan kepada rekan sysadmin, database administrator, DevOps engineer, dan praktisi Linux Server yang membutuhkan panduan ini.

🚀 Jelajahi juga artikel lainnya tentang Debian Server, Ubuntu Server, MySQL, MariaDB, Proxmox, Docker, Prometheus, Grafana, dan High Availability.

Ikuti perkembangan tutorial terbaru seputar Linux, networking, database, cloud computing, dan infrastruktur IT untuk meningkatkan kemampuan administrasi sistem Anda.