`mysql_upgrade` gagal tanpa alasan nyata

70

Saya meningkatkan dari MySQL 5.1 ke 5.5, menjalankan mysql_upgradedan mendapatkan output ini:

# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

Setiap ide di mana untuk mencari apa yang terjadi (atau, tidak terjadi?) Sehingga saya bisa memperbaiki apa yang salah dan benar-benar menjalankan mysql_upgrade?

Terima kasih!

Lebih banyak output:

# mysql_upgrade --verbose
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-check --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

User time 0.00, System time 0.00
Maximum resident set size 1260, Integral resident set size 0
Non-physical pagefaults 447, Physical pagefaults 0, Swaps 0
Blocks in 0 out 16, Messages in 0 out 0, Signals 0
Voluntary context switches 9, Involuntary context switches 5

# mysql_upgrade --debug-check
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

Setelah menutup mysqld --skip-grant-tablesvia mysqladmin shutdowndan restart mysql melalui service mysql start, log kesalahan loop melalui set kesalahan berulang:

130730 21:03:27 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
130730 21:03:27 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130730 21:03:27 InnoDB: The InnoDB memory heap is disabled
130730 21:03:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:03:27 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:03:27 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:03:29 InnoDB: Completed initialization of buffer pool
130730 21:03:30 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 588190222435
130730 21:03:30  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 588192055067
130730 21:03:30  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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: Apply batch completed
InnoDB: Last MySQL binlog file position 0 81298895, file name /var/log/mysql/mysql-bin.006008
130730 21:03:33  InnoDB: Waiting for the background threads to start
130730 21:03:34 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:03:34 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
130730 21:03:34 [Note] Starting crash recovery...
130730 21:03:34 [Note] Crash recovery finished.
130730 21:03:34 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:03:34 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:03:34 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist

Log MySQL selama start up via mysqld_safe --skip-grant-tables

130730 21:19:36 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130730 21:19:36 [Note] Plugin 'FEDERATED' is disabled.
130730 21:19:36 InnoDB: The InnoDB memory heap is disabled
130730 21:19:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:19:36 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:19:37 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:19:39 InnoDB: Completed initialization of buffer pool
130730 21:19:39 InnoDB: highest supported file format is Barracuda.
130730 21:19:42  InnoDB: Warning: allocated tablespace 566, old maximum was 0
130730 21:19:42  InnoDB: Waiting for the background threads to start
130730 21:19:43 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:19:43 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:19:43 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:19:43 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:19:43 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
130730 21:19:43 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_consumers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_instruments' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'performance_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'threads' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'mutex_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'rwlock_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_instances' has the wrong structure
130730 21:19:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.04.1-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

Seperti yang saya pahami, semua masalah struktur tabel / keberadaan (terkait dengan tabel sistem mysql) harus diperbaiki dengan menjalankan mysql_upgrade:

mysql  mysql5.5 
— Jim Rubenstein
sumber
Juga mungkin tidak ada nilainya, mysqldberjalan, dengan --skip-grant-tablesopsi. Saya dapat terhubung melalui mysqlterminal tanpa kredensial, dan saya tidak mendapatkan kesalahan melalui syslog atau di mana pun saya bisa memikirkan untuk melihat ketika saya menjalankanmysql_upgrade
— Jim Rubenstein
The Reference Manual MySQL meliputi upgrade ke 5,5 dari 5,1 cukup baik. Jika Anda telah mengikuti semua instruksi di sini, ada baiknya menyebutkan. Jika belum, ya ...
— Aaron Copley
Jika pengguna root mysql Anda tidak memiliki kata sandi, jangan sertakan `-p` dalam` mysql_upgrade -u root -p`
— Jeferex

Jawaban:

95

Saya pikir itu perlu nama pengguna dan kata sandi

mysql_upgrade -u root -p

Jika saya tidak lulus mereka saya mendapatkan kesalahan Anda

Sunting : terima kasih atas komentarnya sekarang saya tahu bahwa ada alasan lain, mungkin kurang sering tetapi lebih baik untuk menyadarinya juga

