Meskipun arsitektur yang dibangun (MariaDB Galera + Syncthing) ini sangat powerful dan standar industri, tidak ada sistem yang sempurna. Ada beberapa "Jebakan Batman" atau kekurangan yang harus waspadai, terutama untuk kasus absensi wajah.

Berikut adalah analisis risiko dan hal yang perlu diperhatikan:

1. MariaDB Galera Cluster (Database)

"The Weakest Link" (Si Paling Lemot)

Galera menggunakan Synchronous Replication. Artinya, saat melakukan INSERT di Server A, transaksi itu belum dianggap "sukses" sampai Server B dan C mengonfirmasi "Oke, saya sudah terima!".

• Risikonya: Jika jaringan ke Server C lemot (misal kabelnya kendor), maka proses INSERT di Server A juga akan ikut lemot menunggu Server C. Performa write cluster ditentukan oleh server/jaringan yang paling lambat.

Deadlock pada "Hot Row"

Karena ini Multi-Master, apa yang terjadi jika Server A dan Server B mencoba mengedit baris data yang sama di detik yang sama?

• Risikonya: Galera akan membatalkan salah satunya (Deadlock).

• Solusi: Aplikasi kamu misal Python/Go harus siap menangkap error deadlock dan melakukan retry otomatis. Hindari logic yang mengupdate satu baris counter secara brutal dari banyak node sekaligus.

Jangan Hapus Data Masal (Large Transaction)

Jangan pernah melakukan query seperti DELETE FROM log_transaksi WHERE tanggal < '2024-01-01' yang menghapus jutaan baris sekaligus.

• Risikonya: Cluster bisa hang atau stall karena semua node sibuk memproses transaksi raksasa tersebut.

• Solusi: Pecah transaksi besar menjadi kecil-kecil (LIMIT 1000).

2. Syncthing (File Sync)

Race Condition (Balapan DB vs File)

Ini risiko paling nyata untuk aplikasi. Database (Galera) itu sangat cepat (milidetik), sedangkan File Sync (Syncthing) butuh waktu untuk scan, hash, dan transfer (bisa beberapa detik).

• Skenario Masalah:

  1. User upload foto di Server A.

  2. Server A simpan file & insert DB.

  3. User lain refresh halaman via Server B.

  4. Database di Server B sudah ada datanya, TAPI Filenya belum sampai (masih OTW).

  5. Aplikasi error "File Not Found".

• Solusi: Di kode API (endpoint GET), berikan logic pengecekan: "Jika data di DB ada tapi file belum ada, tunggu sebentar atau lempar status Processing, jangan 404/Error."

Conflict Files

Jika Server A mengedit wajah.jpg dan Server B juga mengedit wajah.jpg di waktu bersamaan.

• Risikonya: Syncthing tidak akan menggabungkan (merge) fotonya. Dia akan membuat file baru bernama wajah.sync-conflict-blabla.jpg.

• Solusi: Pastikan nama file yang diupload selalu unik (misal pakai UUID atau Timestamp), jangan pakai nama statis yang ditimpa terus-menerus.

Syncthing Bukan Backup!

Ini salah kaprah yang sering terjadi.

• Risikonya: Jika ada hacker atau admin yang tidak sengaja menghapus folder /opt/face_data di Server A... Syncthing akan dengan patuh menghapus folder itu juga di Server B dan C dalam hitungan detik.

• Solusi: Tetap lakukan backup berkala (snapshot/zip) ke hardisk eksternal atau cloud storage yang tidak terhubung sinkronisasi real-time.

3. Infrastruktur & Jaringan

Split Brain (Otak Terbelah)

Galera butuh "Quorum" (suara mayoritas) untuk berjalan.

• Skenario: Kita punya 3 Server.

  • Jika 1 mati, sisa 2 (Mayoritas). Aman.

  • Jika 2 mati, sisa 1 (Minoritas).

• Risikonya: Server terakhir yang hidup ini akan menolak semua transaksi tulis (Read-Only) demi keamanan, karena dia bingung "Saya yang terputus dari jaringan, atau teman-teman saya yang mati?".

• Solusi: Pastikan kamu punya minimal 3 node ganjil. Jika sisa 1 server saja, kamu harus manual memaksa dia jadi Primary (SET GLOBAL wsrep_provider_options='pc.bootstrap=YES').

Rangkuman untuk Developer 

Mengingat kali aja pembaca sebagai developer Backend (PHP/Go/Python), ini yang harus diperhatikan di kode:

1. Handling Delay File: Saat read data, cek file_exists() dulu. Jika DB ada tapi file tidak ada, mungkin file sedang OTW.

2. Unique Filename: Gunakan UUID untuk nama file foto agar tidak konflik di Syncthing.

3. Retry Mechanism: Jika insert DB gagal karena Deadlock, buat fungsi auto-retry 3x.

