myqsl maria db Fehler

I

informant

Guest
Hallo, ich habe eine Bitte und brauche eure Hilfe. Mein Server hat 2 Partitionen, einmal System und einmal eine wo www, mysql und mail als Verzeichnis liegt, welche dann in Partition 1 gemountet werden. Nun war nach einem Restart plötzlich kein mysql mehr möglich.
Beim start kommt auch ständig
Code: 
/etc/init.d/mysql restart
[ ok ] Stopping MariaDB database server: mysqld.
[ ok ] Starting MariaDB database server: mysqld.
root@mail:~# ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
in der config steht auch 127.0.0.1 drin, ich komme auch per mysql -u root -p nicht rein, da kommt
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

es läuft keine Internetseite mehr, ich habe versucht dne mysql-server neu zu installieren, hilft aber auch nichts. Die Datenbanken im mysql ordner unter var/lib/mysql hab ich nicht gelöscht auch den innodb file ibdata1 nich, alle snoch da, aber ich bekomme es nicht zum laufen, kann mir bitte jmd. helfen? Sitze schon 2 Tage dran und studiere das netz mit Lösungen aber komme nicht weiter.

Wenn ich den Server neu starte dann geht sporadisch mal eine SQL seite auf, aber 1 Sek später schon wieder nicht mehr,,,
Brauche dringend Hilfe.

PS: Debian Stretch ist installiert!

In den logs kommt teilweise das:
Code: 
Nov  6 19:58:30 mail mysqld: 2019-11-06 19:58:30 140200385404288 [Note] InnoDB: Processed 550 .ibd/.isl files
Nov  6 19:58:43 mail /etc/init.d/mysql[3083]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Nov  6 19:58:43 mail /etc/init.d/mysql[3083]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed
Nov  6 19:58:43 mail /etc/init.d/mysql[3083]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")'
Nov  6 19:58:43 mail /etc/init.d/mysql[3083]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Nov  6 19:58:43 mail /etc/init.d/mysql[3083]:

Nov  6 19:58:44 mail mysqld: 2019-11-06 19:58:44 140200385404288 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
Nov  6 19:58:44 mail mysqld: 2019-11-06 19:58:44 140200385404288 [Note] InnoDB: Read redo log up to LSN=800298476544

Nov  6 19:58:53 mail mysqld: 2019-11-06 19:58:53 140200385404288 [ERROR] InnoDB: Table mysql/gtid_slave_pos in the InnoDB data dictionary has tablespace id 3, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary.
Nov  6 19:58:53 mail mysqld: InnoDB: Please refer to
Nov  6 19:58:53 mail mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
Nov  6 19:58:53 mail mysqld: InnoDB: for how to resolve the issue.
Nov  6 19:58:53 mail mysqld: 2019-11-06 19:58:53 140200385404288 [ERROR] InnoDB: Table mysql/innodb_index_stats in the InnoDB data dictionary has tablespace id 103450, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary.
Nov  6 19:58:53 mail mysqld: InnoDB: Please refer to
Nov  6 19:58:53 mail mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
Nov  6 19:58:53 mail mysqld: InnoDB: for how to resolve the issue.
Nov  6 19:58:53 mail mysqld: 2019-11-06 19:58:53 7f82f22b5d80  InnoDB: Error: table 'mysql/innodb_table_stats'
Nov  6 19:58:53 mail mysqld: InnoDB: in InnoDB data dictionary has tablespace id 103451,
Nov  6 19:58:53 mail mysqld: InnoDB: but a tablespace with that id does not exist. There is
Nov  6 19:58:53 mail mysqld: InnoDB: a tablespace of name mysql/innodb_table_stats and id 103453, though. Have
Nov  6 19:58:53 mail mysqld: InnoDB: you deleted or moved .ibd files?
Nov  6 19:58:53 mail mysqld: InnoDB: Please refer to
Nov  6 19:58:53 mail mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
Nov  6 19:58:53 mail mysqld: InnoDB: for how to resolve the issue.
Nov  6 19:58:53 mail mysqld: 2019-11-06 19:58:53 140200385404288 [ERROR] InnoDB: Table mysql/transaction_registry in the InnoDB data dictionary has tablespace id 103449, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary.
Nov  6 19:58:53 mail mysqld: InnoDB: Please refer to
Nov  6 19:58:53 mail mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
Nov  6 19:58:53 mail mysqld: InnoDB: for how to resolve the issue.
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] InnoDB: 128 rollback segment(s) are active.
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] InnoDB: Waiting for purge to start
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.44-86.0 started; log sequence number 800298476155
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140199719859968 [Note] InnoDB: Dumping buffer pool(s) not yet started
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] Plugin 'FEEDBACK' is disabled.
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] Recovering after a crash using tc.log
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] Starting crash recovery...
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] Crash recovery finished.
Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [Note] Server socket created on IP: '127.0.0.1'.

