InnoDB tablo bozulmasını nasıl tanımlarsınız?

Bölümlenmiş ve çoğaltılmış bir köle üzerinde birkaç dizin olan bazı tablolarım var. Hızlı çekimi (güvenli olarak doğrulandı) yeni bir köle kopyaladıktan ve mysqld'ü 5.1.42'den 5.5.15'e yükselttikten ve çoğaltmayı yeniden başlattıktan sonra InnoDB'nin "Geçersiz işaretçi ..." hata iletisiyle çökmesini sağlıyorum

Bu hatalar, farklı donanım ve O / S özellikli 2 sunucuda meydana geldi. Koşudan sonra:

ALTER TABLE .... COALESCE PARTION n;

sorun o masa için ortadan kalkıyor.

Benim sorum, kapsamı daha geniş olsa da, "Bu InnoDB'nin masa üstü bozulmasını nasıl tespit ediyorsunuz?" veya rephrased "InnoDB masa sağlığını nasıl değerlendiriyorsunuz?" Mı "FİYATLARI TABLO" ön çarpışma sorunları tespit etmek kullanılabilen tek araçtır?

Önemli olup olmadığından emin değiliz, ancak çalışan çökmeler meydana geldi: Sürüm: '5.5.15-55-log' soket: '/opt/mysql.sock' portu: 3306 Percona Sunucu (GPL), Sürüm rel21.0, Revizyon 158

Morgan , yorumunda InnoDB'nin okuduğu sayfalarda sağlama toplamı yaparak bozuk sayfaları denetlediğine dair bir ipucu veriyor. InnoDB sağlama uyuşmazlığı bulursa, olacak çökmesine sunucu durdurun.

