Arsitektur High-Availability Database dengan Replikasi Master-Replica MariaDB dan Redis Caching

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur sistem web modern, tantangan terbesar yang dihadapi oleh seorang Principal Infrastructure Engineer bukanlah sekadar menulis kode yang elegan, melainkan memastikan bahwa infrastruktur data layer mampu bertahan di bawah tekanan high concurrency (konkurensi tinggi) tanpa mengalami single point of failure (SPOF). Seiring dengan pertumbuhan pengguna, basis data relasional tunggal (monolithic database) akan mencapai batas fisik operasionalnya. CPU akan kehabisan siklus untuk memproses query read dan write secara bersamaan, RAM akan terbebani oleh buffer pool yang tidak mencukupi, dan I/O disk (IOPS) akan mengalami bottleneck akibat disk contention.

Analisis Akar Masalah: Mengapa Arsitektur Tunggal Gagal?

Secara tradisional, aplikasi web modern sering kali mengeksekusi operasi baca (SELECT) jauh lebih sering daripada operasi tulis (INSERT, UPDATE, DELETE). Pada aplikasi e-commerce, SaaS, atau social network, rasionya bisa mencapai 90:10 atau bahkan 95:5. Ketika jutaan pengguna mengakses sistem secara simultan, database tunggal akan memproses seluruh operasi ini pada satu mesin fisik yang sama. Akibatnya:

1. Lock Contention: Operasi tulis yang mengunci tabel atau baris tertentu akan memaksa operasi baca mengantre, menyebabkan lonjakan query latency.
2. Resource Starvation: Kueri analitik atau laporan berat yang berjalan pada database operasional menghabiskan sumber daya CPU dan memori, membuat transaksi pengguna yang krusial mengalami timeout.
3. Zero Redundancy: Jika instance database tersebut mengalami kegagalan hardware, seluruh aplikasi web akan langsung lumpuh total (total downtime).

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan

• Sebelum Penerapan (Monolithic DB): Latency tinggi saat lonjakan traffic, sering terjadi connection timeout, tidak ada redundansi, dan pemulihan bencana (disaster recovery) memakan waktu berjam-jam karena harus melakukan restore dari backup fisik.
• Sesudah Penerapan (MariaDB Master-Replica + Redis Caching): Beban baca terdistribusi ke beberapa read-replica, data yang sering diakses dilayani secara instan oleh Redis dengan latensi sub-milidetik, operasi tulis dikonsolidasikan pada master node, dan sistem tetap tersedia (high availability) meskipun salah satu replica node mengalami kegagalan.

2. Konsep Inti & Deep Dive Arsitektur

Untuk mengatasi masalah di atas, kita memerlukan arsitektur berlapis yang memisahkan tanggung jawab penyimpanan dan pengiriman data. Solusi industri yang teruji adalah kombinasi dari MariaDB Master-Replica Replication untuk konsistensi data relasional dan Redis Cache-Aside Pattern untuk akselerasi pembacaan data.

Alur Kerja di Balik Layar (Under the Hood)

1. Write Path (Operasi Tulis): Seluruh perintah INSERT, UPDATE, dan DELETE dikirimkan secara eksklusif ke Master Node. Setiap perubahan dicatat ke dalam Binary Log (Binlog) MariaDB. Replica Node secara asinkron atau semi-sinkron membaca Binlog ini melalui proses I/O Thread dan menerapkan perubahannya ke Relay Log, lalu dieksekusi oleh SQL Thread.
2. Read Path & Caching (Operasi Baca): Ketika aplikasi web memerlukan data, alur pengecekan berjalan secara berlapis:
   • Aplikasi memeriksa keberadaan data di Redis Cache terlebih dahulu.
   • Jika data ditemukan (Cache Hit), data langsung dikembalikan ke aplikasi dengan latensi milidetik.
   • Jika data tidak ditemukan (Cache Miss), aplikasi mengambil data dari MariaDB Read-Replica, lalu secara asinkron menyimpan salinan data tersebut ke dalam Redis untuk permintaan berikutnya.

[ Client / Web Browser ]
         │
         ▼
   [ Nginx / Web Server ]
         │
         ├──────────────────────────────┐
         ▼                              ▼
   [ Redis Cache ]              [ Backend App (PHP/Go/Node) ]
 (Cache-Aside Pattern)                 │
         │ (Cache Miss)                 ├──────────────┐
         └─────────────────────────────►│              │
                                        ▼              ▼
                               [ MariaDB Master ] [ MariaDB Replica ]
                                  (Write Only)       (Read Only)
                                        │
                                        └──────(Binlog Replication)─────┘

3. Perbandingan Komparatif / Analisis Pendekatan

Tabel berikut membandingkan tiga strategi arsitektur penyimpanan data untuk membantu Anda memilih pendekatan yang paling sesuai dengan kebutuhan enterprise:

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melangkah ke proses konfigurasi teknis, pastikan environment infrastruktur Anda telah memenuhi spesifikasi minimum berikut:

