Arsitektur Replikata & Sharding MySQL/MariaDB untuk Skala Jutaan Transaksi

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur sistem skala perusahaan modern, database relasional (seperti MySQL dan MariaDB) sering kali menjadi titik kritis pertama yang mengalami bottleneck ketika aplikasi menghadapi pertumbuhan traffic yang eksponensial. Jutaan transaksi per hari, yang didorong oleh lonjakan pengguna konkuren pada platform e-commerce, perbankan digital, atau aplikasi SaaS berskala besar, memberikan tekanan luar biasa pada subsistem penyimpanan data.

Secara tradisional, arsitektur monolithic database (di mana seluruh operasi Read, Write, Update, dan Delete diproses oleh satu instans tunggal) menghadapi beberapa masalah mendasar:

• Keterbatasan Sumber Daya Hardware (Vertical Scaling Limit): Penambahan RAM, CPU, dan NVMe SSD pada satu server memiliki batasan fisik dan biaya yang tidak linier.
• Kunci Baris dan Tabel (Row and Table Locking): Transaksi penulisan (Write) yang masif menyebabkan antrean panjang pada mesin penyimpanan (seperti InnoDB), meningkatkan latensi kueri secara drastis.
• IOPS Saturated: Operasi disk I/O untuk indeks dan data aktual mengalami saturasi, mengakibatkan thread pool exhaustion pada koneksi backend web (PHP-FPM, Node.js, atau Go).

Kondisi Sebelum Penerapan (Single Instance Antipattern):

• Latensi kueri rata-rata melonjak dari 15ms menjadi >1200ms saat lonjakan flash sale.
• Kegagalan koneksi database (Too many connections) yang memutus rantai layanan backend.
• Kegagalan sistem total (Single Point of Failure / SPOF) ketika disk utama mengalami korupsi data.

Kondisi Sesudah Penerapan (Distributed Replication & Sharding Architecture):

• Pemisahan beban kerja (Read/Write Splitting) melalui Master-Slave Replication mengalihkan 80% operasi Read ke kluster replika.
• Distribusi horizontal (Sharding) memecah tabel raksasa bernilai ratusan gigabita ke dalam beberapa instans independen berdasarkan Hash Key.
• Ketersediaan tinggi (High Availability) dengan waktu pemulihan otomatis (Failover) di bawah 5 detik.

2. Konsep Inti & Deep Dive Arsitektur

Untuk membangun sistem yang mampu menahan jutaan transaksi, kita harus mengombinasikan dua strategi utama: Replikasi Data dan Sharding Data.

Alur Replikasi Master-SlaveSemua operasi Write (INSERT, UPDATE, DELETE) dikirimkan secara eksklusif ke server Master. Master mencatat setiap perubahan ke dalam Binary Log (Binlog). Server Slave membaca Binlog tersebut secara asinkron atau semi-sinkron, lalu menerapkannya pada Relay Log dan mengeksekusinya di basis data lokal mereka.

+-------------------------------------------------------------+
|                        Client / App                         |
+-------------------------------------------------------------+
       |                                           |
  Write Operations                         Read Operations
       |                                           |
       v                                           v
+-----------------------+              +----------------------+
|     MySQL Master      | -- Binlog -> |    MySQL Slave 1     |
|    (Read & Write)     |              |     (Read Only)      |
+-----------------------+              +----------------------+
            |
            |---- Binlog ----> +----------------------+
                               |    MySQL Slave 2     |
                               |     (Read Only)      |
                               +----------------------+

Alur Sharding Berdasarkan Hash Key

Ketika ukuran data melebihi kapasitas satu server atau jumlah transaksi Write melampaui kapasitas Master tunggal, Sharding horizontal wajib diterapkan. Dengan algoritma Hash Sharding, nilai kolom unik (seperti user_id atau order_id) dilewatkan melalui fungsi modulo atau consistent hashing untuk menentukan kluster fisik tempat data tersebut disimpan.

$$\text{Shard ID} = \text{CRC32}(\text{user_id}) \pmod N$$ (Di mana $N$ adalah jumlah total shard yang tersedia)

3. Perbandingan Komparatif / Analisis Pendekatan

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan konfigurasi tingkat lanjut, pastikan lingkungan infrastruktur memenuhi spesifikasi berikut:

• OS: Ubuntu Server 22.04 LTS / Debian 12 (Kernel Linux 5.15+ untuk performa epoll terbaik).
• Database: MariaDB 10.11 LTS atau MySQL 8.0.
• Konektivitas Jaringan: Jaringan privat berkecepatan tinggi minimal 1Gbps antar-node database.
• Konfigurasi Hostname & DNS Lokal (/etc/hosts):

  192.168.10.10  db-master
  192.168.10.11  db-slave-01
  192.168.10.12  db-shard-01
  192.168.10.13  db-shard-02
  

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi MySQL/MariaDB Master (/etc/mysql/mariadb.conf.d/50-server.cnf)

[mysqld]
server-id               = 1
log_bin                 = /var/log/mysql/mariadb-bin.log
binlog_format           = ROW
expire_logs_days        = 7
max_binlog_size         = 100M
binlog_do_db            = production_db

# Network & Connections
bind-address            = 0.0.0.0
max_connections         = 1000
connect_timeout         = 10
wait_timeout            = 600
interactive_timeout     = 600

# InnoDB Tuning
innodb_buffer_pool_size = 12G
innodb_log_file_size    = 2G
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table   = 1
innodb_flush_method     = O_DIRECT