Bu işlemi hızlandırmak istiyorsanız (InnoDB'nin bozuk sayfayı okumasını beklemek yerine), şunları kullanabilirsiniz innochecksum:

Sağlama toplamı uyuşmazlıkları InnoDB'nin çalışan bir sunucuyu kasıtlı olarak kapatmasına neden olacağından, bu aracı kullanmak üretim sunucusunda bozuk sayfalarla karşılaşmasını beklemek yerine tercih edilebilir.

İlginç bir uyarı:

innochecksum, sunucunun önceden açmış olduğu tablo alanı dosyalarında kullanılamaz. Bu tür dosyalar için tablo alanı içindeki tabloları kontrol etmek için KONTROL TABLOSU kullanmalısınız.

Yani evet, bir çevrimiçi tablo CHECK TABLEiçin muhtemelen bir araçtır (veya bir seferde tek bir veritabanından daha fazlasını yapmak istiyorsanız başka bir cevabın da işaret ettiği gibi mysqlcheck).

Veritabanınızı kapatırsanız, sağlama toplamı değerlerini kullanarak innochecksum

Anekdot: 29 GB'lık bir innodb tablo alanında innodb_file_per_table=1, bu yazı yaklaşık 2 dakika sürdü.

#!/bin/bash
for i in $(ls /var/lib/mysql/*/*.ibd)
do
  innochecksum -v $i
done

Buna ek olarak, Percona'yı çalıştırdığınızdan beri hızlı innodb sağlama toplamı için yeni bir yöntem uyguladılar . Hiç kullanmadım, ancak süreci hızlandırabilir.

UYARI: Bu talimatlardan herhangi birini denemeden önce, veritabanınızın sağlıklı bir şekilde yedeklendiğini doğrulamanız önerilir. (uyarı için @Nick'e teşekkürler)

mysqlcheckKomutu kullanmaya çalışın . Bir terminalde:

mysqlcheck -u username -p --databases database1 database2

Bu komut tüm tabloların bir listesini ve bir çeşit yolsuzluk olup olmadığını söyleyen bir durum çıktısı verecektir:

table1  OK
table2  OK
table3  OK
tableN  OK

Bununla birlikte, elinizde hangi tabloları tamir etmeniz gerektiğini zaten bileceksiniz. Her şeyi bir kerede onarmak istemeniz durumunda:

mysqlcheck -u username -p --auto-repair --databases database1 database2 

Daha fazlası için mysqlcheck: http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html

Not: Sorunuzu Percona ile etiketlediniz . Bunun ne olduğu hakkında hiçbir fikrim yoktu, bu yüzden googledim. MySQL'in bir çatalı gibi görünüyor, ancak komutların uyumsuz olduğuna inanmak için hiçbir nedenim yok (parmak çarpıştım).

Biri bana bu kılavuza, tüm veritabanının başlamaması durumunda daha kritik durumlar için InnoDB veritabanı kurtarma için daha özel talimatlar olduğunu belirtti: http://www.softwareprojects.com/resources/programming/t-how-to-fix-mysql -veritabanı-MyISAM-innodb-1634.html

Göre MySQL 5.0 Sertifikasyon Eğitim Kılavuzu, Sayfa 443444 Bölüm 30,4 :

InnoDB tablolarını CHECK TABLE komutunu kullanarak veya sizin için ifadeyi yayınlamak için bir istemci programı kullanarak kontrol edebilirsiniz. Ancak, bir InnoDB tablosunda sorun varsa, ONARIM TABLOSU'nu kullanarak sorunu çözemezsiniz, çünkü bu ifade yalnızca MyISAM için geçerlidir.

Bir tablo kontrolü bir InnoDB tablonun sorun yaşadığını gösteriyorsa, masayı mysqldump ile boşaltarak, bırakarak ve o çöplükten yeniden oluşturarak, tutarlı bir duruma geri yükleyebilmelisiniz.

Bir MySQL Sunucusunun veya üzerinde çalıştığı ana bilgisayarın çökmesi durumunda, bazı InnoDB tablolarının onarılması gerekebilir. Normalde, yalnızca sunucuyu yeniden başlatmak yeterlidir, çünkü InnoDB depolama motoru başlangıç ​​sırasının bir parçası olarak otomatik kurtarma işlemini gerçekleştirir. Nadir durumlarda, InnoDB otomatik kurtarma işleminin başarısız olması nedeniyle sunucu başlatılamayabilir. Bu durumda, aşağıdaki prosedürü kullanın:

• Sunucuyu --innodb_force_recovery seçeneği 1 - 6 arasındaki bir değere ayarlanmış değerde olacak şekilde yeniden başlatın. Bu değerler, bir çarpışmayı önleme konusunda artan dikkat seviyelerini ve kurtarılan tablolardaki olası tutarsızlık için tolerans seviyelerinin arttığını gösterir. Başlamak için iyi bir değer 4.

• Sunucuyu --innodb_force_recovery sıfır olmayan bir değere ayarlandığında başlattığınızda, InnoDB tablo alanını salt okunur olarak algılar. Sonuç olarak, InnoDB tablolarını mysqldump ile boşaltmalı ve seçenek etkinken bunları bırakmalısınız. Ardından --innodb_force_recovery seçeneği olmadan sunucuyu yeniden başlatın. Sunucu açıldığında, InnoDB tablolarını döküm dosyalarından kurtarın.

• Yukarıdaki adımlar başarısız olursa, InnoDB tablolarını önceki bir yedekten geri yüklemek gerekir.

Lütfen InnoDB Zorunlu Kurtarma ile ilgili MySQL Docs'ı okuyun  

Kimse InnoDB Eklentisi ile oluşturulan InnoDB verilerini kullanan ve sonra InnoDB'nin başka bir sürümüne geçerse ne olacağını merak ediyorum. Bu, MySQL'in gözünde olası bir sayfa bozulması oluşturabilir.

InnoDB Dosya Biçimi'ndeki MySQL Belgeleri'nin bu olasılık hakkında ne söylediğini unutmayın:

Genel olarak, InnoDB'nin daha yeni bir sürümü, çökme, takılma, yanlış sonuç veya bozulma riski olmadan, önceki InnoDB sürümüyle güvenli bir şekilde okunamayan veya yazılamayan bir tablo veya dizin oluşturabilir. InnoDB Eklentisi, bu koşullara karşı korunmak ve veritabanı dosyaları ve InnoDB sürümleri arasındaki uyumluluğu korumak için yeni bir mekanizma sunar.

Verileri köle üzerine kazıyorum. Aslında, verilerin mantıksal bir dökümü (mysqldump) alarak sadece kaba kuvvet kullanırdım:

• Kölede InnoDB kullanarak tüm veritabanlarını bırakın
• Köle üzerinde mysql Kapatma
• Slave'de ibdata1, ib_logfile0 ve ib_logfile1 dosyalarını silin
• İbdata1, ib_logfile0 ve ib_logfile1 yeniden oluşturularak köle üzerinde mysql'i başlatın
• mysqld, verileri masterdan köleye aktarır

Gönderilen asıl cevabım 'eski okul' olarak kabul edilir. Ancak, bu durumda, kesinlikle .ibd ve / veya ibdata1 tarafından kullanılan dosya formatlarını inceleyeceğim.