La tabella "performance_schema.session

299

Dopo aver aggiornato MySQL a 5.7.8-rc e aver effettuato l'accesso al server ho ricevuto un errore:

Table 'performance_schema.session_variables' doesn't exist

Non riesco a trovare alcuna soluzione per questo. Puoi aiutare ?

mysql upgrade

— Taz
fonte

2

Un altro. Sembra che il tuo aggiornamento non sia riuscito. Potresti voler considerare di ripetere il processo di aggiornamento (o) reinstallare la 5.7.8-rcversione e un ripristino dal backup completo del DB.

— Rahul,

2

hai eseguito mysql_upgradeper assicurarti che siano state apportate modifiche alle tabelle principali / dbs?

— Marc B,

sì, l'ho fatto mysql_upgrade, lo provo per ultimo e lo reinstallo di nuovo. Se non funziona, eseguirò il downgrade alla versione 5.6

— Taz,

28

Ho riscontrato lo stesso problema, per risolverlo, corro mysql_upgrade -u root -p --force, quindi ho riavviato il server DB.

— robregonm,

Se il comando mysql_upgrade non funziona, la tabella mysql.performance_schema potrebbe essere danneggiata. Abbiamo avuto questo problema. Per risolvere il problema, abbiamo rimosso il server di database usando il comando: apt-get purge mariadb-client-10.1 mariadb-common mariadb-server-10.1. Ciò ha rimosso tutti i file binari, di configurazione e di dati del database. Successivamente abbiamo reinstallato il server di database e importato nuovamente i database. Successivamente il server di database è stato eseguito senza problemi

— Nadir Latif

227

Anche mysql_upgrade ha funzionato per me:

# mysql_upgrade -u root -p --force
# systemctl restart mysqld

Saluti, MSz.

— Marcin Sz
fonte

25

Ho dovuto riavviare mysqld ( mysql.server restart, poiché sto usando un'installazione homebrew su os x), quindi questo è stato utile. Altrimenti ho avuto un errore su session_variables con la struttura sbagliata.

— Geoffrey Wiseman,

Comportamento identico con Homebrew su OS X 10.10.5 (Yosemite). L'esecuzione dell'aggiornamento risolve anche un arresto anomalo in Sequel Pro 1.1 (build 4499) quando si tenta di caricare il database.

— William Turrell,

4

Native table 'performance_schema'.'session_variables' has the wrong structure

— Stephen

8

Se stai usando brew servicespuoi riavviare il tuo server con brew services restart mysql.

— Frederik Kammer,

1

Questo non funziona per me, la risposta corretta è data da viq. è necessario solo per abilitare la compatibilità dello spettacolo.

— kato2,

482

Sono stato in grado di accedere al server mysql dopo aver eseguito il comando suggerito @robregonm:

mysql_upgrade -u root -p --force

È necessario un riavvio del server MySQL.

— Mihai Caracostea
fonte

6

Funzionava bene. Grazie. Voglio sapere qual è il motivo.

— diguage

2

Sto ottenendo Access denied for user 'root'@'localhost' (using password: YES) while connecting to the MySQL serveranche se sto usando la password di root corretta. Qualsiasi aiuto?? : - /

— sixty4bit

4

@ sixty4bit prova a rimuovere -p

— Mike Mellor il

1

@NevilleNazerane Non ho familiarità con easy php, ma dovresti essere in grado di individuare dove viene installato mysql e quindi aprire un prompt cdm e cambiare la directory in quella posizione. Ora dovresti essere in grado di eseguire il comando.

— Mihai Caracostea,

4

@diguage Il motivo è che l'aggiornamento della versione di MySQL ha introdotto schemi di versione incompatibili per i metadati interni. Per me sto aggiornando MySQL 5.6 a MySQL 5.7 su un Mac usando Homebrew e la directory dei dati MySQL è rimasta invariata, quindi la nuova versione MySQL stava leggendo i vecchi metadati interni ma non so cosa fare - l'errore che abbiamo visto qui è un manifesto di tale questione. Dopo mysql_upgradee un riavvio, tutto ha funzionato. Vedi: dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html

— Devy

110

mysql -u app -p
mysql> set @@global.show_compatibility_56=ON;

secondo http://bugs.mysql.com/bug.php?id=78159 ha lavorato per me.

— VIQ
fonte

1

Ha funzionato perfettamente per me! E non ho dovuto riavviare il server mysql che sarebbe stato così ingombrante

— anu.agg

3

Mi dispiace, questa è una soluzione un po 'troppo grande: come usare un bazooka per sparare una mosca. Questo interruttore di compatibilità ha molti più effetti, potresti non desiderarli tutti.

— Tuncay Göncüoğlu,

@Tuncay Göncüoğlu quali sono alcuni di questi effetti collaterali?

— katzmopolitan,

@katzmopolitan Leggi qui: dev.mysql.com/doc/refman/5.7/en/… . Le modifiche sono principalmente legate alla gestione di INFORMATION_SCHEMA (sicurezza ecc.), Ma ce ne sono altre.

— Tuncay Göncüoğlu,

Questo ha funzionato anche per me. Il messaggio di errore che ho ricevuto è stato da mysqldump. Una volta apportata la modifica suggerita, mysqldump ha funzionato. Una volta che ho avuto il dump, ho semplicemente cambiato show_compatibility_56 in OFF.

— Bryan,

23

Dal momento che nessuna delle risposte sopra spiegano effettivamente cosa è successo, ho deciso di intervenire e portare alcuni dettagli in più su questo problema.

Sì, la soluzione è eseguire il comando di aggiornamento di MySQL, come segue:, mysql_upgrade -u root -p --forcema cosa è successo?

La causa principale di questo problema è la corruzione di performance_schema, che può essere causata da:

Corruzione organica (volumi che vanno su kaboom, bug del motore, problema del driver del kernel ecc.)
Corruzione durante la patch mysql (non è inaudito che ciò accada durante una patch mysql, specialmente per gli aggiornamenti della versione principale)
Un semplice "drop database performance_schema" causerà ovviamente questo problema e presenterà gli stessi sintomi come se fosse danneggiato

Questo problema potrebbe essere stato presente nel tuo database anche prima della patch, ma ciò che è accaduto in particolare su MySQL 5.7.8 è che il flag ha show_compatibility_56cambiato il suo valore predefinito passando ONda default a OFF. Questo flag controlla il comportamento del motore nelle query per l'impostazione e la lettura delle variabili (sessione e globale) su varie versioni di MySQL.

Poiché MySQL 5.7+ ha iniziato a leggere e archiviare queste variabili su performance_schemaanziché su information_schema, questo flag è stato introdotto come ONper le prime versioni per ridurre il raggio di esplosione di questa modifica e per far conoscere agli utenti la modifica e abituarsi.

OK, ma perché la connessione fallisce? Perché a seconda del driver che si sta utilizzando (e della sua configurazione), potrebbe finire con l'esecuzione di comandi per ogni nuova connessione avviata al database (come show variables, ad esempio). Poiché uno di questi comandi può tentare di accedere a un file danneggiato performance_schema, l'intera connessione si interrompe prima di essere avviata completamente.

Così, in sintesi, si può (è impossibile dire oggi) hanno avuto performance_schemasia mancante o danneggiato prima di patching. La patch a 5.7.8 ha quindi costretto il motore a leggere le variabili da performance_schema(anziché da information_schemadove lo stava leggendo a causa della rotazione della bandiera ON). Poiché è performance_schemastato danneggiato, le connessioni non riescono.

L'esecuzione dell'aggiornamento MySQL è l'approccio migliore, nonostante i tempi di inattività. L'attivazione del flag è un'opzione, ma viene fornita con una serie di implicazioni come già indicato su questo thread.

Entrambi dovrebbero funzionare, ma soppesare le conseguenze e conoscere le tue scelte :)

