`mysql_upgrade` gagal tanpa alasan nyata

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:

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)

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.

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`

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

Masalah yang sama! Solusi untuk saya berasal dari http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

Secara singkat: kesalahannya menyesatkan! jalankan mysql_upgrade -u root -pdengan DB online dan berikan kata sandi root.

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.

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

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.

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.

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.

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.

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.

Saya menghadapi masalah ini, dan saya menemukan bahwa,

1. diperlukan Layanan MySQL untuk dapat berjalan

2. diperlukan nama pengguna dan kata sandi

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.

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.

mencoba

mysql_upgrade --verbose 

atau bahkan mungkin (atau keduanya)

--debug-check --debug-info

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

mysql_upgrade -uadmin -p