Nov  6 19:58:54 mail mysqld: 2019-11-06 19:58:54 140200385404288 [ERROR] Missing system table mysql.proxies_priv; please run mysql_upgrade to create it
Nov  6 19:58:55 mail mysqld: 2019-11-06 19:58:55 140200384976640 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos' doesn't exist
Nov  6 19:58:55 mail mysqld: 2019-11-06 19:58:55 140200385404288 [Note] /usr/sbin/mysqld: ready for connections.
Nov  6 19:58:55 mail mysqld: Version: '10.1.41-MariaDB-0+deb9u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian 9.9

MOD: Code Tags gesetzt.
 
Last edited by a moderator:
Da scheinen ein paar Datenbankfiles zu fehlen...

Was hast Du denn vor dem reboot gemacht?

Am einfachsten wäre wohl, die DB komplett neu aufzusetzen und ein Backup einzuspielen.
 
Hi, es sind ca. 120 Datenbanken, habe davon nur Teile als Backup.
Wie kann ich denn die Datenbank neu aufsetzen, du meinst ja sicher die vom System oder?

Wenn ich die Datenbanken irgendwie sichern könnte wäre es ja schon mal was... Aber bekomm nichts mehr zum laufen und weis nicht weiter :(

wenn ich in var lib mysql den ordner mysql lösche und mysql neu instlaliere geht sql zum teil aber meine Datenbanken nicht, mit meinem mysql ordner startet mysql garnicht ;(
 
Last edited by a moderator:
... damit kommt ggf. die DB wieder hoch - nur ist die danach sicherlich nicht konsistent.

Fehlende Files kann sich das Ding ja nicht ausdenken.

-> Backup einspielen.

DB's, von denen kein Backup vorhanden ist - waren wohl nicht wichtig.
 
Hallo, muss ich außer
innodb_force_recovery = 1
noch was in der conf eintragen oder sollte danach die sql starten?

PS: startet leider immer noch nicht sobald ich meinen mysql Ordner nutze :(
sehe als prozess nur mysqld_safe nach dem eintrag und es rennt wie ein ständiger dump durch die console...
sieht dnan so aus nur wie ne matrix
Code: 
...40b000-7f62a543c000 rw-p 00000000 00:00 0
7f62a543c000-7f62a5442000 rw-s 00000000 fe:10 54526037                   /var/lib/mysql/tc.log
7f62a5442000-7f62a5447000 rw-s 00000000 00:0d 38351                      /[aio] (deleted)
7f62a5447000-7f62a544c000 rw-s 00000000 00:0d 38350                      /[aio] (deleted)
7f62a544c000-7f62a5451000 rw-s 00000000 00:0d 38349                      /[aio] (deleted)
7f62a5451000-7f62a5456000 rw-s 00000000 00:0d 38348                      /[aio] (deleted)
7f62a5456000-7f62a545b000 rw-s 00000000 00:0d 38347                      /[aio] (deleted)
7f62a545b000-7f62a5460000 rw-s 00000000 00:0d 38346                      /[aio] (deleted)
7f62a5460000-7f62a5465000 rw-s 00000000 00:0d 38345                      /[aio] (deleted)
7f62a5465000-7f62a546a000 rw-s 00000000 00:0d 38344                      /[aio] (deleted)
7f62a546a000-7f62a546f000 rw-s 00000000 00:0d 38343                      /[aio] (deleted)
7f62a546f000-7f62a5477000 rw-p 00000000 00:00 0
7f62a5477000-7f62a54fb000 r-xp 00000000 fe:01 5505210                    /lib/x86_64-linux-gnu/libsystemd.so.0.17.0
7f62a54fb000-7f62a54fc000 ---p 00084000 fe:01 5505210                    /lib/x86_64-linux-gnu/libsystemd.so.0.17.0
7f62a54fc000-7f62a54ff000 r--p 00084000 fe:01 5505210                    /lib/x86_64-linux-gnu/libsystemd.so.0.17.0
7f62a54ff000-7f62a5500000 rw-p 0...
im Log komtm nun viel:
Code: 
ov  6 20:32:40 mail mysqld: InnoDB: Error: could not open single-table tablespace file ./mysql/transaction_registry.ibd
Nov  6 20:32:40 mail mysqld: InnoDB: We do not continue the crash recovery, because the table may become
Nov  6 20:32:40 mail mysqld: InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
Nov  6 20:32:40 mail mysqld: InnoDB: To fix the problem and start mysqld:
Nov  6 20:32:40 mail mysqld: InnoDB: 1) If there is a permission problem in the file and mysqld cannot
Nov  6 20:32:40 mail mysqld: InnoDB: open the file, you should modify the permissions.
Nov  6 20:32:40 mail mysqld: InnoDB: 2) If the table is not needed, or you can restore it from a backup,
Nov  6 20:32:40 mail mysqld: InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
Nov  6 20:32:40 mail mysqld: InnoDB: crash recovery and ignore that table.
Nov  6 20:32:40 mail mysqld: InnoDB: 3) If the file system or the disk is broken, and you cannot remove
Nov  6 20:32:40 mail mysqld: InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
Nov  6 20:32:40 mail mysqld: InnoDB: and force InnoDB to continue crash recovery here.
Nov  6 20:32:40 mail mysqld: 2019-11-06 20:32:40 139974287269248 [Note] InnoDB: innodb_force_recovery was set to 1. Continuing crash recovery even though we cannot access the .ibd file of this table.
Nov  6 20:32:40 mail mysqld: 2019-11-06 20:32:40 7f4e4dab9d80  InnoDB: Operating system error number 13 in a file operation.
Nov  6 20:32:40 mail mysqld: InnoDB: The error means mysqld does not have the access rights to
Nov  6 20:32:40 mail mysqld: InnoDB: the directory.
Nov  6 20:32:40 mail mysqld: InnoDB: Error: could not open single-table tablespace file ./mysql/gtid_slave_pos.ibd
Nov  6 20:32:40 mail mysqld: InnoDB: We do not continue the crash recovery, because the table may become
Nov  6 20:32:40 mail mysqld: InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
Nov  6 20:32:40 mail mysqld: InnoDB: To fix the problem and start mysqld:
Nov  6 20:32:40 mail mysqld: InnoDB: 1) If there is a permission problem in the file and mysqld cannot
Nov  6 20:32:40 mail mysqld: InnoDB: open the file, you should modify the permissions.
Nov  6 20:32:40 mail mysqld: InnoDB: 2) If the table is not needed, or you can restore it from a backup,
Nov  6 20:32:40 mail mysqld: InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
Nov  6 20:32:40 mail mysqld: InnoDB: crash recovery and ignore that table.
Nov  6 20:32:40 mail mysqld: InnoDB: 3) If the file system or the disk is broken, and you cannot remove
Nov  6 20:32:40 mail mysqld: InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
Nov  6 20:32:40 mail mysqld: InnoDB: and force InnoDB to continue crash recovery here.
Nov  6 20:32:40 mail mysqld: 2019-11-06 20:32:40 139974287269248 [Note] InnoDB: innodb_force_recovery was set to 1. Continuing crash recovery even though we cannot access the .ibd file of this table.
Nov  6 20:32:40 mail mysqld: 2019-11-06 20:32:40 139974287269248 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...