— Marcello Grechi Lins
fonte

1

Grazie. Mi chiedevo che cosa causasse questo problema prima di saltare e fare cambiamenti.

— Ken Ingram

4

Segui questi passaggi senza -p:

mysql_upgrade -u root
systemctl restart mysqld

Ho avuto lo stesso problema e funziona!

— Pranay Srivastava
fonte

Questo funziona! Solo systemctl restart mysqldnon ha funzionato.

— Ninja

quindi usasystemctl restart mysql

— BitDEVil2K16

1

Come domanda sixty4bit, se il tuo utente root mysql sembra essere configurato in modo errato, prova a installare l'estensione del configuratore dalla fonte ufficiale mysql:

https://dev.mysql.com/downloads/repo/apt/

Ti aiuterà a impostare una nuova password per l'utente root.

Assicurati di aggiornare il tuo repository (debian / ubuntu):

apt-get update

— Matteus Barbosa
fonte

0

Per il mio sistema il problema è finito con il fatto che avevo ancora installato Mysql 5.6 e quindi il mysql_upgrade.exe di quell'installazione veniva chiamato invece di quello per 5.7. Vai C:\Program Files\MySQL\MySQL Server 5.7\bined esegui.\mysql_upgrade.exe -u root

— Alan
fonte

0

Se durante l'utilizzo del mysql_upgrade -u root -p --forcecomando viene visualizzato questo errore:

Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' in the MySQL Servers datadir, errno: 13

basta aggiungere il sudoprima del comando. Ha funzionato per me e ho risolto il mio problema. Quindi è: sudo mysql_upgrade -u root -p --force:)

— Aleksandar
fonte

-2

a volte mysql_upgrade -u root -p --forcenon è abbastanza,

fare riferimento a questa domanda: la tabella "performance_schema.session_variables" non esiste

secondo esso:

apri cmd
cd [installation_path]\eds-binaries\dbserver\mysql5711x86x160420141510\bin
mysql_upgrade -u root -p --force

— Mohamed Nabli
fonte

La tabella "performance_schema.session_variables" non esiste