MySQL çöktü ve başlamıyor

Üretim mysql sunucumuz çöktü ve geri gelmeyecek. Segfault hatası veriyor. Yeniden başlatmayı denedim ve başka ne denemek bilmiyorum. İşte stacktrace:

140502 14:13:05 [Not] 'FEDERATED' eklentisi devre dışı.
InnoDB: Günlük taraması kontrol noktası lsn 108'den ilerledi 105 1057948207
140502 14:13:06 InnoDB: Veritabanı normal şekilde kapatılmadı!
InnoDB: Çökme kurtarma başlatılıyor.
InnoDB: .ibd dosyalarından tablo alanı bilgilerini okuma ...
InnoDB: Olası yarı yazılı veri sayfalarını çift yazıdan geri yükleme
InnoDB: tampon ...
InnoDB: Kurtarma yapıyor: günlük sıra numarası 108 1058059648'e kadar tarandı
InnoDB: Geri alınması veya temizlenmesi gereken 1 işlem
InnoDB: geri alınacak toplam 15 satırlık işlemlerde
InnoDB: Trx id sayacı 0 562485504
140502 14:13:06 InnoDB: Veritabanına toplu iş kayıtları uygulama grubunun başlatılması ...
InnoDB: Yüzdelerdeki ilerleme: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Toplu işlemi uygulandı tamamlandı
InnoDB: Taahhütsüz işlemlerin geri alınmasının arka planda başlaması
140502 14:13:06 InnoDB: Trx id 0 562485192, geri alınacak 15 satır ile geri alınıyor
140502 14:13:06 InnoDB: Başladı; günlüğü sıra numarası 108 1058059648
140502 14:13:06 InnoDB: ../../../storage/innobase/fsp/fsp0fsp.c satır 1593 dosyasındaki 1873206128 numaralı iplikte onaylama hatası
InnoDB: Hatalı iddia: frag_n_used> 0
InnoDB: Kasıtlı olarak bir hafıza tuzağı üretiyoruz.
InnoDB: http://bugs.mysql.com adresine ayrıntılı bir hata raporu gönderin.
InnoDB: Tekrarlanan onaylama hataları veya çökmeleri yaşarsanız,
InnoDB: mysqld başlangıcından hemen sonra,
InnoDB: InnoDB tablo alanındaki bozulma. Bakınız
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: kurtarmaya zorlama hakkında.
140502 14:13:06 - mysqld 6 sinyali aldı;
Bunun nedeni bir hataya çarpmanız olabilir. Bu ikili programın
veya bağlantılı olduğu kütüphanelerden biri bozuk, yanlış yapılmış,
veya yanlış yapılandırılmış. Bu hata, arızalı donanımdan da kaynaklanabilir.
Teşhise yardımcı olacak bazı bilgileri kazımak için elimizden geleni yapacağız
sorun, ama zaten çöktüğümüz için, bir şeyler kesinlikle yanlış
ve bu başarısız olabilir.

key_buffer_size = 16777216
read_buffer_size = 131072
max_used_connections = 0
max_threads = 151
threads_connected = 0
MySQL'in en fazla 
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K
bellek baytı
Umarım bu iyidir; değilse, denklemdeki bazı değişkenleri azaltın.

thd: 0x0
Geri izleme deneniyor. Öğrenmek için aşağıdaki bilgileri kullanabilirsiniz
mysqld öldü. Bundan sonra mesaj görmüyorsanız, bir şeyler gitti
çok yanlış ...
stack_bottom = (nil) thread_stack 0x30000
140502 14:13:06 [Not] Etkinlik Zamanlayıcı: Yüklenen 0 etkinlik
140502 14:13:06 [Not] / usr / sbin / mysqld: bağlantılara hazır.
Sürüm: '5.1.41-3ubuntu12.10' soket: '/var/run/mysqld/mysqld.sock' bağlantı noktası: 3306 (Ubuntu)
/ usr / sbin / mysqld (my_print_stacktrace + 0x2d) [0xb7579cbd]
/ usr / sbin / mysqld (handle_segfault + 0x494) [0xb7245854]
[0xb6fc0400]
/lib/tls/i686/cmov/libc.so.6(abort+0x182) [0xb6cc5a82]
/ usr / sbin / mysqld (+ 0x4867e9) [0xb74647e9]
/ usr / sbin / mysqld (btr_page_free_low + 0x122) [0xb74f1622]
/ usr / sbin / mysqld (btr_compress + 0x684) [0xb74f4ca4]
/ usr / sbin / mysqld (btr_cur_compress_if_useful + 0xe7) [0xb74284e7]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72]
/ usr / sbin / mysqld (btr_node_ptr_delete + 0x82) [0xb74f4012]
/ usr / sbin / mysqld (btr_discard_page + 0x175) [0xb74f41e5]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28]
/ usr / sbin / mysqld (+ 0x526197) [0xb7504197]
/ usr / sbin / mysqld (row_undo_ins + 0x1b1) [0xb7504771]
/ usr / sbin / mysqld (row_undo_step + 0x25f) [0xb74c210f]
/ usr / sbin / mysqld (que_run_threads + 0x58a) [0xb74a31da]
/ usr / sbin / mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0xb6f9f96e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb6d65a4e]
Http://dev.mysql.com/doc/mysql/en/crashing.html adresindeki manuel sayfa şunları içerir:
çökmeye neyin neden olduğunu bulmanıza yardımcı olacak bilgiler.

