`mysql_upgrade 'verilen hiçbir gerçek sebep olmadan başarısız oluyor


70

mysql_upgradeBu çıktıyı alıp çalıştırarak MySQL 5.1'den 5.5'e yükseltme yapıyorum :

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

Neyin olup bittiğini (ya da olmasın?) Nerede arayacağınıza dair herhangi bir fikrim var, bu yüzden neyin yanlış olduğunu ve gerçekte çalışanı düzeltebilirim mysql_upgrade?

Teşekkürler!

Daha fazla çıktı:

# 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

Kapatma sonra mysqld --skip-grant-tablesüzeri mysqladmin shutdownve üzeri mysql yeniden başlatmayı service mysql start, hata günlüğü defalarca hataların bu dizi aracılığıyla döngüler:

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

MySQL günlüğü üzerinden başlatma sırasında 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)

Anladığım kadarıyla tüm masa yapısı / varoluş sorunları (mysql sistem tabloları ile ilgili olarak) aşağıdakiler çalışarak düzeltilmelidir mysql_upgrade:


Ayrıca büyük olasılıkla hiçbir şey değmez mysqld, --skip-grant-tablesseçeneği ile çalışıyor . mysqlTerminal üzerinden hiçbir kimlik bilgisi olmadan bağlanabiliyorum ve syslog veya başka hiçbir yerde hata mysql_upgrade
yapmadım. Çalıştığımda

MySQL Referans El Kitabı oldukça iyi 5.1 ila 5.5 yükseltme işlemlerini düzenlemektedir. Buradaki tüm talimatları takip ettiyseniz, bahsetmeye değer. Eğer yoksa, iyi ...
Aaron Copley

Eğer mysql root kullanıcınız bir parolaya sahip değilse, mysql_upgrade -u root -p `ye` -p` yazmayın
Jeferex

Yanıtlar:


95

Kullanıcı adı ve şifreye ihtiyacı olduğunu düşünüyorum

mysql_upgrade -u root -p

Onları geçemezsem hatanı alırım

Düzenleme : şimdi yorumlar sayesinde başka nedenlerin olduğunu biliyorum, belki daha az sıklıkta ama onlardan haberdar olmak en iyisi

Yani ne zaman bu hatayı alıyorsunuz

  • kullanıcı adı ve şifreyi geçmedin
  • kimlik bilgilerinizi aldınız, ancak yanılıyorlardı
  • MySQL sunucusu çalışmıyor
  • izin tabloları mahvoldu (sonra MySQL ile yeniden başlatmalısınız mysqld --skip-grant-table)
  • mysql.plugin tablosu eksik (çalıştırmayı öneren MySQL başlatırken bununla ilgili bir hata göreceksiniz ... mysql_upgrade ve bu başarısız. Muhtemelen my.cnf dosyasında bazı eski yapılandırmalar vardır)

23
Bu tam olarak sahip olduğum problemdi - neden cehennem sadece "Doğrulanamadı" veya "Bağlantı hatası" ya da başka bir şey söyleyemedi? Çok öfkeli ...
les2

3
Beyler, şifreniz de yanlış ise aynı hatayı alıyorsunuz. haberdar olun.
Yoosaf Abdulla

3
Ve eğer sunucu çalışmıyorsa, şifreyi kabul ediyor gibi görünse de aynı hatayı alıyorsunuz.
Raman

1
sadece veritabanı tablosu veya veritabanı formatı da bozulduğunda, ya da çalışmaz, sonra daemon'a "mysqld - skip-grant-tables" ile başlamanız ve mysql_upgrade komutunu başka bir terminalde çalıştırmanız gerekir!
Henning

Bunun için +1. Başka bir neden
Excalibur

9

5.5'ten 5.6'ya yükseltirken bu kesin semptomlarla yeni tanıştım ve hizmete ulaşılabilirlik sorunu olduğu ortaya çıktı.

Cli MySQL istemcisi yerel DB örneğime yalnızca -u ve -p ile bağlanabilse de, mysql_upgrade için -h 127.0.0.1 belirtmeliyim, ayrıca bir soket dosya bağlantısı kurmaya çalışıyor ve girişimde başarısız oluyordu.


bu tam olarak benim sorunumdu çünkü mysqd'yi şu şekilde çalıştırdım: mysqld --skip-grant-tables - kullanıcı = mysql
Rodo