• OS: Ubuntu Server 22.04 LTS (Minimal 2 Node: 1 Master, 1 Replica, dan Redis dapat diinstal terpisah atau disatukan dengan aplikasi).
• Paket Software: MariaDB Server 10.11+, Redis Server 7.0+.
• Jaringan: Koneksi privat internal (VPC) antar node dengan latensi < 2ms dan port firewall yang terbuka:
  • Port 3306 (MariaDB)
  • Port 6379 (Redis)
• Hak Akses: Akses root atau sudo pada seluruh server.

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi MariaDB Master Node

Buka file konfigurasi MariaDB pada node Master (/etc/mysql/mariadb.conf.d/50-server.cnf) dan pastikan parameter berikut diset dengan benar:

[mysqld]
server-id               = 1
log_bin                 = /var/log/mysql/mariadb-bin.log
log_bin_index           = /var/log/mysql/mariadb-bin.index
binlog_format           = ROW
expire_logs_days        = 7
max_binlog_size         = 100M
bind-address            = 0.0.0.0
innodb_buffer_pool_size = 4G
innodb_flush_log_at_trx_commit = 1
sync_binlog             = 1

Restart layanan MariaDB:

sudo systemctl restart mariadb

Buat akun replikasi khusus di MariaDB Master melalui CLI:

CREATE USER 'replicator'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';
FLUSH PRIVILEGES;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

[!IMPORTANT] Catat nilai File dan Position dari perintah SHOW MASTER STATUS. Nilai ini akan digunakan untuk menyinkronkan Replica Node.

Langkah 2: Konfigurasi MariaDB Replica Node

Buka file konfigurasi pada node Replica (/etc/mysql/mariadb.conf.d/50-server.cnf):

[mysqld]
server-id               = 2
relay-log               = /var/log/mysql/mysql-relay-bin.log
relay-log-index         = /var/log/mysql/mysql-relay-bin.index
log_bin                 = /var/log/mysql/mariadb-bin.log
binlog_format           = ROW
read_only               = 1
bind-address            = 0.0.0.0
innodb_buffer_pool_size = 4G

Restart layanan MariaDB Replica:

sudo systemctl restart mariadb

Hubungkan Replica ke Master menggunakan perintah SQL berikut (sesuaikan file, posisi, dan IP master):

STOP SLAVE;
CHANGE MASTER TO 
  MASTER_HOST='192.168.1.100',
  MASTER_USER='replicator',
  MASTER_PASSWORD='StrongPassword123!',
  MASTER_LOG_FILE='mariadb-bin.000001',
  MASTER_LOG_POS=328;
START SLAVE;
SHOW SLAVE STATUSG

Pastikan parameter Slave_IO_Running dan Slave_SQL_Running bernilai Yes.

Langkah 3: Konfigurasi Redis Server untuk Caching

Edit file konfigurasi Redis (/etc/redis/redis.conf):

bind 0.0.0.0
port 6379
protected-mode yes
requirepass RedisSecurePassword456!
maxmemory 2gb
maxmemory-policy allkeys-lru
save 900 1
save 300 10
save 60 10000

Restart layanan Redis:

sudo systemctl restart redis-server

Langkah 4: Implementasi Cache-Aside Pattern pada Backend (Contoh PHP/PDO)

Berikut adalah implementasi kode backend menggunakan arsitektur Cache-Aside dengan PHP untuk mengambil data pengguna:

<?php

class UserService {
    private PDO $dbRead;
    private \Redis $redis;

    public function __construct(PDO $dbRead, \Redis $redis) {
        $this->dbRead = $dbRead;
        $this->redis = $redis;
    }

    public function getUserProfile(int $userId): ?array {
        $cacheKey = "user:profile:{$userId}";

        // 1. Cek data di Redis Cache terlebih dahulu
        $cachedData = $this->redis->get($cacheKey);
        if ($cachedData !== false) {
            return json_decode($cachedData, true);
        }

        // 2. Jika Cache Miss, ambil dari MariaDB Read-Replica
        $stmt = $this->dbRead->prepare("SELECT id, username, email, updated_at FROM users WHERE id = ?");
        $stmt->execute([$userId]);
        $userData = $stmt->fetch(PDO::FETCH_ASSOC);

        if (!$userData) {
            return null;
        }

        // 3. Simpan kembali ke Redis dengan TTL (Time-To-Live) 3600 detik
        $this->redis->setex($cacheKey, 3600, json_encode($userData));

        return $userData;
    }

    public function updateUserProfile(int $userId, string $email): bool {
        // Operasi tulis dieksekusi ke Master (tidak disertakan dalam snippet ini)
        
        // Cache Invalidation: Hapus cache lama agar tidak terjadi stale data
        $cacheKey = "user:profile:{$userId}";
        $this->redis->del($cacheKey);

        return true;
    }
}

6. Bedah Kode & Penjelasan Detail Baris Kunci

