MySQL performance_schema ERROR

2. Hit bei google:

https://dev.mysql.com/doc/refm…from-previous-series.html

Zitat von blueman

Ich hab in YAST nachgeschaut und sehe dass da bereits MySQL Version 5.5 drauf ist.
Also, warum dass sich das System jetzt aufregt weiss ich nicht...

War das nicht ein Upgrade einer openSUSE?

Aus obigem Link:

Zitat

Incompatible change: As of MySQL 5.5.7, the server requires that a new grant table, proxies_priv, be present in the mysql database. If you are upgrading to 5.5.7 from a previous MySQL release rather than performing a new installation, the server will find that this table is missing and exit during startup with the following message:

Table 'mysql.proxies_priv' doesn't exist

To create the proxies_priv table, start the server with the --skip-grant-tables option to cause it to skip the normal grant table checks, then run mysql_upgrade. For example:

shell> mysqld --skip-grant-tables &
shell> mysql_upgrade

Then stop the server and restart it normally.

You can specify other options on the mysqld command line if necessary. Alternatively, if your installation is configured so that the server normally reads options from an option file, use the --defaults-file option to specify the file (enter each command on a single line):

shell> mysqld --defaults-file=/usr/local/mysql/etc/my.cnf
--skip-grant-tables &
shell> mysql_upgrade

With the --skip-grant-tables option, the server does no password or privilege checking, so any client can connect and effectively have all privileges. For additional security, use the --skip-networking option as well to prevent remote clients from connecting.
Note

This problem is fixed in MySQL 5.5.8; the server treats a missing proxies_priv table as equivalent to an empty table. However, after starting the server, you should still run mysql_upgrade to create the table.

Alles anzeigen

Weil es eine Grundfunktion JEDES Datenbanksystems ist, dass es in den eigentlichen Datenbanken bestimmte Prozeduren und eigene Verwaltungsdaten speichert. Es gibt dort also AUCH IMMER Systemtabellen.
Bei einer neuen Version können sich die Datenstrukturen ändern.
Und deshalb muss man diese Systemtabellen bei manchem Update des Datenbankprogramms halt auch anpassen/neu machen /migrieren.

Also bei relationalen Datenbanken.
(Es gibt noch viele andere)

Zitat von blueman

War's das dann schon - oder kommt noch eine Überraschung?

Das musst Du selbst herausfinden.........

Es ist schlicht Standard, dass ein Befehl Optionen kennt.
Schon immer und überall.

Das findet in der Shell statt.
befehl -s --short-option-long --long-option -- arg1 arg2
Kurze Optionen haben einen Bindestrich. Sie bestehen aus einem Buchstaben.
-asd sind demnach zusammengefasste drei Short-Options a, s, und d
--long-options sind etwas moderner und haben als Kennzeichen zwei Bindestriche.
a -- z zwei Bindestriche mit Leerzeichen drumrum beenden die Optionen, alles nachfolgende sind Argumente für den Befehl.
Und das ist in jeder Shell so.
Innerhalb von Befehlen manchmal auch.

& modifiziert die Ausführung eines Befehls. Damit schickt man ihn in den Hintergrund.
Die Shell wartet also nicht, bis dieser Befehl ausgeführt und beendet ist, sondern startet dafür eine Subshell im Hintergrund, wo er dann in Ruhe arbeitet.
Die Shell kehrt sofort zurück und führt den nächsten Befehl aus.

In deinem Fall wird also der MySQL Server gestartet und in den Hintergrund geschickt
Dann -jetzt bei im Hintergrund laufenden Server- der Updatebefehl ausgeführt.

An solchen Befehlen etwas wegzulassen macht den Befehl kaputt. Mehr nicht.

Dein Problem bleibt gleich.
Die Systemtabellen sind in der veralteten Version.
Aber das ist dir ja klar.

Und du willst GANZ SICHER NICHT das als root ausführen.
Du willst INNERHALB des MySQL Servers root sein.
Das sind ZWEI verschiedede Roots!!