Jadi, Anda mendapatkan kesalahan itu saat

  • Anda tidak memberikan nama pengguna dan kata sandi
  • Anda lulus kredensial Anda, tetapi mereka salah
  • server MySQL tidak berjalan
  • tabel izin hancur (maka Anda harus me-restart MySQL dengan mysqld --skip-grant-table)
  • tabel mysql.plugin tidak ada (Anda akan melihat kesalahan tentang itu ketika memulai MySQL yang menyarankan untuk menjalankan ... mysql_upgrade, dan itu gagal. Anda mungkin memiliki beberapa konfigurasi yang usang di my.cnf)
— Riccardo Galli
sumber
23
Ini persis masalah yang saya miliki - mengapa tidak bisa hanya mengatakan "Tidak dapat mengotentikasi" atau "Koneksi kesalahan" atau sesuatu? Sangat marah ...
— les2
3
Guys, Anda mendapatkan kesalahan yang sama jika kata sandi Anda juga salah. jadi dihubungi.
— Yoosaf Abdulla
3
Dan Anda mendapatkan kesalahan yang sama jika server tidak berjalan, meskipun tampaknya menerima kata sandi.
— Raman
1
tepat ketika tabel database atau format database rusak juga, itu tidak berfungsi baik, maka Anda perlu memulai daemon dengan "mysqld --skip-grant-tables" dan jalankan mysql_upgrade di terminal lain!
— Henning
+1 untuk ini. Namun alasan lain saya membenci MySQL
— Excalibur
9

Saya baru saja mengalami gejala-gejala yang tepat ketika meningkatkan dari 5,5 ke 5,6, dan ternyata menjadi masalah jangkauan layanan.

Meskipun klien MySQL cli dapat terhubung ke instance DB lokal saya dengan hanya -u dan -p disediakan, saya juga perlu menentukan -h 127.0.0.1 untuk mysql_upgrade karena sedang mencoba koneksi file socket dan gagal total dalam upaya tersebut.

— Aubrey Falconer
sumber
itulah masalah saya karena saya menjalankan mysqd seperti ini: mysqld --skip-grant-tables --user = mysql
— Rodo
9

Tampaknya server Plesk, ketika menggunakan Plesk tidak ada root untuk Mysql, tetapi administrator Mysql memanggil admin, jadi perintah ini harus bekerja pada Plesk seperti yang saya coba sebelumnya:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
— linuxman1
sumber
Ini bekerja dengan baik untuk saya
— xarlymg89
5

Anda dapat mencoba menjalankan ini satu per satu untuk melihat kegagalannya:

mysql_upgrade menjalankan perintah berikut untuk memeriksa dan memperbaiki tabel dan meningkatkan tabel sistem: 

mysqlcheck --all-databases --check-upgrade --auto-repair  
mysql < fix_priv_tables  
mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names

dari http://dev.mysql.com/doc/refman/5.5/id/mysql-upgrade.html

— user16081-JoeT
sumber
1
Pikirkan tentang itu, tetapi fix_priv_tablesadalah skrip yang dihasilkan oleh mysql_upgradeuntuk memperbaiki tabel
— Jim Rubenstein
bagus, mungkin coba saja mysqlcheck baris pertama? Dan coba jalankan dari folder bin secara langsung, fwiw,/usr/bin/mysql_upgrade
— user16081-JoeT
3

Pertanyaan ini sangat umum, dan saya minta maaf untuk itu.

Saya tidak dapat menemukan penyebab langsung dan solusi untuk masalah yang saya alami, jadi saya terpaksa menginstal ulang MySQL untuk melihat apakah itu akan berhasil. Ternyata, menginstal ulang melakukan trik. Itu adalah cara yang payah untuk memperbaikinya, tetapi itu adalah satu-satunya pilihan yang tersisa.