MOD: Code Tags gesetzt.
 
Last edited by a moderator:
gibt es bei debian auch eine downgrade option oder wie wäre hier die lösung? bis derzeit am verzweifeln und frage daher lieber nach da ich nicht weiter weis, nach 2 tagen ohen erfolg :(
 
Hab in der log nun einen neuen eintrag:
Code: 
Nov  6 21:07:57 mail mysqld: InnoDB: wrong number of columns in SYS_INDEXES record
Nov  6 21:07:57 mail mysqld: InnoDB: wrong number of columns in SYS_INDEXES record
Nov  6 21:07:57 mail mysqld: InnoDB: wrong number of columns in SYS_INDEXES record
Nov  6 21:07:57 mail mysqld: 2019-11-06 21:07:57 7fe0c92ef700  InnoDB: Assertion failure in thread 140603424700160 in file trx0undo.cc line 1697
Nov  6 21:07:57 mail mysqld: InnoDB: Failing assertion: mach_read_from_2(undo_page + TRX_UNDO_PAGE_HDR + TRX_UNDO_PAGE_TYPE) == TRX_UNDO_UPDATE
Nov  6 21:07:57 mail mysqld: InnoDB: We intentionally generate a memory trap.
Nov  6 21:07:57 mail mysqld: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
Nov  6 21:07:57 mail mysqld: InnoDB: If you get repeated assertion failures or crashes, even
Nov  6 21:07:57 mail mysqld: InnoDB: immediately after the mysqld startup, there may be
Nov  6 21:07:57 mail mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to
Nov  6 21:07:57 mail mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
Nov  6 21:07:57 mail mysqld: InnoDB: about forcing recovery.
Nov  6 21:07:57 mail mysqld: 191106 21:07:57 [ERROR] mysqld got signal 6 ;
Nov  6 21:07:57 mail mysqld: This could be because you hit a bug. It is also possible that this binary
Nov  6 21:07:57 mail mysqld: or one of the libraries it was linked against is corrupt, improperly built,
Nov  6 21:07:57 mail mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
Nov  6 21:07:57 mail mysqld:
Nov  6 21:07:57 mail mysqld: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Nov  6 21:07:57 mail mysqld:
Nov  6 21:07:57 mail mysqld: We will try our best to scrape up some info that will hopefully help
Nov  6 21:07:57 mail mysqld: diagnose the problem, but since we have already crashed,
Nov  6 21:07:57 mail mysqld: something is definitely wrong and this may fail.
Nov  6 21:07:57 mail mysqld:
Nov  6 21:07:57 mail mysqld: Server version: 10.1.41-MariaDB-0+deb9u1
Nov  6 21:07:57 mail mysqld: key_buffer_size=16777216
Nov  6 21:07:57 mail mysqld: read_buffer_size=131072
Nov  6 21:07:57 mail mysqld: max_used_connections=3
Nov  6 21:07:57 mail mysqld: max_threads=153
Nov  6 21:07:57 mail mysqld: thread_count=3
Nov  6 21:07:57 mail mysqld: It is possible that mysqld could use up to
Nov  6 21:07:57 mail mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352469 K  bytes of memory
Nov  6 21:07:57 mail mysqld: Hope that's ok; if not, decrease some variables in the equation.
Nov  6 21:07:57 mail mysqld:
Nov  6 21:07:57 mail mysqld: Thread pointer: 0x7fe0a868f008
Nov  6 21:07:57 mail mysqld: Attempting backtrace. You can use the following information to find out
Nov  6 21:07:57 mail mysqld: where mysqld died. If you see no messages after this, something went
Nov  6 21:07:57 mail mysqld: terribly wrong...
Nov  6 21:07:57 mail mysqld: stack_bottom = 0x7fe0c92eecb8 thread_stack 0x30000
Nov  6 21:07:57 mail mysqld: *** buffer overflow detected ***: /usr/sbin/mysqld terminated
Nov  6 21:07:57 mail mysqld: ======= Backtrace: =========
MOD: Code Tags gesetzt.
 
Last edited by a moderator:
SQL läuft nun aber man kann nur jede 2. Sekunde zugreifen, dann ist die Verbindung wieder weg... Kann mir da jmd helfen? Irgendwie muss man das doch wieder dauerhaft zum laufen bekommen...

mit innodb_force_recovery = 4 kann ich die Datenbanken zumindest scheinbar alle sichern, was muss ich dann tun damit der SQL wieder normal funktioniert? Alles löschen und dump importieren inkl. der mysql user Rechte?

Damit scheint aber alles nur read only zu sein, kann man die DBs nun alle irgendwie reparieren inkl. SQL Server?
 
Last edited by a moderator:
informant said:
kann man die DBs nun alle irgendwie reparieren inkl. SQL Server?
Click to expand...
Kommt drauf an, wie viele der DB-Daten du schon durch dein Herumexperimentieren geschreddert hast.

Je nachdem, wie wichtig dir die DB-Inhalte sind, solltest du jetzt mit deinen Experimenten aufhören und dir professionelle Hilfe suchen. Hier im Forum gibt es einen entsprechenden Bereich Suche
 
Zur Info, ich habe alle Datenbanken normal dumpen können, nun brauch ich noch Hilfe bei der Reparatur vom SQL Server das er diese wieder nromal starten kann - im Normalen Modus. Mal schauen ob sich jmd. meldet auf die Suchanfrage oder heir helfen kann..
 
Hast du noch ein Backup der Datenbank mysql als Dump? Das ist für MySQL die zentrale Datenbank, in der alle wichtige Verwaltungs-Infos drin stehe (wie User, Rechte usw.).
Ich hatte kürzlich darin nämlich auch ein paar korrupte Dateien, nachdem mein Home-Server dank USV-Defekt einfach ausgegangen ist :-(
Ich konnte mysql mit Hilte von --skip-grant-tables wieder starten (Achtung: Jeder kann mit Vollzugriff auf die Datenbank zugreifen, ohne ein Passwort eingegebn zu müssen) und habe die defekten Tabellen dann aus dem Dump wiederherstellen können - danach mysql beenden und ohne den Parameter wieder starten und hoffen dass mysql wieder hochkommt.
Ansonsten mysql Error-Log checken, welche Tabellen noch defekt sein könnten und die ebenfalls aus einem Backup wieder herstellen.
 
Hi dump leider nein, aber wenn ich mit innodb_force_recovery = 2 starte, fährt die db hoch, mit 1 nicht mehr. lt phpmyadmin udn checkmysql ist die tabelle iO. alle andernehabe ich inzwischen per dump gesichert. auch die mysql, in den logs kommt derzeit halt zb noch
Code: 
InnoDB: database modifications by the user. Shut down
InnoDB: mysqld and edit my.cnf so thatInnoDB: innodb_force_... is removed.
oder
2019-11-07 08:58:35 7f0ca9cb5700 InnoDB: Error: Tablespace for table "mysql"."innodb_table_stats" is missing.
2019-11-07 08:58:35 7f0ca9cb5700 InnoDB: Error: Fetch of persistent statistics requested for table...
Kann man da sauch beheben, denn löschen und DB Files im mysql ordner löschen und manuell neu erstellen hat nicht geklappt.

Eine Idee?

PS mit skip-grant-tables kann ich leider Mysql nicht starten!
Da kommt einiges an Meldungen zB
Code: 
[ERROR] InnoDB: Could not find a valid tablespace file for 'mysql/transaction_registry'
InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
191107  9:03:07 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.41-MariaDB-0+deb9u1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=2502
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5512690 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55afefe2cbee]
/usr/sbin/mysqld(handle_fatal_signal+0x3bd)[0x55afef96d45d]
2019-11-07  9:03:07 140554543422848 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.44-86.0 started; log sequence number 800300975539
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7fd56768a0e0]
2019-11-07  9:03:07 140553874306816 [Note] InnoDB: Dumping buffer pool(s) not yet started
2019-11-07  9:03:07 140554543422848 [Note] Plugin 'FEEDBACK' is disabled.
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fd5661f7fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fd5661f942a]
2019-11-07  9:03:07 140554543422848 [Note] Server socket created on IP: '127.0.0.1'.
2019-11-07  9:03:07 140554542995200 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos' doesn't exist
2019-11-07  9:03:07 140554543422848 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.41-MariaDB-0+deb9u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian 9.9
/usr/sbin/mysqld(+0x92c7b4)[0x55afefce67b4]
/usr/sbin/mysqld(+0x92cc34)[0x55afefce6c34]
/usr/sbin/mysqld(+0x92d917)[0x55afefce7917]
/usr/sbin/mysqld(+0x91d864)[0x55afefcd7864]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4)[0x7fd5676804a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fd5662add0f]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
191107 09:03:07 mysqld_safe Number of processes running now: 0
191107 09:03:07 mysqld_safe mysqld restarted
2019-11-07  9:03:08 140498282610048 [Note] Using unique option prefix 'key_buffer' is error-prone and can break in the future. Please use the full name 'key_buffer_size' instead.
2019-11-07  9:03:08 140498282610048 [Note] /usr/sbin/mysqld (mysqld 10.1.41-MariaDB-0+deb9u1) starting as process 17775 ...
2019-11-07  9:03:08 140498282610048 [Note] Using unique option prefix 'myisam-recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead.
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: The InnoDB memory heap is disabled
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Using Linux native AIO
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Using generic crc32 instructions
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Completed initialization of buffer pool
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Highest supported file format is Barracuda.
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: The log sequence number 800300975539 in ibdata file do not match the log sequence number 800300975549 in the ib_logfiles!
2019-11-07  9:03:08 140498282610048 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2019-11-07 09:03:08 7fc84e39fd80  InnoDB: Error: table 'mysql/gtid_slave_pos'
InnoDB: in InnoDB data dictionary has tablespace id 103454,
InnoDB: but a tablespace with that id does not exist. There is
InnoDB: a tablespace of name mysql/gtid_slave_pos and id 103458, though. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
2019-11-07 09:03:08 7fc84e39fd80  InnoDB: Error: table 'mysql/innodb_index_stats'
InnoDB: in InnoDB data dictionary has tablespace id 103450,
InnoDB: but a tablespace with that id does not exist. There is
InnoDB: a tablespace of name mysql/innodb_index_stats and id 103496, though. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
2019-11-07 09:03:08 7fc84e39fd80  InnoDB: Error: table 'mysql/innodb_table_stats'
InnoDB: in InnoDB data dictionary has tablespace id 103451,
InnoDB: but a tablespace with that id does not exist. There is
InnoDB: a tablespace of name mysql/innodb_table_stats and id 103497, though. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
2019-11-07 09:03:08 7fc84e39fd80  InnoDB: Error: table 'mysql/slave_master_info'
InnoDB: in InnoDB data dictionary has tablespace id 103475,
InnoDB: but a tablespace with that id does not exist. There is
InnoDB: a tablespace of name mysql/slave_master_info and id 103498, though. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
2019-11-07 09:03:08 7fc84e39fd80  InnoDB: Error: table 'mysql/slave_relay_log_info'
InnoDB: in InnoDB data dictionary has tablespace id 103476,

