InnoDB: Error: Table "mysql"."innodb_table_stats" no

Unifex

New Member
Ich erhalte folgende Fehlermeldung, beim Start des MySQL Servers:

Im Error Log steht:

Code:
Error: Table "mysql"."innodb_table_stats" not found.

Und dann weitere Folgefehler wie:

Code:
InnoDB: Error: Fetch of persistent statistics requested for table "test1"."tabelle1" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

System ist ein Debian 7 Server mit MySql 5.6.13


Kann mir jemand sagen wie ich den Fehler beheben kann?
 
Code:
mysql_update

Ich stehe etwas auf dem Schlauch. Was meinst du damit?


Was ich jetzt gemacht habe:

Ich habe den MySQL Server runter gefahren.

Dann die ibdata und die iblogfile gelöscht.

Dann den MySQL Server wieder gestartet.

Nun ist immerhin die erste Fehlermeldung weg aber einige andere noch da:

Code:
131008 16:45:08 mysqld_safe Starting mysqld daemon with databases from /opt/mysql/server-5.6/data
2013-10-08 16:45:09 0 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
2013-10-08 16:45:09 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2013-10-08 16:45:09 10867 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
2013-10-08 16:45:09 10867 [Note] Plugin 'FEDERATED' is disabled.
2013-10-08 16:45:09 10867 [Note] InnoDB: The InnoDB memory heap is disabled
2013-10-08 16:45:09 10867 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2013-10-08 16:45:09 10867 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-10-08 16:45:09 10867 [Note] InnoDB: Using Linux native AIO
2013-10-08 16:45:09 10867 [Note] InnoDB: Using CPU crc32 instructions
2013-10-08 16:45:09 10867 [Note] InnoDB: Initializing buffer pool, size = 16.0G
2013-10-08 16:45:09 10867 [Note] InnoDB: Completed initialization of buffer pool
2013-10-08 16:45:09 10867 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created!
2013-10-08 16:45:09 10867 [Note] InnoDB: Setting file ./ibdata1 size to 10240 MB
2013-10-08 16:45:09 10867 [Note] InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000 4100 4200 4300 4400 4500 4600 4700 4800 4900 5000 5100 5200 5300 5400 5500 5600 5700 5800 5900 6000 6100 6200 6300 6400 6500 6600 6700 6800 6900 7000 7100 7200 7300 7400 7500 7600 7700 7800 7900 8000 8100 8200 8300 8400 8500 8600 8700 8800 8900 9000 9100 9200 9300 9400 9500 9600 9700 9800 9900 10000 10100 10200
2013-10-08 16:45:31 10867 [Note] InnoDB: Setting log file ./ib_logfile101 size to 4096 MB
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000
2013-10-08 16:45:40 10867 [Note] InnoDB: Setting log file ./ib_logfile1 size to 4096 MB
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000
2013-10-08 16:45:50 10867 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2013-10-08 16:45:50 10867 [Warning] InnoDB: New log files created, LSN=45782
2013-10-08 16:45:50 10867 [Note] InnoDB: Doublewrite buffer not found: creating new
2013-10-08 16:45:50 10867 [Note] InnoDB: Doublewrite buffer created
2013-10-08 16:45:50 10867 [Note] InnoDB: 128 rollback segment(s) are active.
2013-10-08 16:45:50 10867 [Warning] InnoDB: Creating foreign key constraint system tables.
2013-10-08 16:45:50 10867 [Note] InnoDB: Foreign key constraint system tables created
2013-10-08 16:45:50 10867 [Note] InnoDB: Creating tablespace and datafile system tables.
2013-10-08 16:45:50 10867 [Note] InnoDB: Tablespace and datafile system tables created.
2013-10-08 16:45:50 10867 [Note] InnoDB: Waiting for purge to start
2013-10-08 16:45:50 10867 [Note] InnoDB: 5.6.13 started; log sequence number 0
2013-10-08 16:45:50 10867 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
2013-10-08 16:45:50 10867 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
2013-10-08 16:45:50 10867 [Note] Server socket created on IP: '127.0.0.1'.
2013-10-08 16:45:50 10867 [Note] Event Scheduler: Loaded 0 events
2013-10-08 16:45:50 10867 [Note] /opt/mysql/server-5.6/bin/mysqld: ready for connections.
Version: '5.6.13'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2013-10-08 16:45:55 10867 [Warning] InnoDB: Cannot open table piwik/piwik_site from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
2013-10-08 16:45:57 10867 [Warning] InnoDB: Cannot open table piwik/piwik_option from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
.....

So geht das dann fröhlich weiter mit den anderen Datenbanken.

Wenn ich dem Troubleshooting Link folge, sagt der mir, ich sollte die .frm Dateien löschen, wenn ich das richtig verstehe.

Sind die nicht so wichtig oder wie?
 