Banyak jawaban lain pada pertanyaan ini adalah masalah yang harus saya selesaikan untuk menjalankan mysql_upgrade pada awalnya, tetapi untuk alasan apa pun - gagal karena mencoba menjalankan beberapa permintaan otomatis, dan saya tidak dapat menemukan dokumentasi yang pertanyaan itu berjalan sehingga saya bisa memperbaikinya.

— Jim Rubenstein
sumber
Ya begitu dir data dari mysql telah rusak ada cukup banyak yang dapat Anda lakukan
— Krauser
2

Anda harus memeriksa izin semua file di bawah data mysql. Seharusnya pemilik yang sama dengan PID mysql (mysql atau _mysql). Ini kadang terjadi karena mengembalikan data dari file tanpa izin yang tepat. Misalnya jika data mysql Anda berada di bawah / var / lib / mysql

chown -R mysql /var/lib/mysql
— asofyan
sumber
2

DBA kami menghapus instalan versi mysql 5.0.95 alih-alih hanya memutakhirkan ke 5.5.39. Penghapusan dicadangkan /etc/my.cnfuntuk /etc/my.cnf.rpmsavekemudian dihapus, dan ini mencegah MySQL memulai dengan benar:

140902 15:00:57 [ERROR] Plugin 'InnoDB' init function returned error.
140902 15:00:57 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140902 15:00:57 [ERROR] Unknown/unsupported storage engine: InnoDB
140902 15:00:57 [ERROR] Aborting

Anda dapat melakukan salah satu dari yang berikut:

  • Bandingkan file my.cnf secara manual dan bawa pengaturan konfigurasi yang sesuai untuk InnoDB

  • Kembalikan my.cnf.rpmsavekembali di atas yang asli (periksa dulu untuk pengaturan default baru yang harus Anda tambahkan!)

  • Gunakan alat diff vimdiffuntuk membandingkan my.cnf.rpmsavedengan yang baru my.cnfdan mengembalikan tweak yang telah dibuat ke konfigurasi MySQL, termasuk pengaturan InnoDB.

    [root]# vimdiff /etc/my.cnf /etc/my.cnf.rpmsave

Saya melakukan opsi terakhir, kemudian dapat memulai MySQL:

root]# service mysqld start
Starting mysqld:                                           [  OK  ]

dan sekarang mysql_upgradeberfungsi dengan baik, menggunakan mysql_upgrade -uroot -pitu meminta saya untuk kata sandi root.

[root]# mysql_upgrade -uroot -p
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
....

Semoga ini membantu!

dan juga menggunakan mysql_upgrade -uroot -pgagal karena perlu MySQL untuk dapat berjalan!

Pelajaran yang dipelajari:

  • Cadangkan my.cnf sebelum memutakhirkan ... Dan lakukan pemutakhiran di tempat alih-alih hapus instalan lalu instal versi yang lebih baru.
  • Dapatkan MySQL berjalan sehingga Anda dapat menggunakan mysql_upgrade.
  • Keuntungan.
— Ronnie
sumber
1

Masalah yang sama untuk saya, tetapi sumber masalah saya adalah format kata sandi lama. Sementara mysql dapat dipaksa untuk terhubung menggunakan format lama dengan "skip-secure-auth", mysql_upgrade tidak memiliki opsi ini. Pertama-tama Anda perlu memperbarui kata sandi root dengan format baru dan kemudian Anda dapat memutakhirkan mysql Anda.

— Leandro Dardini
sumber
1

Mengalami masalah yang sama meningkatkan dari 5.1 ke 5.5.

Ini bekerja untuk saya: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Kesalahan saya mungkin disebabkan oleh izin ke jalur soket, tetapi tidak punya waktu untuk memverifikasi itu penyebabnya.

— Kapten
sumber
Saya telah memindahkan DataDir saya pada suatu waktu, saya kira itu sebabnya saya membutuhkan jalur ke soket
— zzapper
0

Saya juga mengalami hal ini setelah memutakhirkan sistem saya dari Mint 12 ke Mint 15. Saya telah mengarsipkan / var / lib / mysql dan meletakkannya kembali di tempat setelah peningkatan. Saya menjalankan yang pertama mysqlcheckdari komentar user16081, dan mengeluh tentang mysql.sock.