9

Bu bir Plesk sunucusu gibi görünüyor, Plesk'i kullanırken Mysql için kök yoktur, ancak Mysql yöneticisi admin denir, bu yüzden bu komut daha önce denediğim gibi Plesk'te çalışmalıdır:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`

Bu benim için mükemmel çalıştı
xarlymg89 4:16

5

nerede başarısız olduğunu görmek için bunları tek tek çalıştırmayı deneyebilirsiniz:

mysql_upgrade tabloları kontrol etmek ve onarmak ve sistem tablolarını yükseltmek için aşağıdaki komutları uygular:

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

dan http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html


1
Düşündüm, ama ayrıcalık tablolarını düzeltmek için fix_priv_tablesyaratılan bir senaryomysql_upgrade
Jim Rubenstein

iyi bir nokta, belki sadece ilk mysqlcheck hattını deneyin? Ve doğrudan bin klasöründen kaçmayı deneyin, fwiw,/usr/bin/mysql_upgrade
user16081-JoeT


3

Bu soru inanılmaz derecede genel ve bunun için özür dilerim.

Karşılaştığım soruna doğrudan bir neden ve çözüm bulamadım, bu yüzden işe yarayıp yaramayacağını görmek için MySQL'i tekrar kurmak için başvurdum. Çıkıyor, yeniden yükleme hile yaptı. Bunu düzeltmek için topal bir yoldu, fakat elimde kalan tek seçenek buydu.

Bu soruya verilen diğer cevapların çoğu, başlangıçta çalıştırılması için mysql_upgrade almak için üzerinde çalışmak zorunda kaldığım sorunlardan biriydi; Çalıştığını sorgular böylece onları düzeltebilirdim.


Evet, mysql'in veri
direktörü

2

MySQL veri altındaki tüm dosyaları izin kontrol etmelisiniz. Aynı mysql PID'nin sahibi olmalıdır (mysql veya _mysql). Bu bazen olur çünkü dosyadan verileri uygun izin olmadan geri yükleyin. Örneğin, mysql verileriniz / var / lib / mysql altındaysa

chown -R mysql /var/lib/mysql

2

DBA’miz sadece 5.5.39’a yükseltmek yerine mysql 5.0.95 sürümünü kaldırdı. Kaldırma yedeklenen /etc/my.cnfiçin /etc/my.cnf.rpmsaveo kaldırdığını ve bu düzgün başlatılmasını MySQL önledi:

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

Aşağıdakilerden herhangi birini yapabilirsiniz:

  • My.cnf dosyalarını manuel olarak karşılaştırın ve InnoDB için uygun yapılandırma ayarlarını getirin

  • my.cnf.rpmsaveOrijinali geri yükleyin (ilk önce eklemeniz gereken yeni ayarları kontrol edin!)

  • Bir fark aracı gibi kullanma vimdiffkarşılaştırmak my.cnf.rpmsaveiçin yeni my.cnfve InnoDB ayarları dahil, MySQL yapılandırma için yapıldığını tweaks üzerinde geri getirdi.

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

Son seçeneği yaptım, sonra MySQL'i başlatabildim:

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

ve şimdi mysql_upgradeiyi çalışıyor, mysql_upgrade -uroot -pbu yüzden onu kullanarak bana root şifresi sordu.

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

Bu yardımcı olur umarım!

ve ayrıca mysql_upgrade -uroot -pçalışıyor çünkü MySQL'in çalışıyor olması gerekiyor

Dersler öğrenildi:

  • Yükseltme işleminden önce my.cnf dosyasını yedekle ... Aslında yeni bir sürümü yüklemek yerine yerinde yükseltme yap.
  • MySQL'i çalıştırın, böylece mysql_upgrade kullanabilirsiniz.
  • Kar.

1

Benim için de aynı problem, fakat problemlerimin kaynağı eski şifre formatıydı. Mysql, "skip-secure-auth" ile eski formatı kullanarak bağlanmaya zorlanabilirken, mysql_upgrade bu seçeneğe sahip değildir. Önce root şifresini yeni formatta güncellemeniz gerekir, ardından mysql'nizi yükseltebilirsiniz.


1

Aynı problem 5.1'den 5.5'e yükselirken de yaşandı.

Bu benim için çalıştı: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Hatam muhtemelen soket yolundaki izinlerden kaynaklanıyordu, ancak sebebini doğrulamak için vakti yoktu.


DataDir'imi bir süre taşıdım, bu yüzden sokete giden yola ihtiyacım vardı
zzapper

0

Ben de sistemimi Mint 12'den Nane 15'e yükselttikten sonra bununla da karşılaştım. İlk mysqlcheckkullanıcı user0081'in yorumundan koştum ve mysql.sock hakkında şikayet etti.

MySQL kullanmaya başladım /usr/sbin/mysqld &ve iyi mysql_upgradekoştum.


Bu, MySQL'i yükseltmek için oldukça korkutucu bir yöntem, ancak bunun sizin için işe yaramasına sevindim.
Aaron Copley

@ aaron-copley: aslında tamamen işe yaramadı. MySQL 5.5.32, InnoDB tablolarımın çoğunu kısmen göz ardı ediyor; Onlar görünürler SHOW TABLES, fakat başka türlü yokturlar. Şu anda çalışmak için mysql-utilities almaya çalışıyorum, ancak bu eksik python modülleri hakkında şikayetçi.
Marty Vance

0

Ben de aynı problemle karşılaştım.
-S /path/to/mysql.sock ekleyerek çözdüm

Benim özel durumumda mysql_upgrade çıktısı şudur:
'mysql' olarak
aranıyor : mysql 'mysqlcheck' olarak aranıyor: mysqlcheck
FATAL ERROR: Yükseltme başarısız oldu

Bu oldukça işe yaramaz. --verbose fark yaratmadı.

Etrafta
takılıyorum Aşağıdaki komutu çözdüm ve bir cazibe gibi çalıştı: mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Umarım yardımcı olur.


0

Bu sorunla karşılaştım ve öğrendim,

  1. MySQL Hizmetinin çalışıyor olması gerekiyordu

  2. kullanıcı adı ve şifre gerekli


0

Ben de aynı sorunla karşılaştım.

Bunu / etc mysql_install_db --user=mysqliçindeki dosyamın yorumlarında açıklandığı şekilde yeni veritabanı yükleyerek rc.mysqlçözdüm.

Sonra mysql arka planını başlatıp 'mysql' ya da mysql paketiyle ne istersen onu kullanabildim.

Slackware kolunda bu sorunu yaşadım, ancak bu durumda önemli olmadığını varsayalım.


0

Benim durumumda yerel olarak çalışan mysqld'ün birkaç sürümü vardı ve bu hata mysql_upgrade'nin Hata ile başarısız olmasına neden oldu : Sunucu sürümü getirilirken başarısız oldu! Yetkisiz erişim nedeniyle olabilir. ps aux | grep mysqlve MySQL'in tamamen kapalı olduğundan emin olun. Daha sonra tüm sürümü kaldırın demlemek, doğru sürümü yeniden yükleyin. Ve bundan sonra mysql_upgrade çalışmaya başladı.


-1

Deneyin

mysql_upgrade --verbose 

veya belki bile (veya her ikisi de)

--debug-check --debug-info

Bunları denedim, gerçek yararlı bir bilgi yok, sanmıyorum |;
Jim Rubenstein

yeniden başlatıldı ve bazı hata günlüğü bilgileri yapıştırıldı \; neden bu aynı hataları tekrar tekrar tekrarlamaya devam edeceğinden emin değilim.
Jim Rubenstein

Sanırım orada bir hata var - 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existBence her şeyin başarısız olmasına sebep olan şey bu.
alexus,

ancak ondan önce, mysql_upgrade --version komutunu deneyin ve bunun için çıktı verin.
alexus,

mysql_upgrade --versionsürüm çıktısı üretmez (yalnızca FATAL ERROR hatası). mysql --versionreadline 6.2 kullanan debian-linux-gnu (x86_64) için mysql Ver 14.14 Distribüt 5.5.32 ve mysqld versiyonu 5.5'tir
Jim Rubenstein

-3

MySQL için root kullanıcısı root olarak değil "admin" olarak adlandırılır. Doğru komut

mysql_upgrade -uadmin -p

Bu kesinlikle yanlıştır. MySQL'deki kök kullanıcı root.
dr01
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.