Last edited by a moderator:
`mysql_update` führt man als braver MySQL-Admin nach jedem MySQL-Versionsupdate aus, um die (internen) Tabellen(formate) auf den aktuellen Stand zu bringen. Das solltest Du also dringend nachholen, sofern Dir Deine Daten nicht scheissegal sind.

Die anderen Fehlermeldungen behebst Du gemäss Doku.
 
Hmm, hab bloß überhaupt kein Versionsupdate gemacht.


Der Ton war hier im Forum übrigens auch schon mal besser, gerade von Leuten die in Verantwortung für das Forum stehen.
 
Last edited by a moderator:
Hmm, hab bloß überhaupt kein Versionsupdate gemacht.
http://packages.debian.org/search?keywords=mysql&searchon=names&suite=stable&section=all sagt für Debian 7 ist 5.5.31 im Repository, während Du angibst 5.6.13 zu verwenden. Daraus darf ich durchaus schlussfolgern, dass Du ein Versionsupdate durchgeführt hast.

<OT>
gerade von Leuten die in Verantwortung für das Forum stehen.
Da das auf mich nicht zutrifft, kann ich insbesondere gegenüber nicht-Newbies wie Dir meinen normalen Admin-Ton anschlagen. "Unfreundlich" sieht bei mir ganz anders aus, wie Dir hier mehrere langjährige SSF-Nutzer und auch die Moderatoren aus eigener Erfahrung jederzeit bestätigen können. EOD.
</OT>
 
http://packages.debian.org/search?keywords=mysql&searchon=names&suite=stable&section=all sagt für Debian 7 ist 5.5.31 im Repository, während Du angibst 5.6.13 zu verwenden. Daraus darf ich durchaus schlussfolgern, dass Du ein Versionsupdate durchgeführt hast.


Nein, falsche Schlussfolgerung. Das ist ein Testserver der langsam mit Live Aufgaben Betreut wird.

Die 5.6.13 habe ich direkt installiert. Also sie funktioniert soweit auch gut aber nun habe ich abschließend noch mal einen Blick aufs Error Log geworfen.

Zum Fall selber:

Wenn ich die ibdata und die iblogfile lösche und dann den Server starte, funktioniert keine Datenbank mehr.

Das sagt wohl auch diese Fehlermeldung aus:

Code:
Warning] InnoDB: Cannot open table piwik/piwik_site from the internal data dictionary of InnoDB though the .frm file for the table exists.

Jetzt habe ich die alten ibdata und die iblogfile zurückgespielt- Jetzt funktionieren die Datenbanken wieder aber es kommt dann wieder zur Fehlermeldung des ersten Beitrages:

Code:
Error: Table "mysql"."innodb_table_stats" not found.

Ich frage mich erstens, warum der Fehler überhaupt auftritt, also wie das sein kann, dass offensichtlich einfach eine Tabelle fehlen kann, und zweitens, wie ich diesen Fehler beheben kann.

Ich wäre dankbar für Tipps.
 
Das Problem scheint ja zu sein, dass fünf Tabellen fehlen. Ich vermute ein Bug der MySQL Server Version.

Es fehlen:

innodb_index_stats
innodb_table_stats
slave_master_info
slave_relay_log_info
slave_worker_info


Jetzt wollte ich die Tabellen einfach von Hand anlegen und zwar so:

Code:
CREATE TABLE `innodb_index_stats` (
  `database_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `table_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `index_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `stat_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `stat_value` bigint(20) unsigned NOT NULL,
  `sample_size` bigint(20) unsigned DEFAULT NULL,
  `stat_description` varchar(1024) COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;

CREATE TABLE `innodb_table_stats` (
  `database_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `table_name` varchar(64) COLLATE utf8_bin NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `n_rows` bigint(20) unsigned NOT NULL,
  `clustered_index_size` bigint(20) unsigned NOT NULL,
  `sum_of_other_index_sizes` bigint(20) unsigned NOT NULL,
  PRIMARY KEY (`database_name`,`table_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;

CREATE TABLE `slave_master_info` (
  `Number_of_lines` int(10) unsigned NOT NULL COMMENT 'Number of lines in the file.',
  `Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'The name of the master binary log currently being read from the master.',
  `Master_log_pos` bigint(20) unsigned NOT NULL COMMENT 'The master log position of the last read event.',
  `Host` char(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT 'The host name of the master.',
  `User_name` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The user name used to connect to the master.',
  `User_password` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The password used to connect to the master.',
  `Port` int(10) unsigned NOT NULL COMMENT 'The network port used to connect to the master.',
  `Connect_retry` int(10) unsigned NOT NULL COMMENT 'The period (in seconds) that the slave will wait before trying to reconnect to the master.',
  `Enabled_ssl` tinyint(1) NOT NULL COMMENT 'Indicates whether the server supports SSL connections.',
  `Ssl_ca` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The file used for the Certificate Authority (CA) certificate.',
  `Ssl_capath` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The path to the Certificate Authority (CA) certificates.',
  `Ssl_cert` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The name of the SSL certificate file.',
  `Ssl_cipher` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The name of the cipher in use for the SSL connection.',
  `Ssl_key` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The name of the SSL key file.',
  `Ssl_verify_server_cert` tinyint(1) NOT NULL COMMENT 'Whether to verify the server certificate.',
  `Heartbeat` float NOT NULL,
  `Bind` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'Displays which interface is employed when connecting to the MySQL server',
  `Ignored_server_ids` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The number of server IDs to be ignored, followed by the actual server IDs',
  `Uuid` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The master server uuid.',
  `Retry_count` bigint(20) unsigned NOT NULL COMMENT 'Number of reconnect attempts, to the master, before giving up.',
  `Ssl_crl` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The file used for the Certificate Revocation List (CRL)',
  `Ssl_crlpath` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The path used for Certificate Revocation List (CRL) files',
  `Enabled_auto_position` tinyint(1) NOT NULL COMMENT 'Indicates whether GTIDs will be used to retrieve events from the master.',
  PRIMARY KEY (`Host`,`Port`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Master Information';

CREATE TABLE `slave_relay_log_info` (
  `Number_of_lines` int(10) unsigned NOT NULL COMMENT 'Number of lines in the file or rows in the table. Used to version table definitions.',
  `Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'The name of the current relay log file.',
  `Relay_log_pos` bigint(20) unsigned NOT NULL COMMENT 'The relay log position of the last executed event.',
  `Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'The name of the master binary log file from which the events in the relay log file were read.',
  `Master_log_pos` bigint(20) unsigned NOT NULL COMMENT 'The master log position of the last executed event.',
  `Sql_delay` int(11) NOT NULL COMMENT 'The number of seconds that the slave must lag behind the master.',
  `Number_of_workers` int(10) unsigned NOT NULL,
  `Id` int(10) unsigned NOT NULL COMMENT 'Internal Id that uniquely identifies this record.',
  PRIMARY KEY (`Id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Relay Log Information';

CREATE TABLE `slave_worker_info` (
  `Id` int(10) unsigned NOT NULL,
  `Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Relay_log_pos` bigint(20) unsigned NOT NULL,
  `Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Master_log_pos` bigint(20) unsigned NOT NULL,
  `Checkpoint_relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Checkpoint_relay_log_pos` bigint(20) unsigned NOT NULL,
  `Checkpoint_master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `Checkpoint_master_log_pos` bigint(20) unsigned NOT NULL,
  `Checkpoint_seqno` int(10) unsigned NOT NULL,
  `Checkpoint_group_size` int(10) unsigned NOT NULL,
  `Checkpoint_group_bitmap` blob NOT NULL,
  PRIMARY KEY (`Id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Worker Information';

Ergebnis:

Fehlermeldung:

#1146 - Table 'mysql.innodb_index_stats' doesn't exist

Ach hehehe. klar existiert die nicht. Darum will ich sie ja auch anlegen.

Was mache ich falsch?
 
Und wie sieht die Lösung nun aus?

Zunächst erst mal die Ursache ist ein Bug in der Version mysql 5.6.13

Somit hat also kein Serverfehler zu dem Problem beigetragen.

Erster Schritt war das umbenennen der .frm + .ibd Dateien der fehlenden Tabellen.

Zweiter Schritt. Die Aktuelle Version 5.6.14 installiert.

Danach die Tabellen per Hand angelegt (geht nun plötzlich)

SQL Server stoppen und wieder starten.

et-voilà, keine Fehlermeldungen mehr.

Danach ein "mysql_upgrade" laufen lassen (aber nur, wenn einem seine Daten nicht scheißegal sind ;) ).


Problem gelöst.

Ich hoffe das hilft anderen, die vor dem selben Problem mal stehen und mit einem sparsamen "mysql_update" als Antwort, nicht allzu viel anfangen können ;)
 
Hallo,

bei mir ist nun auch besagter Fehler aufgetreten, konnte soweit auch alles nachvollziehen und würde das gerne mit derselben Methode beheben. Es handelt sich bei dem Fehler übrigens nunmehr um einen seitens Oracle bestätigten Bug:

http://bugs.mysql.com/bug.php?id=67179

Meine Frage: kann ich die .frm und .ibd Dateien der fünf Tabellen gefahrlos löschen, sie dann mit dem SQL-Code neu anlegen und danach den Server neu starten, OHNE dass ich bei bestehenden anderen Tabellen Gefahr laufe, irgendetwas zu verlieren?

Der Hintergrund ist, dass ich leider zu spät bemerkt habe, dass es diesen Bug gibt und der MySQL-Server nun bereits im Betrieb ist (war übrigens eine komplette Neuinstallation auf einem Ubuntu 12.04 LTS Linux).

Herzlichen Dank für Eure Hilfe im Voraus.
 
Kopier dir die Dateien halt vorher an einen sicheren Ort, außerhalb des MySQL-Verzeichnisses. Backup und so :)
Wenn's kracht, kannst Sie dann ja zur Not wieder zurückschieben.
 
Kopier dir die Dateien halt vorher an einen sicheren Ort, außerhalb des MySQL-Verzeichnisses. Backup und so :)
Wenn's kracht, kannst Sie dann ja zur Not wieder zurückschieben.

