dataiotech Labs
Runbook #17
mysql
MaintenanceSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minsSUPER / CONNECTION_ADMIN / RELOAD / REPLICATION CLIENT

MySQL InnoDB History List Sürekli Büyüyor: Purge Engellerini Bulma

Uzun transaction, replica okuması ve purge kapasitesi sorunlarını ayırarak undo birikimini güvenli biçimde azaltır.

İlişkili Metrik:M17
#innodb#history-list#purge#long-transaction

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- M17 (`trx_rseg_history_len`) aralıksız büyür; undo/disk tüketimi ve sorgu gecikmesi artar.

2. Etki / Impact

Purge gecikmesi nedeniyle eski satır sürümleri birikir; alan ve I/O yükü artar. Sırf yüksek sayı değil, büyüme hızı ve kapasite riski önemlidir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. S33 ile en eski transaction'ları ve history list değerini izleyin:
sql
SELECT trx_id, trx_started, TIMESTAMPDIFF(SECOND,trx_started,NOW()) AS age_s,
       trx_state, trx_mysql_thread_id, trx_rows_locked, LEFT(trx_query,160) AS sql_text
FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 20;
SELECT name, count FROM information_schema.innodb_metrics
WHERE name = 'trx_rseg_history_len';

Metrik etkin değilse `SHOW ENGINE INNODB STATUS\G` içindeki `History list length` değerine bakın. Tek seferlik fotoğraf yerine birkaç aralıklı örnek kullanın.

🟢 Salt Okunur2. S22 ile kilit bekleyenleri kontrol edin. Açık transaction `information_schema.processlist` içinde Sleep görünse dahi undo sürümlerini tutabilir; `trx_mysql_thread_id` ile processlist ID'yi eşleştirin.
🟢 Salt Okunur3. Purge thread'leri işlem yapıyor mu, disk I/O doygun mu ve yük tek büyük transaction'dan mı kaynaklanıyor inceleyin. Replica'daki uzun okuma yalnızca **o replica'nın** purge'unu etkileyebilir; sunucuları ayrı ölçün.

4. Müdahale / Response

🟡 Geri Alınabilir1. İş sahibine danışarak uzun okuma/transaction'ı uygulama tarafında bitirin. İptal edilemiyorsa S33'ten doğrulanmış ID için `KILL <id>;` uygulayın; büyük yazma transaction'ının rollback'i uzun sürebilir.
🟡 Geri Alınabilir2. Büyük DELETE/UPDATE işlerini küçük commit'li parçalara ayırın ve işlem hızını düşürün; purge'un yetişmesine zaman tanıyın.
🟡 Geri Alınabilir3. Uzun transaction yok ama purge CPU/I/O'da gerideyse, `innodb_purge_threads` (sürüme bağlı yapılandırma) ve depolama kapasitesini planlı değişiklikte değerlendirin; önce darboğazı kanıtlayın.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. Disk üzerindeki undo dosyalarını elle silmeyin; `OPTIMIZE TABLE` geçmiş birikimini çözmez ve ek disk ihtiyacı yaratır.

5. Doğrulama / Verification

- M17 artışı durur, ardından kademeli düşer; disk doluluk eğilimi ve gecikme iyileşir.

- Yeni uzun açık transaction oluşmaz; replica'ların her birinde ayrı ölçüm yapılır.

6. Geri Alma / Rollback

- Yazma işinin hız sınırı eski haline kontrollü döndürülür; bitirilen transaction geri getirilemez, uygulama gerekirse yeniden dener.

- Purge ayarı değiştiyse eski değeri ve yapılandırma dosyasını geri alın.

Mühendislik Triadı: Doğrudan Teşhis Scriptleri

Bu runbook kriz müdahalesinde darboğazı tespit etmek için önerilen hazır SQL / Shell scriptleri:

Tüm Scriptler (100)
#22 · SQLLocking

MySQL InnoDB Kilit Beklemelerini ve Bloklayan Sorguyu Bulma

sys şeması ile bekleyen ve bloklayan oturumları, kilit modlarıyla birlikte gösterir. Hangi işlemin hangisini beklettiğini tek sorguda çözer.

#33 · SQLLocking

MySQL'de Uzun Süredir Açık InnoDB Transaction'ları

Açık transaction'ları yaşlarına, kilitledikleri satırlara ve son sorgularına göre listeler. Purge'ı engelleyen ve history list'i şişiren işlemleri bulur.

Tetikleyen Alarmlar ve Metrikler
M17MySQL InnoDB History List UzunluğuMySQL

Diğer MYSQL Runbook'ları