Membangun Klaster Database MySQL High Availability dengan Orchestrator dan ProxySQL di Kubernetes

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern yang menuntut ketersediaan layanan hingga tingkat High Availability (HA) 99.999%, database relational seperti MySQL sering kali menjadi titik kegagalan tunggal (Single Point of Failure / SPOF) yang paling rentan. Ketika sebuah aplikasi enterprise berkembang pesat—menghandle ribuan permintaan HTTP per detik, melakukan transaksi finansial real-time, atau mengelola state sesi pengguna—infrastruktur database konvensional berbasis Single Instance atau Active-Passive tradisional tidak lagi memadai.

Bottleneck Performa dan Keamanan Konvensional

Pada arsitektur konvensional, kegagalan pada node master memerlukan intervensi manual yang memakan waktu (Recovery Time Objective / RTO yang tinggi). Selain itu, tanpa mekanisme pembagian beban baca (Read Splitting), seluruh query SELECT yang masif dibebankan pada satu node master yang sama dengan operasi tulis (INSERT, UPDATE, DELETE), menyebabkan saturasi CPU, IOPS disk yang habis, dan peningkatan latensi yang merusak pengalaman pengguna akhir.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur yang kita bangun menggabungkan tiga komponen utama dalam ekosistem Kubernetes:

1. MySQL Server dengan Semi-Synchronous Replication: Menjamin bahwa transaksi tidak dianggap sukses oleh klien sampai setidaknya satu replica menerima dan menulis relay log secara fisik.
2. GitHub Orchestrator: Sistem otomasi topologi replikasi MySQL yang memantau kesehatan klaster secara real-time dan mengeksekusi failover otomatis.
3. ProxySQL: Lapisan perantara (middleware) berperforma tinggi yang bertindak sebagai connection pooler sekaligus intelligent query router (mengarahkan read ke replica dan write ke master).

Alur Eksekusi & Data Flow (ASCII Diagram)

+-------------------------------------------------------------------------+
|                           KUBERNETES CLUSTER                            |+
|                                                                         |
|   +-------------------+       +-----------------------+                 |
|   |  App Pods / Micro | ----> | ProxySQL Service (IP) |                 |
|   +-------------------+       +-----------------------+                 |
|                                    | (Query Routing)                    |
|                       +------------+------------+                       |
|                       |                         |                       |
|                       v (Writes)                v (Reads)               |
|             +-------------------+     +-------------------+             |
|             | MySQL Master Pod  |     | MySQL Replica Pod |             |
|             +-------------------+     +-------------------+             |
|                       \                     /                           |
|                        +-- Semi-Sync Rep --+                            |
|                                                                         |
|   +-----------------------------------------------------------------+   ||
|   |                   GitHub Orchestrator Service                   |===||
|   |      (Monitors Topologies & Triggers Automated Failover)        |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Memilih komponen database HA di Kubernetes memiliki beberapa opsi arsitektur. Berikut perbandingan mendalam:

| Fitur / Metrik | Orchestrator + ProxySQL | MySQL InnoDB Cluster (MySQL Shell) | Vitess |: | :--- | :--- | :--- | :--- | | Kompleksitas Setup | Menengah-Tinggi | Menengah | Sangat Tinggi | | Resource Overhead (RAM/CPU) | Rendah - Menengah | Menengah | Tinggi (Banyak komponen gRPC) | | Kompatibilitas Aplikasi | 100% Native MySQL | Membutuhkan X Protocol / Standard | Membutuhkan sharding key (vttablet) | | Kontrol Topologi | Sangat Fleksibel (Custom Failover Hooks) | Otomatis oleh Group Replication | Skala Web-Scale Sharding | | Cocok Untuk | Monolit hingga Mid-Microservices | Aplikasi standar berbasis MySQL | Sistem skala raksasa (jutaan QPS) |

[!TIP] Gunakan kombinasi Orchestrator dan ProxySQL jika Anda memiliki aplikasi eksisting yang ingin dipindahkan ke Kubernetes tanpa mengubah kode SQL atau pola koneksi driver database.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melangkah ke implementasi, pastikan lingkungan Anda memenuhi spesifikasi berikut:

• Kubernetes Cluster: Versi 1.25+ dengan dukungan StorageClass berkinerja tinggi (misal: NVMe-backed CSI).
• Resource Node Minimum: 3 Worker Nodes (masing-masing minimal 4 vCPU, 8GB RAM).
• Tools: kubectl, helm (v3.10+).
• Namespace Khusus: database-system untuk isolasi beban kerja.

Verifikasi node Kubernetes:

kubectl get nodes -o wide

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Deploy MySQL StatefulSet dengan Semi-Sync Replication

Buat file manifest mysql-statefulset.yaml:

apiVersion: v1
kind: Service
metadata:
  name: mysql-headless
  namespace: database-system
  labels:
    app: mysql
spec:
  ports:
  - port: 3306
    name: mysql
  clusterIP: None
  selector:
    app: mysql
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: database-system
spec:
  selector:
    matchLabels:
      app: mysql
  serviceName: "mysql-headless"
  replicas: 3
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0.33
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
        - name: mysql-config
          mountPath: /etc/mysql/conf.d
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 50Gi

Langkah 2: Konfigurasi MySQL (my.cnf) via ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-config
  namespace: database-system
