`mysql_upgrade` ล้มเหลวโดยไม่มีเหตุผลที่แท้จริง

ฉันกำลังอัพเกรดจาก MySQL 5.1 เป็น 5.5 ให้เรียกใช้mysql_upgradeและรับผลลัพธ์นี้:

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

ความคิดใด ๆ ในการที่จะมองหาสิ่งที่เกิดขึ้น (หรือไม่ได้เกิดขึ้น?) ดังนั้นฉันสามารถแก้ไขสิ่งที่ไม่ถูกต้องและทำงานจริงmysql_upgrade?

ขอบคุณ!

ผลผลิตเพิ่มเติม:

# 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

หลังจากปิดเครื่องmysqld --skip-grant-tablesผ่านmysqladmin shutdownและเริ่ม mysql ใหม่service mysql startอีกครั้งบันทึกข้อผิดพลาดจะวนซ้ำผ่านชุดข้อผิดพลาดนี้ซ้ำแล้วซ้ำอีก:

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 ระหว่างเริ่มต้นผ่าน 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)

ตามที่ฉันเข้าใจแล้วโครงสร้างของตาราง / ปัญหาการมีอยู่ทั้งหมด (เนื่องจากเกี่ยวข้องกับตารางระบบ mysql) ควรได้รับการแก้ไขโดยการเรียกใช้mysql_upgrade:

ฉันคิดว่ามันต้องมีชื่อผู้ใช้และรหัสผ่าน

mysql_upgrade -u root -p

หากฉันไม่ผ่านพวกเขาฉันได้รับข้อผิดพลาดของคุณ

แก้ไข : ขอบคุณความคิดเห็นตอนนี้ฉันรู้ว่ามีเหตุผลอื่น ๆ อาจจะน้อยกว่านี้บ่อย แต่ก็ควรระวังด้วยเช่นกัน

ดังนั้นคุณจะได้รับข้อผิดพลาดเมื่อ

• คุณไม่ได้ส่งชื่อผู้ใช้และรหัสผ่าน
• คุณผ่านข้อมูลรับรองของคุณ แต่พวกเขาคิดผิด
• เซิร์ฟเวอร์ MySQL ไม่ทำงาน
• ตารางสิทธิ์ 'ถูกทำลาย (จากนั้นคุณต้องรีสตาร์ท MySQL ด้วยmysqld --skip-grant-table)
• ตาราง mysql.plugin หายไป (คุณจะเห็นข้อผิดพลาดเกี่ยวกับสิ่งนั้นเมื่อเริ่ม MySQL ซึ่งแนะนำให้เรียกใช้ ... mysql_upgrade และที่ล้มเหลวคุณอาจมีการกำหนดค่าล้าสมัยใน my.cnf)

ฉันเพิ่งพบอาการที่แม่นยำเหล่านี้เมื่ออัพเกรดจาก 5.5 เป็น 5.6 และมันกลายเป็นปัญหาการเข้าถึงบริการ

แม้ว่าไคลเอนต์ไคลเอนต์ MySQL cli สามารถเชื่อมต่อกับอินสแตนซ์ฐานข้อมูลท้องถิ่นของฉันโดยมีเพียง -u และ -p ที่จัดเตรียมไว้ฉันยังต้องระบุ -h 127.0.0.1 สำหรับ mysql_upgrade เนื่องจากพยายามเชื่อมต่อไฟล์ซ็อกเก็ตและล้มเหลวในความพยายาม

ดูเหมือนว่าเซิร์ฟเวอร์ Plesk เมื่อใช้ Plesk ไม่มีรูทสำหรับ Mysql แต่ผู้ดูแลระบบของ Mysql เรียกว่า admin ดังนั้นคำสั่งนี้ควรใช้กับ Plesk ตามที่ฉันเคยลองมาก่อน:

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

คุณสามารถลองใช้สิ่งเหล่านี้ทีละอันเพื่อดูว่ามันล้มเหลวที่ไหน:

mysql_upgrade ดำเนินการคำสั่งต่อไปนี้เพื่อตรวจสอบและซ่อมแซมตารางและอัพเกรดตารางระบบ:

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

จากhttp://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html

