Catatan Perbaikan — Galera Node Gagal Resync dari ClusterControl

Tanggal: 2026-09-11 Cluster: MariaDB 11.8.9 Galera “cluster-2” (Cluster ID 2), dikelola ClusterControl / CMON 2.3.4.17761 (Severalnines) Node bermasalah: 192.168.223.110 — db2-c2-Write-223 Node donor sehat: 192.168.223.113 (db1-c2-Write), 192.168.223.108 (db3-c2-Write), 192.168.143.31 (db4-c2-ReadOnly) Dampak: 1 dari 4 node down. Cluster tetap Primary (quorum 3/4), tidak ada outage layanan, tapi node tidak bisa di-resync.

1. Gejala

Job ClusterControl RESTART / Rebuild dengan initial: true selalu gagal:

{
  "command": "RESTART",
  "job_data": { "initial": true, "hostname": "192.168.223.110", "port": 3306 }
}

Restart failed: Check error logs.
192.168.223.110:3306: Starting mysqld service failed.
Job for mariadb.service failed because the control process exited with error code.

Error log MariaDB di node .110:

[Note] Plugin 'wsrep-provider' is disabled.
[Warning] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.db' doesn't exist
[ERROR] Aborting

2. Analisa akar masalah

Yang ClusterControl lakukan saat initial: true

