SonarQube Replication Lock Investigation

Kenapa replication.lock Lambat Dikemas Kini? Siasatan 3 Hari di Node DR

by

Setup dan Context

Node DR aku, prod-dr-appserver01, ada satu fail kecil tapi penting: /data/app/replication.lock. Fail ni update setiap kali replication sync selesai, jadi umur fail tu jadi proksi untuk tahu sama ada sync running atau stuck.

Zabbix monitor umur fail tu. Kalau lebih 2 jam tak update, alert terus fire. Siasatan ni cover 3 hari: 24, 25, 26 November 2025.

Trigger Logic

now() - vfs.file.time[/data/app/replication.lock] > 7200

Straightforward. Kalau last modified lebih 7,200 saat (2 jam) dari sekarang, trigger aktif. Zabbix check roughly setiap minit.

Findings: 3 Hari, 3 Cerita

24 Nov: Minor

  • Max file age: 2.35 jam (8,455s), slightly over threshold
  • Average age: 12.8 minit, generally healthy
  • 1 problem period: 11:10–11:30 (~20 minit)

Hari pertama boleh lagi excuse sebagai noise. Tapi pattern dah mula nampak.

25 Nov: Worse

  • Max file age: 2.67 jam (9,595s)
  • Average age: 22.7 minit, naik berbanding hari sebelum
  • 2 problem periods: 11:10–11:49 (~39 minit) dan satu lagi petang

Sekarang dah tak boleh anggap noise. Average age naik hampir dua kali ganda dari hari pertama.

26 Nov: Pattern Confirmed

  • Issue cluster sekitar late morning, same window
  • Replication delay correlate dengan production load spike

Tiga hari consecutif, sama window masa. Bukan coincidence.

Pattern Yang Nampak

Delay berlaku consistently dalam window 11:00–12:00. Paling likely correlate dengan aktiviti production: job berjalan, I/O berat, DR replication gets starved masa tu.

Trend pun makin teruk dari hari ke hari. Average age naik, duration breach pun panjang. Kalau biar je, minggu depan mungkin lebih kronik.

Possible Causes

  • Production disk I/O saturated masa peak hours. Replication sync kena tunggu giliran.
  • Network bandwidth contention antara prod dan DR node.
  • Replication process mungkin single-threaded, blocking on large files.

Cara Semak Sekarang

Sebelum buat apa-apa, confirm dulu I/O saturation memang berlaku dalam window tu.

Check disk I/O kat production node

# Real-time I/O per device
iostat -xz 5

# Tengok process mana paling banyak makan I/O
pidstat -d 5

Tengok column %util dalam iostat. Kalau consistently dekat 100% dalam window 11:00–12:00, confirmed bottleneck kat situ.

Semak replication mechanism yang sedang pakai

# Tengok proses rsync atau apa yang running
ps aux | grep -E 'rsync|app'

# Kalau guna rsync, tengok progress
rsync --info=progress2 -az /data/app/ dr-host:/data/app/

Cara Lebih Baik Dari Setup Sekarang

Kalau replication sekarang guna rsync biasa, ada beberapa improvement yang boleh consider.

1. Hadkan I/O bandwidth rsync supaya tak compete dengan production

rsync --bwlimit=50000 -az /data/app/ dr-host:/data/app/

--bwlimit dalam KB/s. Set 50,000 bermakna ~50 MB/s. Adjust ikut keupayaan link korang.

2. Parallelize transfer guna GNU Parallel

Kalau ada banyak subdirektori besar, boleh split kerja supaya transfer jalan serentak.

ls /data/app/ | parallel -j4 rsync -az /data/app/{}/ dr-host:/data/app/{}/

Ini bagi replication habis lebih cepat, kurangkan window masa fail tu tak update.

Leave a Comment