ปัญหาเดียวกัน! ทางออกสำหรับฉันมาจากhttp://www.freebsd.org/cgi/query-pr.cgi?pr=180624

สั้น ๆ : ข้อผิดพลาดทำให้เข้าใจผิด! รันmysql_upgrade -u root -pด้วย DB on-line และระบุรหัสผ่านรูท

คำถามนี้เป็นคำถามทั่วไปอย่างไม่น่าเชื่อและฉันขอโทษสำหรับสิ่งนั้น

ฉันไม่สามารถหาสาเหตุโดยตรงและแก้ไขปัญหาที่เกิดขึ้นได้ดังนั้นฉันจึงหันไปติดตั้ง MySQL ใหม่อีกครั้งเพื่อดูว่าจะใช้งานได้หรือไม่ กลับกลายเป็นว่าเคล็ดลับในการติดตั้งใหม่ นั่นเป็นวิธีที่อ่อนแอในการแก้ไข แต่มันเป็นตัวเลือกเดียวที่ฉันทิ้งไว้

คำตอบอื่น ๆ จำนวนมากสำหรับคำถามนี้คือปัญหาที่ฉันต้องทำงานเพื่อให้ mysql_upgrade เริ่มทำงาน แต่ไม่ว่าจะด้วยเหตุผลใด - มันล้มเหลวเนื่องจากพยายามเรียกใช้ข้อความค้นหาอัตโนมัติและฉันไม่พบเอกสารที่ ข้อความค้นหาที่ทำงานอยู่ดังนั้นฉันสามารถแก้ไขได้

คุณต้องตรวจสอบการอนุญาตไฟล์ทั้งหมดภายใต้ข้อมูล mysql ควรเป็นเจ้าของเดียวกันกับ mysql PID (mysql หรือ _mysql) บางครั้งเกิดขึ้นเนื่องจากกู้คืนข้อมูลจากไฟล์โดยไม่ได้รับอนุญาต ตัวอย่างเช่นหากข้อมูล mysql ของคุณอยู่ภายใต้ / var / lib / mysql

chown -R mysql /var/lib/mysql

DBA ของเราถอนการติดตั้ง mysql เวอร์ชั่น 5.0.95 แทนที่จะเป็นรุ่นอัพเกรดเป็น 5.5.39 การถอนการติดตั้งสำรอง/etc/my.cnfไปยัง/etc/my.cnf.rpmsaveแล้วลบออกและสิ่งนี้ทำให้ MySQL ไม่สามารถเริ่มต้นได้อย่างถูกต้อง:

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

คุณสามารถทำสิ่งใดสิ่งหนึ่งต่อไปนี้:

• เปรียบเทียบไฟล์ my.cnf ด้วยตนเองและตั้งค่าการกำหนดค่าที่เหมาะสมสำหรับ InnoDB

• คืนค่าmy.cnf.rpmsaveกลับไปเป็นต้นฉบับ (ตรวจสอบก่อนว่าคุณควรเพิ่มการตั้งค่าเริ่มต้นใหม่!)

• ใช้เครื่องมือ diff ที่ต้องการvimdiffเปรียบเทียบสิ่งmy.cnf.rpmsaveใหม่my.cnfและนำกลับมาปรับแต่งที่ทำกับ MySQL config รวมถึงการตั้งค่า InnoDB

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

ฉันได้ตัวเลือกสุดท้ายจากนั้นก็สามารถเริ่ม MySQL:

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

และตอนนี้ใช้mysql_upgradeงานได้ดีการใช้mysql_upgrade -uroot -pจึงแจ้งรหัสผ่านรูทให้ฉัน

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

หวังว่านี่จะช่วยได้!

และการใช้งานmysql_upgrade -uroot -pล้มเหลวเพราะมันต้องการ MySQL ที่จะทำงาน!

บทเรียนที่ได้เรียนรู้:

• สำรอง my.cnf ก่อนอัปเกรด ... และทำการอัปเกรดแบบแทนที่แทนที่จะถอนการติดตั้งจากนั้นติดตั้งเวอร์ชันที่ใหม่กว่า
• รับ MySQL ทำงานเพื่อให้คุณสามารถใช้ mysql_upgrade
• กำไร.

