Uzun süredir çalışan mysql "temizleme" işlemi

Question

Bir satır seçmeye çalıştığımda düzensiz olarak atılan MySQL (AWS RDS) v5.6.19a'daki 'Bekleme zaman aşımı aşıldı' hatalarını ayıklamaya çalışıyorum. güncelleme için birincil kimliği, yani:

SELECT primary_id FROM tbl_widgets WHERE primary_id = 5 FOR UPDATE 

kaç saat ayıklama sonra (belirgin suçlu idi) aynı satır kilitleme 'doğrudan' benim uygulamasının başka bir bölümüne dışladı.

SHOW ENGINE INNODB STATUS; 

uzun olduğu görülmektedir: Bunun gibi hata atılır ve bilgilerin tarafından sağlanan 'aşıldı Kilit bekleme zaman aşımı' mysql kilitleme olan tavşan deliğinden ineceğinize başlamış ve aralarında şu korelasyon fark etmiş

2015-08-19 13:29:04 
---TRANSACTION 25861246681, ACTIVE 158 sec 
10 lock struct(s), heap size 1184, 21 row lock(s), undo log entries 20 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7146839061 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:29:42 
---TRANSACTION 25861246681, ACTIVE 196 sec 
13 lock struct(s), heap size 2936, 28 row lock(s), undo log entries 27 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7147149416 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:30:10 
---TRANSACTION 25861246681, ACTIVE 224 sec 
13 lock struct(s), heap size 2936, 31 row lock(s), undo log entries 30 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id23 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:30:41 
---TRANSACTION 25861246681, ACTIVE 255 sec 
13 lock struct(s), heap size 2936, 35 row lock(s), undo log entries 34 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7147511090 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:31:12 
---TRANSACTION 25861246681, ACTIVE 286 sec 
15 lock struct(s), heap size 2936, 38 row lock(s), undo log entries 37 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7147604774 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:31:30 
---TRANSACTION 25861246681, ACTIVE 304 sec 
21 lock struct(s), heap size 2936, 42 row lock(s), undo log entries 39 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7147789789 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:31:57 
---TRANSACTION 25861246681, ACTIVE 331 sec 
21 lock struct(s), heap size 2936, 46 row lock(s), undo log entries 43 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7147837536 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:32:28 
---TRANSACTION 25861246681, ACTIVE 362 sec 
22 lock struct(s), heap size 2936, 51 row lock(s), undo log entries 48 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7147905807 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:33:16 
---TRANSACTION 25861246681, ACTIVE 410 sec 
23 lock struct(s), heap size 2936, 58 row lock(s), undo log entries 55 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7148317478 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

2015-08-19 13:33:49 
---TRANSACTION 25861246681, ACTIVE 443 sec 
24 lock struct(s), heap size 2936, 64 row lock(s), undo log entries 61 
MySQL thread id 5110120, OS thread handle 0x2ba082506700, query id 7148471519 10.0.1.154 mfuser cleaning up 
Trx read view will not see trx with id >= 25861246682, sees < 25861246682 

ben rastladım: çalışan iŞLEM 10 dakika kadar için satır yavaş artan sayıda ~ kilitliyor devlet temizleyerek, burada 10 manuel InnoDB dURUMU sorgularından bu işlem için ilgili çizgilerdir blog gönderisini takip etme (http://databaseblog.myname.nl/2014/10/when-your-query-is-blocked-but-there-is_26.html) bu uzun çalışan işlemde neler olduğunu belirlemeye yardımcı olan bir potansiyel çözüm sağlar, özellikle ayarlamak için:

set GLOBAL innodb_status_output_locks=ON; 

Maalesef nedeniyle kısıtlı izinleri RDS bu işlemi gerçekleştirmek mümkün değildir.

Bu işleminin temizlenmesine nasıl yardımcı olabileceğimi ve muhtemelen bunların hepsini nasıl önleyeceğiyle ilgili bazı hata ayıklama yardımlarını rica ediyorum.

Düzenleme eklemek için: MySQL örneğinin ortalama CPU kullanımı benim ben benim ayıklayıcısını koşuyordu JVM öldürdükten sonra kilitleri gittiler "temizlik" Benim durumumda% 20

Answer 1

olduğunu Görünüşe göre bir kalıntı vardı. Daha önceki bir hata ayıklama işleminin çalışması, işlem temizlenmeden önce kesintiye uğradım.

Muhtemelen bu size yardımcı olmuyor, ancak burada bu hata ayıklama için birkaç öneri var.

1. Kilitleme sayısı olan bir parça bilginiz var. Kesme noktalarını kullanarak, sayım bittiğinde tam olarak denemek ve kesinleştirmek için uygulamayı çeşitli yerlerde duraklatabilirsiniz. (Ya da, yalnızca belirli hataların günlüğünde göründükten sonra veya yalnızca belirli kullanıcı eylemlerinden sonra ortaya çıkar.)

2. Kesme noktalarını kullanamazsanız, başka bir aracınız vardır, bu select for update ifadesidir. kilit oluştuktan sonra bloklar. Engellemenin başladığı yeri kesin olarak belirlemek için kodunuzun etrafına, muhtemelen ek günlüğe kaydetme ile serpebilirsiniz. Uygulamayı yerel olarak yüklenmiş bir MySQL veritabanına karşı geçici olarak hata ayıklamayı göz önünde bulundurun.

3. Bu, yerel bir sunucuya veya geliştirme makinenize yüklenebilir. Bu kurmak için bir güçlük olabilir, ama başka birçok yararları olabilir (db komut örneğin test yatağı;. Çevrimdışı iken dizüstü çalışma yeteneği)

Tüm bu kilit neden olup varsayar senin kendi kodu ve başka bir iş tarafından değil. (Günlüğünüzde temizlik kullanıcısı "mfuser" dır.) Bu, talep üzerine sorunu yeniden oluşturmanızı mümkün kılar.