MySQL terus mogok: InnoDB: Tidak dapat mengunci ./ibdata1, kesalahan: 11

43

Saya memiliki server web sederhana (Debian 6.0 x86, DirectAdmin dengan memori 1 GB dan masih 10 GB ruang kosong, versi mySQl 5.5.9), namun server mySQL terus macet dan saya harus mematikan semua proses mySQL untuk dapat memulai kembali lagi.

/var/log/mysql-error.log keluaran:

130210 21:04:26 InnoDB: Using Linux native AIO
130210 21:04:34 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:05:42 InnoDB: Completed initialization of buffer pool
130210 21:05:48 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:22 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:27 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:06:29 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:07:22 InnoDB: Completed initialization of buffer pool
130210 21:07:51 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:08:33 InnoDB: Completed initialization of buffer pool
130210 21:12:03 [Note] Plugin 'FEDERATED' is disabled.
130210 21:12:47 InnoDB: The InnoDB memory heap is disabled
130210 21:12:47 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
130210 21:12:47 InnoDB: Compressed tables use zlib 1.2.3
130210 21:12:47 InnoDB: Using Linux native AIO
130210 21:13:11 InnoDB: highest supported file format is Barracuda.
130210 21:13:23 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130210 21:14:05  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
130210 21:17:53  InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
130210 21:17:53  InnoDB: Operating system error number 11 in a file operation.

Saya telah menemukan topik di situs web mySQL di sini namun tidak ada solusi untuk itu.

Ada ide?

mysql  debian 
— Devator
sumber
Dan versi MySQL manakah ini?
— Michael Hampton
Saya tidak mengerti - ini bagian dari file log menceritakan tentang masalah dengan MySQL mulai bukan tentang penyebab kesalahan. Yang terbaik adalah menghapus sumber masalah.
— Krzysztof Księżyk
@MichaelHampton Posting telah diedit (mySQL versi 5.5.9 dan meningkatkan log).
— Devator
1
Apakah Anda memeriksa bahwa tidak ada menjalankan mysqld sebelum memulai? Bagaimana?
— symcbean

Jawaban:

32

pendekatan lain dari satu komentar di blog yang sama:

ini membantu saya:

lsof -i: 3306

Kemudian bunuh (nomor proses)

bunuh PROSES -9

mis. bunuh -9 13498

Kemudian cobalah untuk me-restart MySQL lagi.

via http://www.webhostingtalk.com/archive/index.php/t-1070293.html

— Brigo
sumber
1
service mysql restartsudah menunjukkan tidak ada proses yang berjalan, tetapi lsofmenemukannya. Membunuhnya service mysql start,, dan sekarang banjir proses email gagal dapat berhenti. Terimakasih banyak.
— Doyle Lewis
28

dengan ubuntu 14.04. Saya mengalami masalah ini ketika saya mencoba me-restart via

/etc/init.d/mysql restart

Alih-alih mencoba

service mysql restart
— Jens
sumber
1
Terima kasih, ini membantu. Tapi kenapa?
— juga
1
— mloskot
@ juga, jika Anda memiliki skrip init.d gaya lama dan konfigurasi pemula untuk suatu pekerjaan, Anda harus menggunakan service job start, jika tidak, jika Anda memulainya dengan skrip init.d, Upstart tidak akan mengetahuinya dan dapat mencoba untuk mem-boot instance lain. (Setidaknya itulah yang terjadi dengan skrip init default MySQL.)
— wireman
@wireman: itu menjelaskan mengapa paket lain termasuk simpul (server DNS) memiliki masalah serupa. Kapan mereka memutuskan untuk menegakkannya? Saya pikir / etc / init.d lebih unggul karena memungkinkan penyelesaian shell sehingga membebaskan pengguna dari pengetikan yang berlebihan. Kemajuan ke kekuatan -1 :)
— juga
@too Penyelesaian tab Bash dapat disesuaikan. Tidak memiliki apa pun yang praktis untuk Ubuntu, tetapi tampaknya aneh bahwa tidak ada orang yang akan memikirkan servicenama - nama pelengkap tab . Mungkin mengirimkan permintaan fitur ke Canonical melalui pelacak bug mereka?
— CVn
18

Penyebab paling umum dari masalah ini adalah mencoba untuk memulai MySQL ketika sudah berjalan.

Untuk mengatasinya, matikan semua instance MySQL yang berjalan dan kemudian restart menggunakan skrip startup normal Anda, mis service mysql start.

Jangan mencoba untuk memulai MySQL secara manual ketika menggunakan versi paket distribusi kecuali Anda siap untuk dunia yang terluka.