Saya mulai menggunakan mysqld /usr/sbin/mysqld &dan mysql_upgradeberjalan dengan baik.

— Marty Vance
sumber
Itu metode yang cukup menakutkan untuk meningkatkan MySQL, tetapi saya senang itu berhasil untuk Anda.
— Aaron Copley
@ aaron-copley: sebenarnya itu tidak sepenuhnya berfungsi. MySQL 5.5.32 sebagian mengabaikan banyak tabel InnoDB saya; mereka muncul SHOW TABLES, tetapi sebaliknya tidak ada. Saat ini saya mencoba untuk mendapatkan mysql-utilities agar berfungsi, tetapi itu mengeluhkan modul python yang hilang.
— Marty Vance
0

Saya menemukan masalah yang sama.
Saya menyelesaikannya dengan memasukkan -S /path/to/mysql.sock

Dalam kasus khusus saya, output dari mysql_upgrade adalah:
Mencari 'mysql' sebagai: mysql
Mencari 'mysqlcheck' sebagai: mysqlcheck
KESALAHAN FATAL: Upgrade gagal

Itu sangat tidak berguna. --verbose tidak membuat perbedaan.

Menghubungkan sekitar saya menetap pada perintah berikut dan itu bekerja seperti pesona:
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Semoga ini bisa membantu.

— bfieber
sumber
0

Saya menghadapi masalah ini, dan saya menemukan bahwa,

  1. diperlukan Layanan MySQL untuk dapat berjalan

  2. diperlukan nama pengguna dan kata sandi

— Sruit A.Suk
sumber
0

Saya mengalami masalah yang sama.

Saya memecahkan ini dengan menginstal database baru mysql_install_db --user=mysqlseperti yang dijelaskan dalam komentar rc.mysqlfile saya di / etc.

Kemudian saya dapat memulai daemon mysql dan menggunakan 'mysql' atau apa pun yang Anda inginkan terhubung dengan paket mysql.

Saya punya masalah ini di lengan slackware, tetapi anggap tidak masalah dalam kasus ini.

— pengguna323106
sumber
0

Dalam kasus saya, saya memiliki beberapa versi mysqld berjalan secara lokal yang membuat mysql_upgrade gagal dengan Kesalahan: Gagal saat mengambil versi Server! Mungkin karena akses yang tidak sah. ps aux | grep mysqldan pastikan mysqld semuanya dimatikan. Kemudian buat hapus semua versi, instal ulang versi yang benar. Dan setelah itu mysql_upgrade mulai berfungsi.

— Laurens Bronwasser
sumber
-1

mencoba 

mysql_upgrade --verbose

atau bahkan mungkin (atau keduanya)

--debug-check --debug-info
— alexus
sumber
Sudah mencoba itu, tidak ada informasi yang benar-benar berguna, kurasa |
— Jim Rubenstein
memulai kembali dan menempel beberapa info log kesalahan \; tidak yakin mengapa itu akan terus berulang melalui kesalahan yang sama berulang-ulang.
— Jim Rubenstein
Sepertinya Anda memiliki kesalahan di sana - 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existsaya pikir itulah yang menyebabkan semuanya gagal.
— alexus
tetapi sebelum itu, coba mysql_upgrade --version dan berikan output untuk itu.
— alexus
mysql_upgrade --versiontidak menghasilkan keluaran versi (hanya kesalahan KESALAHAN FATAL). mysql --versionadalah mysql Ver 14.14 Distrib 5.5.32, untuk debian-linux-gnu (x86_64) menggunakan readline 6.2, dan versi mysqld 5.5
— Jim Rubenstein
-3

Pengguna root untuk MySQL bernama "admin", bukan root. Perintah yang benar adalah

mysql_upgrade -uadmin -p
— Marco Marsala
sumber
Ini benar-benar salah. Pengguna root di MySQL adalah root.
— dr01
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.