`mysql_upgrade` está falhando sem nenhum motivo real

70

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:

mysql  mysql5.5 
— Jim Rubenstein
fonte
Provavelmente também não vale nada, mysqldestá funcionando, com --skip-grant-tablesopção. I pode se conectar via mysqlno terminal sem credenciais, e eu fico sem erros via syslog ou em qualquer outro lugar que eu posso pensar de olhar quando eu corromysql_upgrade
— Jim Rubenstein
O Manual de Referência do MySQL cobre muito bem a atualização para 5.5 de 5.1. Se você seguiu todas as instruções aqui, vale a pena mencionar. Se você não tem, bem ...
— Aaron Copley
Se o usuário mysql raiz não tem uma senha, não incluem `-p` em` mysql_upgrade u root -p`
— Jeferex

Respostas:

95

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)
— Riccardo Galli
fonte
23
Esse era exatamente o problema que eu tinha - por que diabos não podia simplesmente dizer "Não foi possível autenticar" ou "Erro de conexão" ou algo assim? Tão bravo ...
— les2
3
Pessoal, você receberá o mesmo erro se sua senha também estiver errada. então seja informado.
— Yoosaf Abdulla
3
E você obtém o mesmo erro se o servidor não estiver em execução, mesmo que pareça aceitar a senha.
— Raman
11
apenas quando a tabela do banco de dados ou o formato do banco de dados também está quebrado, também não funciona, então você precisa iniciar o daemon com "mysqld --skip-grant-tables" e executar mysql_upgrade em outro terminal!
— Henning
+1 para isso. Outro motivo pelo qual eu odeio o MySQL
— Excalibur
9

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.

— Aubrey Falconer
fonte
esse foi exatamente o meu problema, porque eu executo o mysqd assim: mysqld --skip-grant-tables --user = mysql
— Rodo
9

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`
— linuxman1
fonte
Isso funcionou perfeitamente para mim
— xarlymg89
5

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

— user16081-JoeT
fonte
11
Pensei sobre isso, mas fix_priv_tablesé um script que é gerado pelo mysql_upgradefim de Fixup as tabelas Privilégio
— Jim Rubenstein
bom ponto, talvez tente apenas a primeira linha do mysqlcheck? E tente executar a partir da pasta bin diretamente, fwiw,/usr/bin/mysql_upgrade
— user16081-JoeT
3

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.

— Jim Rubenstein
fonte
Sim, uma vez que dir dados de mysql foi corrompido há praticamente nada que possa fazer
— Krauser
2

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
— asofyan
fonte
2

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.
— Ronnie
fonte
1

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.

— Leandro Dardini
fonte
1

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.

— Capitão
fonte
Eu me mudei minha DataDir em algum momento, eu acho que é por isso que eu precisava o caminho para o socket
— ZZAPPER
0

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.

— Marty Vance
fonte
Esse é um método bastante assustador para atualizar o MySQL, mas estou feliz que funcionou para você.
— Aaron Copley
@ Aaron-Copley: na verdade, não funcionou completamente. O MySQL 5.5.32 está parcialmente ignorando muitas das minhas tabelas do InnoDB; eles aparecem SHOW TABLES, mas não existem. Atualmente, estou tentando fazer com que o mysql-utilities funcione, mas está reclamando da falta de módulos python.
— Marty Vance
0

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.

— bfieber
fonte
0

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

— Sruit A.Suk
fonte
0

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.

— user323106
fonte
0

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.

— Laurens Bronwasser
fonte
-1

experimentar 

mysql_upgrade --verbose

ou talvez até (ou ambos)

--debug-check --debug-info
— alexus
fonte
Tentei aqueles, nenhuma informação realmente útil, eu não acho |;
— 21413 Jim Rubenstein
reiniciou e colou algumas informações do log de erros \; não sei por que continuaria repetindo esses mesmos erros repetidamente.
— 22613 Jim Rubenstein
parece que você tem um erro lá - 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existacho que é isso que causa a falha de tudo.
— 31413 alexus
mas antes disso, tente mysql_upgrade --version e forneça saída para isso.
— 31413 alexus
mysql_upgrade --versionnão produz saída de versão (apenas o erro FATAL ERROR). mysql --versioné mysql Ver 14,14 Distrib 5.5.32, para o debian-linux-gnu (x86_64), utilizando readline 6.2, ea versão mysqld é de 5,5
— Jim Rubenstein
-3

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

mysql_upgrade -uadmin -p
— Marco Marsala
fonte
Isto está absolutamente errado. O usuário root no MySQL é root.
— #
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.