`mysql_upgrade` está falhando sem nenhum motivo real

Estou atualizando do MySQL 5.1 para 5.5, executando mysql_upgradee obtendo esta saída:

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

Alguma idéia de onde procurar o que está acontecendo (ou não está acontecendo?) Para que eu possa consertar o que está errado e realmente executar mysql_upgrade?

Obrigado!

Mais saída:

# 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

Depois de desligar mysqld --skip-grant-tablesvia mysqladmin shutdowne reiniciar mysql via service mysql start, o log de erro percorre esse conjunto de erros mais e mais:

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

Registro do MySQL durante a inicialização 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)

Pelo que entendi, todos os problemas de estrutura / existência da tabela (no que se refere às tabelas do sistema mysql) devem ser corrigidos executando mysql_upgrade:

Eu acho que precisa de nome de usuário e senha

mysql_upgrade -u root -p

Se eu não passar, eu recebo seu erro

Edit : graças aos comentários agora eu sei que existem outras razões, talvez menos frequentes, mas é melhor estar ciente delas também

Então você recebe esse erro quando

• você não passou nome de usuário e senha
• você passou suas credenciais, mas elas estavam erradas
• o servidor MySQL não está rodando
• as tabelas de permissões estão arruinadas (então você deve reiniciar o MySQL com mysqld --skip-grant-table)
• a tabela mysql.plugin está ausente (você verá um erro ao iniciar o MySQL, o que sugere executar ... mysql_upgrade, e isso falhará. Você provavelmente tem alguma configuração obsoleta no my.cnf)

Acabei de encontrar esses sintomas precisos ao atualizar do 5.5 para o 5.6 e acabou sendo um problema de acessibilidade de serviço.

Mesmo que o cliente cli MySQL pudesse se conectar à minha instância de banco de dados local com apenas um -u e -p fornecido, eu também precisei especificar -h 127.0.0.1 para mysql_upgrade, pois estava tentando uma conexão de arquivo de soquete e falhando miseravelmente na tentativa.

Parece um servidor Plesk, ao usar o Plesk, não existe raiz para o Mysql, mas o administrador do Mysql chamou admin, portanto esse comando deve funcionar no Plesk como eu tentei antes:

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

você pode tentar executá-los um por um para ver onde ele falha:

O mysql_upgrade executa os seguintes comandos para verificar e reparar tabelas e atualizar as tabelas do sistema:

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

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

Mesmo problema! A solução para mim veio de http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

Resumidamente: o erro é enganoso! execute mysql_upgrade -u root -pcom o banco de dados on-line e forneça a senha root.

Esta pergunta é incrivelmente genérica, e peço desculpas por isso.

Não consegui encontrar uma causa e solução diretas para o problema que estava tendo, então recorri à reinstalação do MySQL para ver se isso funcionaria. Acontece que a reinstalação fez o truque. Era uma maneira esfarrapada de consertar, mas era a única opção que me restava.

Muitas das outras respostas nesta questão são problemas que eu tive que trabalhar para que o mysql_upgrade fosse executado inicialmente, mas por qualquer motivo - ele falhou ao tentar executar algumas consultas automatizadas e não consegui encontrar a documentação na qual consultas que estavam sendo executadas para que eu pudesse corrigi-las.

Você deve verificar a permissão de todos os arquivos nos dados do mysql. Deve ser o mesmo proprietário do mysql PID (mysql ou _mysql). Às vezes, isso ocorre porque restaura os dados do arquivo sem a devida permissão. Por exemplo, se seus dados mysql estiverem em / var / lib / mysql

chown -R mysql /var/lib/mysql

Nosso DBA desinstalou o mysql versão 5.0.95 em vez de apenas atualizar para a 5.5.39. A desinstalação fez backup do /etc/my.cnfpara /etc/my.cnf.rpmsaveremovê-lo e isso impediu o MySQL de iniciar corretamente:

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

Você pode fazer o seguinte:

• Compare os arquivos my.cnf manualmente e traga as definições de configuração apropriadas para o InnoDB

• Restaure a my.cnf.rpmsaveparte de trás do original (verifique primeiro as novas configurações padrão que você deve adicionar!)

• Use uma ferramenta diff, como vimdiffpara comparar my.cnf.rpmsavecom o novo my.cnfe trazido de volta os ajustes que foram feitos na configuração do MySQL, incluindo as configurações do InnoDB.

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

Eu fiz a última opção, então foi capaz de iniciar o MySQL:

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

e agora mysql_upgradefunciona bem, usando mysql_upgrade -uroot -p-me a senha de root.

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

Espero que isto ajude!

e também usando mysql_upgrade -uroot -pfalhou porque ele precisa do MySQL para rodar!

Lições aprendidas:

• Faça backup do my.cnf antes da atualização ... E faça uma atualização no local em vez de desinstalar e instale a versão mais recente.
• Coloque o MySQL em execução para poder usar o mysql_upgrade.
• Lucro.

O mesmo problema para mim, mas a origem dos meus problemas era o formato de senha antiga. Enquanto o mysql pode ser forçado a se conectar usando o formato antigo com "skip-secure-auth", o mysql_upgrade não tem essa opção. Você precisa primeiro atualizar a senha root com o novo formato e depois atualizar seu mysql.

Teve o mesmo problema ao atualizar de 5.1 para 5.5.

Isso funcionou para mim: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Meu erro provavelmente foi causado por permissões no caminho do soquete, mas não tenho tempo para verificar se foi a causa.

Acabei de encontrar isso também depois de atualizar meu sistema do Mint 12 para o Mint 15. Eu arquivei / var / lib / mysql e o coloquei de volta no lugar após a atualização. Corri o primeiro mysqlcheckdo comentário do user16081 e ele reclamou do mysql.sock.

Comecei o mysqld usando /usr/sbin/mysqld &e mysql_upgradecorreu bem.

Encontrei o mesmo problema.
Eu o resolvi incluindo -S /path/to/mysql.sock

No meu caso em particular, a saída do mysql_upgrade foi:
Procurando por 'mysql' como: mysql
Procurando por 'mysqlcheck' como: mysqlcheck
ERRO FATAL: Falha na atualização

Isso é muito inútil. --verbose não fez diferença.

Ao ligar, resolvi o seguinte comando e funcionou como um encanto: mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Espero que ajude.

Enfrentei esse problema e descobri que,

1. exigia que o serviço MySQL estivesse em execução

2. é necessário nome de usuário e senha

Eu encontrei o mesmo problema.

Resolvi isso instalando um novo banco de dados mysql_install_db --user=mysqlconforme descrito nos comentários do meu rc.mysqlarquivo no / etc.

Então eu pude iniciar o daemon mysql e usar o 'mysql' ou o que você quiser conectado ao pacote mysql.

Eu tive esse problema no braço do slackware, mas suponha que não importe nesse caso.

No meu caso, eu tinha algumas versões do mysqld em execução localmente que fizeram o mysql_upgrade falhar com Erro: Falha ao buscar a versão do servidor! Pode ser devido a acesso não autorizado. ps aux | grep mysqle verifique se o mysqld está desligado. Em seguida, desinstale a versão completa, reinstale a versão correta. E depois disso o mysql_upgrade começou a funcionar.

experimentar

mysql_upgrade --verbose 

ou talvez até (ou ambos)

--debug-check --debug-info

O usuário root do MySQL é nomeado "admin", não root. O comando certo é

mysql_upgrade -uadmin -p