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

MySQL InnoDB Lock Wait Timeout: Bloklayıcıyı Bulma ve Çözme

ERROR 1205 ve satır kilidi beklemelerinde bekleyen ile bloklayan transaction'ı eşleştirir; müdahale ve tekrarını önleme adımlarını açıklar.

İlişkili Metrik:M20
İlişkili Script:S22S33
#error-1205#innodb#lock-waits#blocking

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

- `ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction`, M20 artışı.

- Çok sayıda kısa sorgu aynı tabloda bekler. `ERROR 1213` bir **deadlock**'tur ve farklı teşhis gerektirir.

2. Etki / Impact

İşlem zaman aşımına uğrar; MySQL varsayılanında timeout alan **statement** geri alınır, tüm transaction otomatik rollback olmayabilir (`innodb_rollback_on_timeout` ayarına bağlı). Uygulama hatalı biçimde devam ederse kısmi iş mantığı oluşabilir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. S22 ile bekleme ve bloklayan zinciri açın (`sys` şeması etkin olmalı):
sql
SELECT wait_started, wait_age, locked_table, locked_index,
       waiting_pid, LEFT(waiting_query,160) AS waiting_sql,
       blocking_pid, LEFT(blocking_query,160) AS blocking_sql
FROM sys.innodb_lock_waits ORDER BY wait_age DESC;

`blocking_query` boş olabilir: oturum Sleep durumunda açık transaction tutuyordur.

🟢 Salt Okunur2. S33 ile transaction yaşını ve thread kimliğini doğrulayın:
sql
SELECT trx_mysql_thread_id AS pid, trx_started, trx_state,
       trx_rows_locked, trx_rows_modified, LEFT(trx_query,160) AS query_text
FROM information_schema.innodb_trx ORDER BY trx_started;
🟢 Salt Okunur3. 8.0'da `performance_schema.data_lock_waits` ve `data_locks`; 5.7'de `information_schema.innodb_lock_waits`/`innodb_locks` ek ayrıntı verir. `SHOW ENGINE INNODB STATUS\G` anlık özetini kaydedin.
🟢 Salt Okunur4. Uzun transaction'ın sahibini, host'unu, işlemin iş kritikliğini belirleyin. İndeks eksikliği yüzünden gereğinden çok satır kilitlenmiş olabilir.

4. Müdahale / Response

🟡 Geri Alınabilir1. İş sahibine COMMIT/ROLLBACK yaptırın. Bloklayıcı hâlâ sorgu yürütüyorsa önce `KILL QUERY <blocking_pid>;` yalnızca sorguyu keser; **kilit açık transaction'da kalabilir**.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ2. Kök oturumu gerçekten sonlandırmak gerekiyorsa `KILL <blocking_pid>;` uygulayın; açık transaction rollback olur ve büyük rollback uzun sürer. System/replication thread'lerine dokunmayın.
🟡 Geri Alınabilir3. Uygulamanın ERROR 1205 sonrası **transaction'ı açıkça ROLLBACK etmesini** ve tüm iş birimini güvenli, idempotent yeniden denemesini sağlayın.
🟡 Geri Alınabilir4. Kalıcı çözüm: kısa transaction, tablo sırasını tutarlı kullanma, seçici indeks; raporlamayı replica'ya taşıma. İndeks DDL'ini bakım penceresinde test edin.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ5. `innodb_lock_wait_timeout` değerini körlemesine artırmayın; sorunu gizleyip bağlantı birikimini ağırlaştırır.

5. Doğrulama / Verification

- S22 bekleme listesi temizlenir, M20 normalleşir; uygulama işlemleri ve satır sayısı/tutarlılık kontrolü başarılıdır.

- 1205 ve deadlock sayıları ayrı ayrı izlenir; değişiklik sonrası regresyon yoktur.

6. Geri Alma / Rollback

- Sonlandırılan transaction geri gelmez, uygulama kontrollü yeniden denemelidir; indeks veya zaman aşımı ayarını planlı olarak eski değerine alın.

- Olay anında zorla yapılan COMMIT/ROLLBACK geri alınamaz; iş verisini doğrulayın.

Diğer MYSQL Runbook'ları