• binlog_format = ROW: Baris ini sangat penting dalam replikasi MariaDB modern. Format berbasis row mencatat perubahan aktual pada setiap baris data alih-alih pernyataan SQL mentah (STATEMENT). Hal ini menghilangkan risiko inkonsistensi data akibat fungsi non-deterministik seperti NOW() atau UUID().
• read_only = 1 pada Replica: Mencegah pengguna atau aplikasi melakukan perubahan data secara tidak sengaja langsung ke node replica, menjaga integritas struktur replikasi agar tidak terjadi split-brain.
• maxmemory-policy allkeys-lru: Pada konfigurasi Redis, kebijakan ini memastikan bahwa ketika batas memori RAM tercapai (2gb), Redis secara otomatis akan menghapus kunci yang paling jarang digunakan (Least Recently Used) untuk memberikan ruang bagi data baru tanpa menyebabkan Out of Memory (OOM) crash.
• Cache Invalidation ($this->redis->del($cacheKey)): Menerapkan strategi Cache-Aside yang benar dengan cara menghapus cache setiap kali operasi pembaruan data (UPDATE/DELETE) terjadi pada database master.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada sistem e-commerce skala besar yang menghadapi flash sale, lonjakan traffic pada halaman katalog produk dapat mencapai 50.000 requests per second (RPS). Tanpa arsitektur caching dan read-replica, database utama akan langsung mengalami connection pool exhaustion.

Solusi Arsitektural yang Diterapkan:

1. Edge Caching: Menggunakan Cloudflare untuk file statis dan halaman landing.
2. Redis Caching: Menyimpan data detail produk, harga, dan stok yang sering dibaca dengan TTL pendek (60 detik).
3. MariaDB Read-Replica Cluster: Menyediakan 4 unit read-replica di belakang load balancer HAProxy khusus untuk melayani kueri pencarian produk dan katalog yang kompleks.
4. Master Node: Didedikasikan secara eksklusif untuk proses transaksi pembayaran (checkout dan order placement).

Hasilnya, sistem mampu mempertahankan latensi rata-rata di bawah 15ms meskipun terjadi lonjakan transaksi hingga 10x lipat dari kondisi normal.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Anti-Pattern 1: Mengabaikan Replicaton Lag. Masalah: Aplikasi membaca data dari replica segera setelah melakukan operasi tulis ke master, menyebabkan pengguna melihat data lama (stale data). Solusi: Gunakan teknik Read-after-Write Consistency dengan cara mengarahkan pembacaan langsung ke Master untuk beberapa detik pertama setelah transaksi tulis, atau gunakan mekanisme penanda waktu (session tracking).

[!WARNING] Anti-Pattern 2: Cache Stampede (Dogpile Effect). Masalah: Ketika kunci cache dengan popularitas tinggi kedaluwarsa secara bersamaan di bawah traffic tinggi, ribuan permintaan secara serentak melakukan cache miss dan menghantam database secara masif. Solusi: Terapkan Mutex Locking (Redis SETNX) atau Probabilistic Early Expiration (Algoritma XFetch) untuk meregenerasi cache sebelum benar-benar kedaluwarsa.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan sistem siap menghadapi beban produksi, lakukan pengujian beban (load testing) menggunakan tool seperti k6 atau Apache Bench (ab).

Contoh perintah pengujian menggunakan ab untuk menguji endpoint API produk:

ab -n 10000 -c 200 -H "Authorization: Bearer token123" https://api.enterprise.com/v1/products/1042

Metrik Utama yang Dipantau:

• QPS (Queries Per Second): Pastikan database dan Redis mampu menangani target minimal 5000 QPS.
• P99 Latency: Waktu respons persentil ke-99 harus berada di bawah 50 milidetik.
• Replica Lag (Seconds_Behind_Master): Pantau secara berkala melalui perintah SHOW SLAVE STATUS untuk memastikan nilai ini selalu bernilai 0 atau mendekati nol.

Tuning Lanjutan Linux Kernel (/etc/sysctl.conf):

net.core.somaxconn = 65535
vm.swappiness = 10
fs.file-max = 2097152

Terapkan perubahan dengan perintah sudo sysctl -p untuk mengoptimalkan penanganan koneksi jaringan dan pengelolaan memori virtual.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis arsitektur ini ke lingkungan production, pastikan seluruh poin dalam checklist berikut telah terpenuhi:

• Konfigurasi server-id unik pada setiap node MariaDB Master dan Replica.
• Pengaktifan binlog_format = ROW dan mode read_only pada seluruh replica.
• Implementasi kredensial akses database dan Redis yang kuat serta dibatasi oleh jaringan privat (VPC).
• Mekanisme Cache Invalidation terintegrasi dengan baik pada seluruh operasi tulis di backend.
• Monitoring aktif menggunakan Prometheus dan Grafana untuk memantau Replica Lag dan penggunaan RAM Redis.
• Pengujian prosedur manual failover ketika node Master mengalami pemadaman mendadak.

Penerapan arsitektur MariaDB Master-Replica yang dikombinasikan dengan Redis Caching memberikan fondasi infrastruktur enterprise yang tangguh, skalabel, dan tahan terhadap kegagalan. Dengan memisahkan beban baca dan tulis serta memanfaatkan akselerasi memori in-memory, sistem Anda kini siap menghadapi pertumbuhan bisnis digital yang eksponensial.