— Michael Hampton
sumber
however the mySQL server keeps crashing- Saya tidak memulai ulang mySQL. Itu hanya crash sendiri, setelah itu saya perlu me-restart itu dengan jelas. ;-)
— Devator
@MichaelHampton dapatkah Anda memberikan sedikit info lebih lanjut tentang 'dunia yang menyakitkan' dan 'mulai MySQL secara manual'? Terima kasih)
— Serge Kvashnin
11

Larutan

buat salinan dari file asli (ibdata1, ib_logfile0, ib_logfile1 ...).

mv ibdata1 ibdata1.bak 
cp -a ibdata1.bak ibdata1

http://cglreport.zhenhua.info/2008/08/mysql-error-unable-to-lock-ibdata1.html

— Brigo
sumber
ajaib membantu saya.
— nils petersohn
apa gunanya cp -a?, saya sudah membaca halaman manual
— Ilja
2
Terima kasih banyak, ini membantu. Tapi kenapa?
— DaviAragao
Saya punya masalah ini setelah gagal me-restart pada db yang berjalan di wadah buruh pelabuhan. Saya membuat tebakan yang mendidik mengapa ini bekerja dan itu adalah bahwa beberapa meta data disimpan dalam file. memindahkannya dan menyalinnya ke lokasi aslinya menghapus metadata yang menentukan itu terkunci. operasi -a mempertahankan atribut file, termasuk atribut terkait SELinux, tetapi tidak metadata, selama salin.
— JDL
2

Ini membantu saya untuk menyelesaikannya:

Hapus semua file ibdata dan biarkan mysql membuatnya.

hentikan mysql:

service mysql stop

buka perpustakaan mysql:

cd /var/lib/mysql/

pindahkan file innodb di suatu tempat jika Anda membutuhkannya:

mv ib* /root/

mulai mysql:

service mysql start
— Ali Caner Öner
sumber
Bergulir melalui jawaban yang bermanfaat saya pikir ini pasti akan berfungsi karena kesalahannya adalah mengeluh karena tidak dapat mengunci file itu. Setelah pindah, mysql berhasil membuat ulang mereka tetapi masih mengeluh ... gila!
— Kyle Burkett
1

Datang ke sini dari googling dari kesalahan berulang yang sama tetapi dengan kode kesalahan 13 ( InnoDB: Unable to lock ./ibdata1, error: 13). Setelah mencoba banyak solusi di internet, menemukan satu yang membantu saya (apparmor!)

Tambahkan baris-baris ini ke config /etc/apparmor.d/usr.sbin.mysqld(dan tentu saja memuat ulang apparmor dan mysql):

/path/to/mysql/data/ r,
/path/to/mysql/data/** rwk,

Perbedaan utama antara sering solusi: dua aturan (untuk dir itu sendiri dan untuk semua file di dalamnya, perhatikan ganda **) dan kopsi untuk memungkinkan mysql untuk mengunci file.

Semoga ini bisa membantu seseorang.

— hlomzik
sumber
Anda juga dapat menambahkannya ke /etc/apparmor.d/local/usr.sbin.mysqld. Buat file jika tidak ada. Untuk detail lebih lanjut, silakan lihat/etc/apparmor.d/local/README
— knb
0

Harap periksa bahwa Anda memiliki pid-fileparameter di [mysql]bagian my.cnffile. Jika tidak ada, itu unable to lock ...ibdata1.. error:1akan terjadi.

— Sachin
sumber
0

Sederhana, tetapi lebih cepat dari cara dengan "cp -a". Dan membantu ketika "cp -a" dan yang lainnya tidak bisa.

  1. service mysql stop && pkill -f mysql

Singkirkan semua proses mysql

  1. vi /etc/mysql/my.cnf

Ubah parameter datadir = / var / lib / mysql ke datadir = / var / lib / mysql2 (atau tambahkan saja jika Anda tidak punya)

  1. mv /var/lib/mysql /var/lib/mysql2

Ubah nama datadir menjadi nama baru

  1. service mysql start

Siapkan rebana Anda

— WSR
sumber
0

Jika tidak ada solusi lain yang berfungsi, masalahnya mungkin berasal dari kesalahan konfigurasi AppArmor.

Jadi lakukan saja:

$ apt install apparmor-profiles

dan kemudian restart MySQL (perhatikan seberapa cepat akan restart).

Saya perhatikan ada file yang hilang terkait dengan AppArmor ketika melakukan:

$ systemctl status mysql.service

Karenanya mengapa saya pikir ada sesuatu yang salah dengan konfigurasi AppArmor.

— fevangelou
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.