Secara umum, untuk skala Face Recognition korporat/pabrik, solusi ini sudah sangat mumpuni dan jauh lebih baik daripada single server.

Tambahan untuk solusi dari permasalahan "Galera menggunakan Synchronous Replication".

Berikut solusinya, dari yang paling mudah hingga yang paling advanced:

1. Solusi Konfigurasi: Parallel Slave Threads (Paling Mudah)

Jika Server C lambat bukan karena jaringan, tapi karena CPU/Disk-nya kewalahan memproses antrean transaksi, kita bisa suruh dia kerja "lebih ngebut" dengan menggunakan multi-threading.

Secara default, Galera mungkin hanya pakai 1 jalur untuk menulis data replikasi. Ubah agar dia pakai banyak jalur sekaligus.

• Caranya: Edit my.cnf atau 60-galera.cnf di SEMUA server. 

  # Sesuaikan dengan jumlah Core CPU.
  # Rumus kasar: 4 x Jumlah Core. Misal 2 Core = 8 threads.
  wsrep_slave_threads = 8

  Efek: Server C bisa mengejar ketertinggalan lebih cepat.

•  

2. Solusi "Curang": Relaxed Durability (innodb_flush_log)

Ini trik yang sering dipakai developer untuk meningkatkan performa write drastis, dengan sedikit risiko.

Default MySQL (innodb_flush_log_at_trx_commit = 1) memaksa data ditulis ke hardisk fisik setiap kali ada transaksi. Ini lambat. Kita bisa ubah ke nilai 2. Artinya: "Tulis ke RAM dulu, baru ke hardisk tiap 1 detik sekali."

• Caranya: Edit my.cnf di SEMUA server.

  innodb_flush_log_at_trx_commit = 2

   

• Risikonya: Jika mati listrik total mendadak (tanpa UPS), ada potensi hilang data transaksi 1 detik terakhir.

• Keuntungannya: Proses write jadi jauh lebih ringan, sehingga Server C tidak mudah jadi bottleneck.

3. Solusi Arsitektur: Asynchronous Processing (Best Practice)

Jika API aplikasimuharus responsif (user tidak boleh menunggu loading lama), jangan biarkan user menunggu database selesai insert.

Gunakan konsep "Fire and Forget" di aplikasi kamu.

• Cara Kerja Lama (Blocking): User Upload -> Python terima -> Python Insert ke DB (Nunggu Galera A,B,C deal) -> Python Balas "Sukses". (User nunggu lama).

• Cara Kerja Baru (Async/Background Task): User Upload -> Python terima -> Simpan File & Taruh Task di Background -> Python Balas "Sukses, sedang diproses".

  • Di belakang layar (BackgroundTasks di FastAPI), Python baru pelan-pelan insert ke DB.

  • Jika Server C lemot, yang nunggu adalah "Background Task"-nya, bukan User-nya.

4. Solusi Topologi: Hybrid (Galera + Async Slave)

Jika Server C lokasinya jauh (misal beda kota) atau jaringannya memang jelek dan tidak bisa diperbaiki, jangan masukkan Server C ke dalam Cluster Galera.

Ubah topologinya menjadi:

• Server A & Server B: Galera Cluster (Satu lokasi, jaringan kencang).

• Server C: Standard MySQL Slave (Async replication) yang mengambil data dari Server A.

• Keuntungan: Server A & B ngebut tanpa nunggu C. Server C akan terima data "sebisanya" (mungkin telat beberapa detik), tapi tidak akan membebani performa A & B.

• Kerugian: Server C tidak bisa dipakai untuk write (harus Read-Only). Jika A & B mati semua, C tidak bisa otomatis jadi Master tanpa setting manual.

5. Mekanisme Otomatis Galera: Flow Control

Sebenarnya Galera punya fitur bawaan namanya Flow Control. Jika Server C tertinggal terlalu jauh (queue-nya menumpuk), Galera otomatis akan MEMPAUSE Server A dan B supaya C bisa mengejar. Inilah yang bikin terasa "lemot".

Jika ingin Server C "ditinggal saja" kalau terlalu lemot (daripada mengorbankan performa A & B), Anda bisa mengatur agar node yang lemot ditendang keluar cluster. Tapi ini berbahaya (cluster jadi tidak sync), jadi tidak disarankan kecuali darurat.

Jadi mending yang mana?

1. Langkah Pertama (Wajib): Terapkan Solusi No. 1 (wsrep_slave_threads). Ini gratis dan mudah.

2. Langkah Kedua (Rekomendasi): Terapkan Solusi No. 2 (innodb_flush_log_at_trx_commit = 2). Performanya naik signifikan, risikonya kecil selama ada UPS.

3. Langkah Ketiga (Coding): Gunakan Solusi No. 3 (Background Task) di Python FastAPI. Ini membuat aplikasi terasa sangat cepat di mata user, tidak peduli DB-nya lagi lemot atau tidak.