Langkah 2: Membuat Pengguna Replikasi pada Master

Masuk ke konsol MySQL master dan jalankan perintah berikut:

CREATE USER 'replicator'@'%' IDENTIFIED BY 'StrongSecurePassword123!';
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 karena akan digunakan untuk menghubungkan server Slave.

Langkah 3: Konfigurasi MySQL/MariaDB Slave (/etc/mysql/mariadb.conf.d/50-server.cnf)

[mysqld]
server-id               = 2
relay-log               = /var/log/mysql/mysql-relay-bin.log
log_bin                 = /var/log/mysql/mariadb-bin.log
read_only               = 1

# InnoDB Tuning (Disamakan atau disesuaikan dengan kapasitas slave)
innodb_buffer_pool_size = 12G
innodb_log_file_size    = 2G
innodb_flush_log_at_trx_commit = 1
innodb_flush_method     = O_DIRECT

Langkah 4: Menghubungkan Slave ke Master

Masuk ke konsol MySQL slave, lalu jalankan perintah integrasi replikasi:

CHANGE MASTER TO
  MASTER_HOST='192.168.10.10',
  MASTER_USER='replicator',
  MASTER_PASSWORD='StrongSecurePassword123!',
  MASTER_LOG_FILE='mariadb-bin.000001',
  MASTER_LOG_POS= 481;

START SLAVE;
SHOW SLAVE STATUS\G

6. Bedah Kode & Penjelasan Detail Baris Kunci

• binlog_format = ROW: Baris konfigurasi ini memastikan bahwa MariaDB mencatat perubahan tingkat baris, bukan tingkat pernyataan (statement-based). Ini krusial untuk mencegah inkonsistensi data ketika menggunakan fungsi nondeterministik atau operasi berbasis replikasi multi-master.
• innodb_buffer_pool_size = 12G: Mengalokasikan memori RAM untuk menyimpan cache data dan indeks InnoDB. Pada server produksi dengan RAM 16GB, alokasi 70-75% untuk buffer pool adalah standar emas.
• innodb_flush_log_at_trx_commit = 1: Menjamin integritas ACID dengan menulis dan mem-flush log transaksi ke disk pada setiap proses commit. Ubah ke 2 hanya jika Anda bersedia menoleransi risiko kehilangan data transaksi beberapa detik terakhir demi peningkatan performa penulisan (Write IOPS).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam sistem E-Commerce skala besar, tabel orders dapat tumbuh hingga 50 juta baris per tahun. Menerapkan sharding berdasarkan user_id membagi tabel ini menjadi 4 node independen:

• Shard 0: user_id % 4 == 0 -> Disimpan di db-shard-01
• Shard 1: user_id % 4 == 1 -> Disimpan di db-shard-02
• Shard 2: user_id % 4 == 2 -> Disimpan di db-shard-03
• Shard 3: user_id % 4 == 3 -> Disimpan di db-shard-04

Aplikasi backend (menggunakan Go atau Node.js) mengimplementasikan fungsi routing di tingkat ORM atau middleware kustom untuk mengarahkan kueri SQL ke koneksi database shard yang tepat secara dinamis berdasarkan parameter user_id yang masuk.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Mengabaikan Lag Replikasi (Replication Lag) Masalah: Aplikasi membaca data dari Slave segera setelah operasi Write di Master, menyebabkan data terlihat belum berubah (misal: profil pengguna gagal diperbarui). Solusi: Gunakan pembacaan yang konsisten dengan memaksa kueri penting dibaca langsung dari Master atau gunakan Session-based Routing.
• Anti-Pattern 2: Global Unique Identifier (GUID/UUID v4) sebagai Primary Key pada Sharded InnoDB Masalah: UUID bersifat acak, menyebabkan fragmentasi halaman B-Tree yang parah dan penurunan performa Write yang drastis. Solusi: Gunakan UUID v7, Sequential Snowflake IDs, atau Auto-Increment dengan offset khusus per shard.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan kluster, gunakan utilitas sysbench untuk melakukan simulasi transaksi OLTP:

# Inisialisasi data uji sysbench pada database
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.10 \
  --mysql-user=root \
  --mysql-password=SecurePassword \
  --mysql-db=production_db \
  --table-size=1000000 \
  --tables=10 prepare

# Jalankan benchmark konkurensi tinggi
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.10 \
  --mysql-user=root \
  --mysql-password=SecurePassword \
  --mysql-db=production_db \
  --threads=64 \
  --time=300 \
  --report-interval=10 run

Interpretasi Metrik:

• Perhatikan metrik transactions per second (TPS) dan 95th percentile latency. Target enterprise modern minimal mencapai >5000 TPS dengan latensi p95 di bawah 15ms.

10. Checklist Penerapan Produksi & Kesimpulan

• Konfigurasi server-id unik pada setiap instans Master dan Slave.
• Aktifkan binlog_format = ROW dan verifikasi integritas replikasi (Slave_IO_Running: Yes, Slave_SQL_Running: Yes).
• Terapkan enkripsi TLS/SSL untuk lalu lintas replikasi melintasi jaringan data.
• Lakukan pengujian Failover otomatis menggunakan skrip pemantauan (Orchestrator / MHA / ProxySQL).
• Pastikan rotasi log binari dikonfigurasi dengan benar untuk mencegah kehabisan ruang disk.