2019-11-07  9:46:52 140632589813504 [ERROR] InnoDB: Trying to do i/o to a tablespace which exists without .ibd data file. i/o type 10, space id 103451, page no 0, i/o length 16384 bytes
2019-11-07  9:46:52 140632589813504 [ERROR] InnoDB: Trying to access tablespace [space=103451: page=0] but the tablespace does not exist or is just being dropped.
2019-11-07  9:46:52 140632589813504 [ERROR] InnoDB: tablespace id is 103451 in the data dictionary but in file ./mysql/innodb_table_stats.ibd it is 103497!
usw.

MOD: Code Tags gesetzt.
 
Last edited by a moderator:
MariaDB komplett deinstallieren, alles unter /var/lib/mysql löschen, dann MariaDB wieder installieren. Dabei wird die Datenbank mysql sauber neu erstellt. Dann die Datenbanken und User neu anlegen und die Dumps der Datenbanken zurückkippen. Ob du evtl. die User und Grant-Tabellen auch aus deinem letzten Dump importieren kannst, liegt daran, ob genau diese Tabellen zum Zeitpunkt des Dumps noch OK waren.
 
Hallo, sprich wenn mysql.user und mysql.db korrekt sind solle es funktionieren, wenn ich sql uninstall mach, mysql folder lösche, mysql neu installieren, dumps einlese und dann die 2 tabellen mysql.user udn mysql.db manuell einspiele?
 
Hi scheint zu klappen,,,, dazu eine Frageich habe mehrere DBs als zip Dump, kann ich die irgendwie alle auf einmal importieren per console? also alles was im zip file an db dumps ist?
 
You must log in or register to reply here.
Back
Top