data:
  server.cnf: |
    [mysqld]
    server-id = 100
    gtid-mode = ON
    enforce-gtid-consistency = ON
    log-bin = mysql-bin
    log-slave-updates = 1
    binlog-format = ROW
    master-info-repository = TABLE
    relay-log-info-repository = TABLE
    read-only = 0
    plugin-load-add = semisync_master.so
    plugin-load-add = semisync_slave.so
    rpl-semi-sync-master-enabled = 1
    rpl-semi-sync-slave-enabled = 1

Langkah 3: Deploy GitHub Orchestrator

Deploy Orchestrator untuk mengelola topologi replikasi secara otomatis:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orchestrator
  namespace: database-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: orchestrator
  template:
    metadata:
      labels:
        app: orchestrator
    spec:
      containers:
      - name: orchestrator
        image: github/orchestrator:v3.2.6
        ports:
        - containerPort: 3000
          name: http
        env:
        - name: ORCHESTRATOR_TOPOLOGY_USER
          value: "orc_client"
        - name: ORCHESTRATOR_TOPOLOGY_PASSWORD
          value: "SecureOrcPass123!"

Langkah 4: Deploy ProxySQL untuk Query Routing

apiVersion: apps/v1
kind: Deployment
metadata:
  name: proxysql
  namespace: database-system
spec:
  replicas: 2
  selector:
    matchLabels:
      app: proxysql
  template:
    metadata:
      labels:
        app: proxysql
    spec:
      containers:
      - name: proxysql
        image: proxysql/proxysql:2.5.2
        ports:
        - containerPort: 6033
          name: mysql
        - containerPort: 6032
          name: admin

6. Bedah Kode & Penjelasan Detail Baris Kunci

• gtid-mode = ON dan enforce-gtid-consistency = ON: Memastikan setiap transaksi memiliki Global Transaction Identifier unik. Hal ini sangat krusial bagi Orchestrator untuk melakukan failover tanpa kehilangan pointer posisi binlog (MASTER_LOG_FILE dan MASTER_LOG_POS).
• rpl-semi-sync-master-enabled = 1: Mengaktifkan mode semi-synchronous di tingkat penyimpanan. Node master akan menunggu konfirmasi dari setidaknya satu node replica bahwa relay log telah ditulis ke disk lokal sebelum mengirimkan commit acknowledgement ke aplikasi klien.
• ProxySQL Query Rules: Memisahkan pola query SQL menggunakan regex (misal: SELECT diarahkan ke hostgroup pembaca, sementara INSERT/UPDATE diarahkan ke hostgroup penulis).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam sebuah platform e-commerce dengan 15.000 transaksi checkout per menit saat Flash Sale, lonjakan beban tulis (write amplification) berpotensi melumpuhkan database. Dengan arsitektur ini:

1. ProxySQL mendistribusikan query agregasi produk (SELECT) ke 2 node replica secara merata melalui algoritma Round Robin atau Weight-based.
2. Saat node master mengalami kernel panic atau kegagalan jaringan, Orchestrator mendeteksi dead master dalam waktu 5 detik, mempromosikan replica dengan lag paling rendah menjadi master baru, dan memicu topology refocus.
3. ProxySQL mendeteksi perubahan topologi secara dinamis dan memindahkan traffic tulis ke master baru tanpa memerlukan restart pada aplikasi backend Node.js atau PHP-FPM.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Anti-Pattern Fatal: Menggunakan koneksi langsung dari aplikasi ke pod database individu tanpa melalui ProxySQL atau Service Mesh. Jika pod restart dan IP berubah, aplikasi akan mengalami Connection Refused massal.

• Kesalahan 1: Mengabaikan Network Partition (Split-Brain).
  • Solusi: Pastikan Orchestrator dikonfigurasi dengan Quorum minimal 3 node pemantau atau mendeteksi status melalui Kubernetes API server.
• Kesalahan 2: Konfigurasi rpl_semi_sync_master_timeout terlalu rendah.
  • Solusi: Atur timeout minimal 5000ms untuk mencegah master melakukan fallback ke asynchronous mode terlalu cepat saat terjadi lonjakan latensi jaringan internal.

9. Benchmark, Metrik Kinerja & Tuning Performa

Lakukan pengujian beban (load testing) menggunakan sysbench untuk memvalidasi performa klaster:

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=PROXYSQL_SERVICE_IP \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=app_password \
  --mysql-db=testdb \
  --threads=64 \
  --time=300 run

Parameter Tuning Lanjutan (my.cnf):

• innodb_buffer_pool_size: Alokasikan 70-80% dari total RAM pod MySQL.
• innodb_log_file_size: Atur minimal 2GB untuk mempercepat operasi tulis dan checkpointing.
• max_connections: Sesuaikan dengan kapasitas connection pool ProxySQL untuk menghindari error Too many connections.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis klaster database ini ke lingkungan Production, pastikan Anda telah mencentang seluruh daftar verifikasi berikut:

• GTID diaktifkan di seluruh instance MySQL.
• Semi-Synchronous Replication terverifikasi aktif (SHOW STATUS LIKE 'Rpl_semi_sync_master_status';).
• Orchestrator terhubung ke webhook notifikasi (Slack/PagerDuty) saat terjadi failover.
• ProxySQL Admin credentials telah diamankan dan tidak menggunakan password default.
• Strategi backup otomatis (misal: Percona XtraBackup) dijadwalkan secara berkala ke S3/MinIO.

Dengan mengimplementasikan arsitektur ini, Anda tidak hanya mengamankan aplikasi dari risiko down-time akibat kegagalan database, tetapi juga membangun infrastruktur cloud-native yang tangguh, mudah di-skalakan, dan siap menghadapi beban kerja enterprise tingkat tinggi.