Bekleyen işlemlerle MySQL tablosunu silme

MySQL'de (tercihen dosya sistemi düzeyinde) bekleyen işlemleri içeren bir InnoDB tablosunu veya veritabanını silmenin bir yolu var mı?

Ne oldu:

MySQL 5.5.28 kullanın ve LOAD DATA INFILE…bir InnoDB tabloya büyük bir veri kümesi (300M satır) almak için koştu . Daha set autocommit = 0;önce kullanmadım . Ne yazık ki, mysqldithalatın tam ortasında durduruldu.

Yeniden mysqlbaşlattığınızda, sistem günlüğünü böyle iletilerle dolduran işlemi geri almaya çalışır:

mysqld_safe [4433]: 121212 16:58:52 InnoDB: 1 aktif işlemin tamamlanması bekleniyor

Sorun şu ki, geri alma işlemi 25 saatten daha uzun bir süredir çalışıyor ve bu arada mysqldherhangi bir soket bağlantısı kabul etmiyor.

/var/lib/mysql/*Bu makinede başka InnoDB veritabanları / tabloları da olduğu için sadece sıfırdan başlayamıyorum. Ancak, sorunlu tablo ayrı bir veritabanındaki tek tablodur. Daha sonra tüm verileri yeniden içe aktarabildiğim için tüm tabloyu veya veritabanını silmek sorun değil.

Gerçekten yapabileceğiniz hiçbir şey yoktur, çünkü ibdata1 içindeki UNDO tablo alanı aracılığıyla son derece büyüyecek bir geri dönüş yapılıyor .

Eğer mysqld işlemini öldürür ve mysql'i yeniden başlatırsanız, çökme kurtarma döngüsünün bir parçası olarak kaldığı yerden devam edecektir.

YASAL UYARI: Veri Kaybından Sorumlu Değil

Yapabilecekleriniz diğer tablolar için veri kaybına neden olabilir, ancak InnoDB'nin normal çökme kurtarma döngüsünü atlatmak için yapabileceğiniz bir şey vardır.

İnnodb_force_recovery adlı InnoDB kilitlenme kurtarmanın çeşitli aşamalarını atlamanızı sağlayan bir başlatma seçeneği vardır .

InnoDB Recovery'yi Zorlamak için MySQL Belgelerine göre , ayarlar ve etkileri şunlardır:

1 (SRV_FORCE_IGNORE_CORRUPT)

Bozuk bir sayfa algılasa bile sunucunun çalışmasına izin verin. SELECT * FROM tbl_name bozuk tabloları ve döküm tablolar yardımcı sayfalar üzerinden atlamak için deneyin.

2 (SRV_FORCE_NO_BACKGROUND)

Ana iş parçacığının çalışmasını önleyin. Temizleme işlemi sırasında bir kilitlenme meydana gelirse, bu kurtarma değeri engellemeyi önler.

3 (SRV_FORCE_NO_TRX_UNDO)

Kilitlenme kurtarma işleminden sonra işlem geri almalarını çalıştırmayın.

4 (SRV_FORCE_NO_IBUF_MERGE)

Insert buffer birleştirme işlemlerini önleyin. Eğer bir kazaya neden olurlarsa, onları yapmayın. Tablo istatistiklerini hesaplamayın.

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

Veritabanını başlatırken geri alma günlüklerine bakmayın: InnoDB, tamamlanmamış işlemleri bile işlem görür.

6 (SRV_FORCE_NO_LOG_REDO)

Kurtarma işlemiyle bağlantılı olarak yeniden günlüğe kaydetme işlemini yeniden yapmayın.

UNDO ve REDO günlüklerine gömülü işlem değişiklikleriyle,

• yazılacak veriyi kaybetmek
• verileri silinmek üzere tutmak

Kötü yan etkiler beklerseniz, tüm / var / lib / mysql dosyasını yedekleyin ve ibdata1, ib_logfile0 ve ib_logfile1 kopyalayıp normal kurtarmayı yeniden denemek istediğinizde bir yere koyun.

MySQL modlardan birinde tamamen yukarıdaysa

• mysqldump rahatsız edici tablo dışındaki tüm verileri
• kapatma mysql
• / var / lib / mysql / mysql dışında / var / lib / mysql içindeki her şeyi kaldır
• mysql başlat
• mysqldump'ı yeniden yükle

CAVEAT: Her şeyi yedeklediğinizden emin olun !!!

Umarım bu yardımcı olur !!!

Bu hafta benzer bir durum yaşadım.

Ve bir test sunucusuna tam bir yedeklemeyi geri yükledikten ve dev bekleyen işlemlerle tabloları bırakmaya, silmeye veya öldürmeye çalışmanın dört yinelemesinden sonra, sonunda Cuma öğleden sonraya gittik ve çalışmasına izin vermeye karar verdik. Üç gün içinde, işlem ihmal edilebilir sunucu yükü ile bitti ve veritabanı iyiydi. Hangi denenmiş ve başarısız .frm dosyaları ve mysql tablolarda manuel işlemlerin herhangi daha çok daha iyi oldu.

Benim çözümüm: Silmeyin . Birkaç gün boyunca diğer işlemleri ertelemeniz veya bir yerde disk alanı bulmanız veya köle sunucunuzun yükü almasına izin verseniz bile, bekleyen işlemlerin bitmesine izin verin.