1. Stop mariadb di node target
2. rm -rf /var/lib/mysql/* — datadir dikosongkan untuk SST penuh
3. Start mariadbd → seharusnya wsrep provider load → node join cluster → minta SST (mariabackup) dari donor → datadir terisi → Synced

Apa yang sebenarnya terjadi

Langkah 3 gagal karena mariadbd start tanpa wsrep provider. Tanpa wsrep, tidak ada SST yang dipicu. Datadir sudah kosong (dihapus di langkah 2) + tidak ada system table mysql.* → server langsung Aborting.

Table 'mysql.db' doesn't exist / mysql.servers doesn't exist adalah gejala dari datadir kosong tanpa SST — bukan penyebab. Jangan terjebak memperbaiki system table.

Kenapa wsrep provider tidak load?

/etc/mysql/my.cnf di node .110 tertimpa oleh stub bawaan paket MariaDB (mysql-common), hanya 33 baris:

[client-server]
socket = /run/mysqld/mysqld.sock
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

Padahal my.cnf yang benar (template ClusterControl, ±226 baris) berisi seluruh blok WSREP. Bukti:

# di node .110 (RUSAK) — cuma bind-address yang kebaca, tidak ada wsrep sama sekali
root@db2-c2-Write-223:~# my_print_defaults --mysqld | grep -Ei 'wsrep|galera'
--bind-address=127.0.0.1

# di node .113 / .108 / .143 (SEHAT)
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_on=ON
...

Efek samping tambahan: stub menarik mariadb.conf.d/50-server.cnf yang memaksa bind-address = 127.0.0.1 (di node sehat baris ini tidak aktif karena my.cnf CC tidak pakai !includedir).

60-galera.cnf di semua node memang hanya placeholder ter-comment (#wsrep_on = ON) — normal untuk setup ClusterControl, karena config asli ada di my.cnf.

Kemungkinan pemicu

my.cnf CC hilang / tertimpa stub — kemungkinan akibat apt install/reinstall/dpkg-reconfigure paket mariadb-server atau mysql-common di node tsb (file my.cnf.bak tertanggal sehari sebelumnya juga sudah berupa stub, jadi backup itu tidak berguna).

3. Diagnosa yang dijalankan (semua read-only)

Kesimpulan: satu-satunya yang rusak adalah my.cnf. Semua prasyarat SST lain sudah benar.

4. Tindakan perbaikan

Dilakukan di node .110 saja (node sudah down, perubahan config-only, ada backup).

4.1 Backup stub yang ada

cp -av /etc/mysql/my.cnf /etc/mysql/my.cnf.stub-20260911

4.2 Restore my.cnf template ClusterControl

Ambil my.cnf dari .108 (db3-c2-Write-223 — subnet, gmcast.segment, dan role identik) sebagai template. Ubah hanya baris spesifik node:

sed -e 's/^wsrep_node_address=192\.168\.223\.108/wsrep_node_address=192.168.223.110/' \
    -e 's/^wsrep_node_name=192\.168\.223\.108/wsrep_node_name=192.168.223.110/' \
    -e 's/^# wsrep_node_incoming_address = 192\.168\.223\.108/# wsrep_node_incoming_address = 192.168.223.110/' \
    my.cnf.from-108 > my.cnf.110.new

Yang tetap sama dengan template (jangan diubah): wsrep_provider, wsrep_cluster_address (daftar 4 node), wsrep_cluster_name="cluster-2", wsrep_provider_options (gcache.size=1024M;gmcast.segment=0;gcache.recover=yes;socket.ssl_*), wsrep_sst_method=mariabackup, read_only=ON, server_id=2000, wsrep_gtid_domain_id=2000, blok [sst] (encrypt=3, sockopt=",cipher=AES128-SHA,verify=0"), !include /etc/mysql/secrets-backup.cnf.

Pasang file + samakan owner/permission (mysql:root, 0644):

scp my.cnf.110.new root@192.168.223.110:/etc/mysql/my.cnf.new
ssh root@192.168.223.110 'chown mysql:root /etc/mysql/my.cnf.new && chmod 0644 /etc/mysql/my.cnf.new && mv -f /etc/mysql/my.cnf.new /etc/mysql/my.cnf'

4.3 Validasi parsing

my_print_defaults --mysqld | grep -Ei 'wsrep_provider=|wsrep_on|wsrep_cluster_address|wsrep_node_address|wsrep_node_name|wsrep_sst_method|read_only'

Output yang diharapkan (semua muncul, dan bind-address=127.0.0.1 sudah hilang):

--wsrep_provider=/usr/lib/galera/libgalera_smm.so
--wsrep_on=ON
--wsrep_node_address=192.168.223.110
--wsrep_cluster_address=gcomm://192.168.223.113:4567,192.168.223.110:4567,192.168.223.108:4567,192.168.143.31:4567
--wsrep_node_name=192.168.223.110
--wsrep_sst_method=mariabackup
--read_only=ON

4.4 Reset state unit

systemctl reset-failed mariadb

Datadir tidak dibersihkan manual — job resync ClusterControl (initial: true) sudah otomatis rm -rf /var/lib/mysql/* sendiri.

5. Eksekusi resync & hasil

1. Pastikan Cluster Autorecovery & Node Autorecovery kembali ON di ClusterControl (job yang gagal sebelumnya sempat men-set keduanya ke false).
2. Nodes → 192.168.223.110 → Resync Node (menjalankan RESTART initial: true).

Log job (berhasil):

00:37:19  192.168.223.110:3306: Preparing initial start (SST).
00:37:19  Removing ('/var/lib/mysql/*') for initial start.
00:37:31  WSREP: Recovered position 00000000-...:-1,0-0-0
00:38:01  Started MariaDB 11.8.9 database server.
00:38:04  The mariadb service was started, but it may take some minutes to become SYNCED (IST or SST).

Verifikasi di node .110:

SHOW GLOBAL STATUS WHERE Variable_name IN
 ('wsrep_local_state_comment','wsrep_cluster_size','wsrep_cluster_status',
  'wsrep_connected','wsrep_ready','wsrep_evs_state');

wsrep_local_state_comment  Synced
wsrep_cluster_size         4
wsrep_cluster_status       Primary
wsrep_connected            ON
wsrep_ready                ON
wsrep_evs_state            OPERATIONAL
@@read_only                1

Cluster kembali 4/4 node Synced.

6. Verifikasi posisi data pasca-resync (223.110 vs 143.31)

Dilakukan setelah node Synced untuk memastikan data benar-benar konvergen, bukan sekadar “service up”.

6.1 Posisi replikasi — identik

grastate.dat kedua node: uuid: 46cea2d4-…, seqno: -1 (normal untuk node yang sedang running — seqno hanya ditulis saat clean shutdown).

6.2 Verifikasi level data — identik

Perintah yang dipakai:

SELECT @@hostname, @@gtid_current_pos,
 (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS
   WHERE VARIABLE_NAME='wsrep_last_committed') AS last_committed;
CHECKSUM TABLE db_cloud.migrations, db_cloud.users EXTENDED;

6.3 Catatan: kolom table_rows yang beda itu WAJAR

information_schema.tables.table_rows menunjukkan angka berbeda antar node (mis. cbt_stiq 34.876 vs 36.239, maileroo 11.434 vs 13.117). Ini bukan data divergen. Untuk InnoDB angka itu = estimasi optimizer hasil sampling statistik, beda-beda tergantung kapan ANALYZE TABLE terakhir jalan di tiap node. Yang otoritatif adalah GTID + CHECKSUM TABLE di atas — dan itu identik. Jangan pakai table_rows untuk membandingkan konsistensi Galera.

Untuk audit konsistensi menyeluruh (bukan sekadar posisi), gunakan pt-table-checksum (Percona Toolkit) dari node writer .113; jalankan di jam sepi karena menambah beban.

7. Temuan: versi minor tidak seragam — saran rolling upgrade

Saat verifikasi ketahuan versi running antar node tidak sama:

Hanya .110 yang sudah di 11.8.9 (paket dan running). Kemungkinan besar apt upgrade di .110 inilah yang memicu my.cnf tertimpa stub (lihat bagian 2) — paket lain tidak diupgrade.

Risiko kondisi sekarang: rendah. Galera + MariaDB 11.8.x toleran beda patch version untuk operasi normal. Tapi campur versi sebaiknya tidak dibiarkan lama: replikasi writeset antar versi berbeda tidak dijamin untuk skenario tertentu (perubahan format, bugfix replikasi), dan SST/IST bisa rewel.

Rekomendasi: rolling upgrade semua node ke 11.8.9

Prasyarat:

• Backup sudah tervalidasi (ClusterControl backup / mariabackup) sebelum mulai.
• Cluster + Node Autorecovery = OFF di ClusterControl selama proses, biar CC tidak
  ikut campur saat node di-restart manual.
• Kerjakan satu node pada satu waktu, tunggu wsrep_local_state_comment = Synced sebelum lanjut.

Urutan (node paling tidak kritis dulu, primary terakhir):

1. 192.168.143.31 (db4-c2-ReadOnly)
2. 192.168.223.108 (db3-c2-Write, read_only)
3. 192.168.223.110 (db2-c2-Write) — sudah 11.8.9, skip
4. 192.168.223.113 (db1-c2-Write, primary) — terakhir. Pindahкан traffic tulis dari aplikasi/
   proxy (mis. arahkan ke .108/.110 sementara & jadikan salah satu writable) sebelum restart.

Langkah per node:

# 1. konfirmasi node Synced & cluster size penuh sebelum mulai
mariadb -N -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size'; SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"

# 2. simpan salinan my.cnf DULU (apt upgrade bisa menimpanya dengan stub!)
cp -av /etc/mysql/my.cnf /root/my.cnf.pre-upgrade-$(date +%Y%m%d)

# 3. upgrade paket
apt update && apt install --only-upgrade mariadb-server mariadb-client mariadb-backup galera-4

# 4. WAJIB: cek my.cnf tidak tertimpa stub; kalau iya, restore dari salinan di langkah 2
grep -q wsrep_provider /etc/mysql/my.cnf || cp -av /root/my.cnf.pre-upgrade-* /etc/mysql/my.cnf

# 5. restart & mariadb-upgrade
systemctl restart mariadb
mariadb-upgrade --silent

# 6. tunggu sampai Synced sebelum lanjut ke node berikutnya
watch -n2 "mariadb -N -e \"SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment'\""

Setelah semua node 11.8.9: nyalakan kembali Autorecovery, kembalikan konfigurasi writer ke .113, dan verifikasi ulang posisi data seperti bagian 6.

Alternatif lebih aman: pakai fitur ClusterControl → Manage → Upgrades (rolling minor upgrade otomatis, node-by-node). Tetap ambil salinan my.cnf tiap node sebelum menjalankannya.

8. Pelajaran & pencegahan

• my.cnf di setup ClusterControl adalah file kritis dan tidak di-backup otomatis oleh CC. Jika hilang/tertimpa stub, node tidak akan pernah bisa start sebagai anggota Galera.
• Diagnosa Table 'mysql.db' doesn't exist saat SST: cek dulu my_print_defaults --mysqld | grep wsrep. Kalau kosong → masalahnya config, bukan datadir / system table.
• Hati-hati apt upgrade / dpkg-reconfigure pada paket mariadb-server / mysql-common di node yang dikelola CC — bisa menimpa /etc/mysql/my.cnf dengan stub. Setelah operasi paket, selalu diff my.cnf terhadap node lain.
• Simpan salinan my.cnf tiap node (mis. di snippet/repo config, atau etckeeper). Template antar-node hanya beda 3 baris: wsrep_node_address, wsrep_node_name, wsrep_node_incoming_address.
• Backup .bak belum tentu valid — my.cnf.bak di node ini ternyata juga sudah berupa stub. Verifikasi isi backup, jangan asal ada file.
• Node “Write” yang bukan primary (mis. .108, .110) tetap read_only=ON di config; hanya .113 (db1) yang writable. Pertahankan pola ini saat restore.
• Sebelum apt upgrade node manapun, cp dulu my.cnf ke lokasi aman, lalu grep -q wsrep_provider /etc/mysql/my.cnf setelahnya. Ini urutan wajib di prosedur rolling upgrade (bagian 7).
• Jangan bandingkan konsistensi Galera pakai information_schema.tables.table_rows — itu estimasi, bukan angka nyata. Pakai @@gtid_current_pos + CHECKSUM TABLE, atau pt-table-checksum untuk audit penuh (bagian 6.3).
• Cluster sempat campur versi (.110 di 11.8.9, tiga node lain 11.8.6). Jadwalkan rolling upgrade biar seragam — detail di bagian 7.

9. Lampiran — perbedaan node-specific pada my.cnf

Hanya baris berikut yang berbeda antar node (sisanya identik):