Herhangi bir tavsiye?

Ahh.

InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

Önerilen web sayfasını kontrol edin: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html .

Temel olarak, MySQL sunucusunu kurtarma modunda başlatmayı ve çökmüş tablolarınızın yedeğini almayı deneyin .

Kendinizi düzenleyin /etc/my.cnfve ekleyin:

 innodb_force_recovery = 1

... veritabanınıza girip verilerinizi alıp alamayacağınızı / bozuk tabloyu bulabileceğinizi görmek için.

Genellikle, bu bir yeniden oluşturma (en azından bozuk bir tablo veya iki).

Gönderen http://chepri.com/mysql-innodb-corruption-and-recovery/ :

1. Durdur mysqld( service mysql stop).
2. Destek olmak /var/lib/mysql/ib*

3. Aşağıdaki satırı ekleyin /etc/my.cnf:

   innodb_force_recovery = 1
   

   (4 önerirler, ancak 1 ile başlamak ve başlamazsa artırmak en iyisidir)

4. Yeniden başlat mysqld( service mysql start).

5. Tüm tabloları dök: mysqldump -A > dump.sql
6. Kurtarma gerektiren tüm veritabanlarını bırakın.
7. Durdur mysqld( service mysql stop).
8. Kaldırmak /var/lib/mysql/ib*
9. Yorumla innodb_force_recovery içinde/etc/my.cnf
10. Yeniden başlat mysqld. MySQL hata günlüğüne bakın. Varsayılan olarak /var/lib/mysql/server/hostname.com.err, yeni ib*dosyaları nasıl oluşturduğunu görmek olmalıdır .
11. Veritabanlarını dökümden geri yükleyin: mysql < dump.sql

MySQL: 5.7 Docker görüntü kullanırken aynı hatayla karşı karşıya idi. Ana hata, varsayılan olarak var olan kök kullanıcı oluşturmaya çalışıyordu. Daha fazla bilgi: https://github.com/docker-library/mysql/issues/129

Yukarıdaki bağlantıda verildiği gibi çözüm, docker görüntüsünü başlatırken ortam değişkenlerinde MYSQL_USER ve MYSQL_PASSWORD ayarlamıyordu.

Bu bana Laravel Homestead'de (Mac OS Sierra 10.12.4 (16E195) çalıştıran bir çekirdek paniğinden sonra Vagrant) oldu:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper

Onarım seçeneklerinden hiçbiri benim için çalışmadı, ancak deneyebileceğiniz bazı kaynaklar :

https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-database

MySQL yapılandırma için kuvvet kurtarma eklemeye çalıştım (sözde daha yüksek sayılar kalıcı bozulmaya neden olabilir çünkü 1'den başlayın ve giderek daha yüksek gidin):

sudo nano /etc/mysql/my.cnf

[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled

Başka bir pencerede şunu çalıştırın:

tail -f /var/log/mysql/error.log

Ardından, çeşitli seçenekler etkinken mysqld'i yeniden başlatmayı deneyin:

sudo /etc/init.d/mysql restart

Zaman aşımına uğradığında, mysql işlemlerini aşağıdakilerle yeniden başlatmaya zorlayabilirsiniz:

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
sudo kill -9 <process-id>
sudo /etc/init.d/mysql restart

Çalışırsa, günlük aşağıdaki gibi bir şey gösterir:

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

Başarısız olursa, günlük aşağıdaki gibi bir şey gösterir:

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420

Daha kötüsü kötüleştiğinde, bozuk olması muhtemel veritabanlarını kaldırmayı denedim:

sudo ls -alt /var/lib/mysql

Üzerinde çalıştığım veritabanının listenin en üstünde en son değiştirilen veritabanı olduğu ortaya çıktı. Neyse ki o gün için bir SQL dökümü vardı, bu yüzden kaldırmak mümkün oldu:

sudo rm -rf /var/lib/mysql/<database_name>

Diğer tüm dosyaları bıraktım ve mysql yine de başlayabildi.

GÜNCELLEME: innodb_force_recovery = 1mysql tekrar çalıştığında devre dışı bıraktığınızdan emin olun , aksi takdirde veritabanlarını ve tabloları değiştirmeye çalıştığınızda hata alırsınız.

Sonra veritabanını Sequel Pro ile yeniden oluşturdum, verilerimi yeniden aktardım ve diğer projelerimden tüm veritabanlarını atmak zorunda kalmadan ilerleyebildim.

Gelecekte, herhangi bir mysql veritabanının bozulabileceğini ve günlük yedeklemeleri tutmaya çalışacağını ve veritabanı rekreasyon komut dosyasının belgelendirildiğini veya sürekli entegrasyon araçlarına kodlandığını varsaymalıyım.