Hm, geht das denn so einfach mit dem zurückschieben? Sind da dann nicht andere Dinge "out-of-sync" und kollidieren, so dass der MySQL-Server nicht mehr starten kann (der ist da ja recht empfindlich bisweilen)?

Weißt Du zufällig, wofür genau diese Tabellen

innodb_index_stats
innodb_table_stats
slave_master_info
slave_relay_log_info
slave_worker_info

da sind? Völlig kritisch scheinen sie ja nicht zu sein, sonst würde der Server nicht schon zwei Wochen laufen (mit Master-Master-Replikation übrigens).
 
Öh, wie jetzt? Initial ging es doch darum, dass der MySQL-Server gar nicht startet. Wieso läuft dein mysqld dann?
Dein zitierter Bug bezieht sich letzten Endes übrigens auf die Windows Version von MySQL ;)

Welche MySQL-Version läuft bei dir?
Läuft der MySQL-Server aktuell oder nicht?
 
Öh, wie jetzt? Initial ging es doch darum, dass der MySQL-Server gar nicht startet. Wieso läuft dein mysqld dann?

mysqld läuft, allerdings treten im Error-Log kontinuierlich neue Fehler auf der Form wie im verlinkten Bug-Thread ([ERROR] InnoDB: Could not find a valid tablespace file for 'mysql/innodb_index_stats'. See http://dev.mysql.com/doc/
refman/5.6/en/innodb-troubleshooting-datadict.html for how to resolve the issue.)

Dein zitierter Bug bezieht sich letzten Endes übrigens auf die Windows Version von MySQL ;)

Ja, ursprünglich trat das Problem bei Windows-Installationen auf, allerdings wurde er vom Nutzer Arnaud Adant auch für Linux bestätigt (weiter unten, liegt wohl am mysql_install_db-Skript).

Welche MySQL-Version läuft bei dir?
Läuft der MySQL-Server aktuell oder nicht?

Bei uns installiert ist MySQL 5.6.14, debian os, x86_64, Server läuft wie gesagt, nur die Errors treten im Log auf. Er benutzt laut Log wohl aufgrund der fehlenden Tabellen "Transient Stats" für InnoDB-Tabellen ("Using transient stats instead." die exakte Logausgabe). Weißt Du, was das bedeutet?
 
Ja, ursprünglich trat das Problem bei Windows-Installationen auf, allerdings wurde er vom Nutzer Arnaud Adant auch für Linux bestätigt (weiter unten, liegt wohl am mysql_install_db-Skript).

Ja, und wurde unter http://bugs.mysql.com/bug.php?id=68807 als eigenständiger Bug aufgeführt. Das liegt aber nur daran, dass mysql_install_db scheinbar die Konfigurationsdateien ignoriert und somit das datadir zersemmelt. Folglich startet der mysqld nicht.

Deiner startet - also erstmal nicht der Bug :)

Debian oder Ubuntu? Du schreibst nun Debian, aber meintest im ersten Posting Ubuntu 12.04 LTS. Bzgl. deines eigentlichen Problems bin ich dann über folgenden Artikel im MySQL-Forum gestolpert. Give it a try :) http://forums.mysql.com/read.php?22,578559,579749#msg-579749
 
... Deiner startet - also erstmal nicht der Bug :)

Debian oder Ubuntu? Du schreibst nun Debian, aber meintest im ersten Posting Ubuntu 12.04 LTS. Bzgl. deines eigentlichen Problems bin ich dann über folgenden Artikel im MySQL-Forum gestolpert. Give it a try :) http://forums.mysql.com/read.php?22,578559,579749#msg-579749

Ah okay, dann ist das bei mir auf jeden Fall nicht der Bug, aber zumindest das Symptom ist ähnlich.

Ist ein Ubuntu 12.04er Linux, mit den MySQL Debian Binaries installiert nach Anleitung auf der MySQL-Homepage. Klappte auch an und für sich alles einwandfrei (war auch mittlerweile meine 5. oder 6. Installation von MySQL).

Danke für den Link und die Hilfe, schaue ich mir morgen an, für heute ist jetzt erst mal Server-Admin-Feierabend! :D
 
Back
Top