ปัญหาเดียวกันสำหรับฉัน แต่สาเหตุของปัญหาคือรูปแบบรหัสผ่านเก่า ในขณะที่ mysql สามารถบังคับให้เชื่อมต่อโดยใช้รูปแบบเก่าด้วย "skip-secure-auth", mysql_upgrade ไม่มีตัวเลือกนี้ คุณต้องอัปเดตรหัสผ่านรูทด้วยรูปแบบใหม่ก่อนจากนั้นคุณสามารถอัพเกรด mysql ของคุณได้

พบปัญหาเดียวกันในการอัปเกรดจาก 5.1 เป็น 5.5

สิ่งนี้ใช้ได้กับฉัน: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

ข้อผิดพลาดของฉันอาจเกิดจากสิทธิ์ในการเส้นทางซ็อกเก็ต แต่ไม่มีเวลาที่จะตรวจสอบว่ามันเป็นสาเหตุ

ฉันเพิ่งพบปัญหานี้เช่นกันหลังจากอัปเกรดระบบของฉันจาก Mint 12 เป็น Mint 15 ฉันได้เก็บถาวร / var / lib / mysql แล้วและนำกลับมาใช้ใหม่หลังจากอัปเกรดแล้ว ฉันวิ่งแรกmysqlcheckจากความคิดเห็นของผู้ใช้ 16081 และมันบ่นเกี่ยวกับ mysql.sock

ฉันเริ่มใช้ mysqld /usr/sbin/mysqld &และmysql_upgradeวิ่งได้ดี

ฉันเจอปัญหาเดียวกัน
ฉันแก้ไขได้โดยรวม -S /path/to/mysql.sock

ในกรณีของฉันผลลัพธ์ของ mysql_upgrade คือ:
มองหา 'mysql' เป็น: mysql
กำลังมองหา 'mysqlcheck' เป็น: mysqlcheck
ข้อผิดพลาด FATAL: การอัพเกรดล้มเหลว

นั่นไร้ประโยชน์เลยทีเดียว - verbose ทำให้ไม่แตกต่างกัน

เสียบรอบฉันตัดสินตามคำสั่งต่อไปนี้และมันทำงานเหมือนมีเสน่ห์:
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

หวังว่ามันจะช่วย

ฉันประสบปัญหานี้และฉันพบว่า

1. จำเป็นต้องใช้บริการ MySQL เพื่อให้ทำงานได้

2. จำเป็นต้องมีชื่อผู้ใช้และรหัสผ่าน

ฉันพบปัญหาเดียวกัน

ฉันแก้ไขได้โดยติดตั้งฐานข้อมูลใหม่ตามmysql_install_db --user=mysqlที่อธิบายไว้ในความคิดเห็นของrc.mysqlไฟล์ของฉันใน / etc

จากนั้นฉันก็สามารถเริ่ม mysql daemon และใช้ 'mysql' หรืออะไรก็ตามที่คุณต้องการเชื่อมต่อกับแพ็คเกจ mysql

ฉันมีปัญหานี้กับแขนสแล็กแวร์ แต่คิดว่ามันไม่สำคัญในกรณีนี้

ในกรณีของฉันฉันมี mysqld เวอร์ชันไม่กี่รันในเครื่องซึ่งทำให้ mysql_upgrade ล้มเหลวโดยมีข้อผิดพลาด: ล้มเหลวขณะดึงข้อมูลเวอร์ชันเซิร์ฟเวอร์! อาจเป็นเพราะการเข้าถึงที่ไม่ได้รับอนุญาต ps aux | grep mysqlและตรวจสอบให้แน่ใจว่า mysqld ปิดตัวลงทั้งหมดแล้ว จากนั้นชงถอนการติดตั้งทุกรุ่นติดตั้งรุ่นที่ถูกต้อง และหลังจากนั้น mysql_upgrade ก็เริ่มทำงาน

ลอง

mysql_upgrade --verbose 

หรืออาจจะ (หรือทั้งคู่)

--debug-check --debug-info

ผู้ใช้รูทสำหรับ MySQL ชื่อ "admin" ไม่ใช่รูท คำสั่งที่ถูกต้องคือ

mysql_upgrade -uadmin -p