Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
23.10.2021, 16:31:39

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
Statistiken
  • Beiträge insgesamt: 759253
  • Themen insgesamt: 61003
  • Heute online: 616
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema:  mysql mariadb crash nach fsck  (Gelesen 495 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

mysql mariadb crash nach fsck
« am: 23.08.2021, 23:53:33 »
Nabend in die Runde,
ein sehr seltsames Verhalten meines Heimservers habe ich heute festgestellt, bzw eigentlich habe ich gemerkt, dass der DNS-Cache ni mehr ging und damit natürlich keine Domain mehr auflösbar. Soweit keine Fehler, nach einigem hin und her, dann eben doch mal reboot gemacht - ja ich weiß ...., aber ist heute nicht mein Tag gewesen und da hatte ich keinen Bock mehr auf große Sucherei. Jedenfalls aha, /var konnte nicht eingehangen werden und war somit nicht da. Zum Verständnis: /var läuft bei dem Ding auf nem extra-Medium - ne Art "Opferanode" für das ständige Gekritzel.
Jedenfalls mal fsck: Hm, okay... isser gleich wutig geworden mit geschätzt 100 Fehlern: "Fixing?" fragte er mich anständig, "Yo", habe ich gesagt. Was soll ich auch sonst machen. Device ging ja nicht mehr einzuhängen. Dann reboot, alles wieder hübsch, naja, außer die sql

2021-08-23 22:52:07 0 [Note] InnoDB: Using Linux native AIO
2021-08-23 22:52:07 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-08-23 22:52:07 0 [Note] InnoDB: Uses event mutexes
2021-08-23 22:52:07 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-08-23 22:52:07 0 [Note] InnoDB: Number of pools: 1
2021-08-23 22:52:07 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-08-23 22:52:07 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2021-08-23 22:52:07 0 [Note] InnoDB: Completed initialization of buffer pool
2021-08-23 22:52:07 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-08-23 22:52:07 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=7673759
2021-08-23 22:52:07 0x7f5c528d5d00  InnoDB: Assertion failure in file /build/mariadb-10.3-XTU5dn/mariadb-10.3-10.3.29/storage/innobase/include/fut0lst.ic line 85
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
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: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
210823 22:52: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.3.29-MariaDB-0+deb10u1
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467429 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 0x49000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x5570913f031e]
/usr/sbin/mysqld(handle_fatal_signal+0x54d)[0x557090f1b57d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f5c52c3b730]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f5c52a9f7bb]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7f5c52a8a535]
/usr/sbin/mysqld(+0x4e92f9)[0x557090c5d2f9]
/usr/sbin/mysqld(+0xa365f4)[0x5570911aa5f4]
/usr/sbin/mysqld(+0xa2563c)[0x55709119963c]
/usr/sbin/mysqld(+0xa2fe16)[0x5570911a3e16]
/usr/sbin/mysqld(+0x4e28e8)[0x557090c568e8]
/usr/sbin/mysqld(+0x918444)[0x55709108c444]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x68)[0x557090f1dca8]
/usr/sbin/mysqld(+0x5e1089)[0x557090d55089]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x98a)[0x557090d5620a]
/usr/sbin/mysqld(+0x521975)[0x557090c95975]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x3f9)[0x557090c9c5b9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f5c52a8c09b]
/usr/sbin/mysqld(_start+0x2a)[0x557090c8fa5a]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /mnt/microsd1/var/lib/mysql
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             7288                 7288                 processes
Max open files            32768                32768                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       7288                 7288                 signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                   
Max realtime priority     0                    0                   
Max realtime timeout      unlimited            unlimited            us       
Core pattern: core

Ähm, so mit einfach Pakete reinstallieren isses jetzt wohl nicht getan vermute ich oder wie sind da die Einschätzungen bei den vorzugsweise geneigten sql-Spezis?
Ich verstehe nicht wozu ich jetzt das debug-binary dort reinmeißeln soll? Fixen kann ich, soweit ich das verstanden habe, damit eh nix, sondern mir nur irgendwelche Bruchstücke ausgeben lassen. Macht ja aber das .log ohnehin schon. Detaillierter als ich überhaupt was damit anfangen könnte.
.......nochmal drüber nachgedacht, kann das sein, dass die db nicht zerscherbelt zu sein scheint, sondern doch "nur" das Paket und die 2 libs halt?

Re: mysql mariadb crash nach fsck
« Antwort #1 am: 24.08.2021, 18:20:28 »
Deine DB liegt auch in /var in /var/lib/mysql. M.E. ist die jetzt kaputt.
Kannst du ein Backup einspielen?
Hast du mal InnoDB Recovery versucht?

thebookkeeper

  • aka AnanasDampf
  • *****
Re: mysql mariadb crash nach fsck
« Antwort #2 am: 24.08.2021, 23:24:17 »
...
/var läuft bei dem Ding auf nem extra-Medium - ne Art "Opferanode" für das ständige Gekritzel ...
Und das findest Du toll oder lustig? Nach dem Motto: Dann mach ich mir ein Schlitz ins Kleid und find es wunderbar.

Re: mysql mariadb crash nach fsck
« Antwort #3 am: 26.08.2021, 15:11:49 »
Backup einspielen geht leider nicht. Strukturiere grad um und dort wo das backup drauf war.....
innodb_force_recovery macht er nicht bzw crasht trotzdem.
Ich schätze mal Jackpot oder?

Re: mysql mariadb crash nach fsck
« Antwort #4 am: 27.08.2021, 20:05:15 »
Ich schätze mal Jackpot oder?
Ich schätze ja.
Du kannst den Anweisungen aus der Ausgabe folgen und Bug Reports erstellen.
Wenn du meinst, defekt ist "nur" der DB Server nicht die Datendateien, kannst du natürlich - vorzugsweise auf einem anderen Rechner - einen neuen DB Server aufsetzen und die Datendateien dort rein kopieren und starten und schauen was passiert.
Ich würde mir jedenfalls mal Gedanken über das extra Medium machen. Muss das getauscht werden? Muss das neu aufgesetzt werden? Irgendeinen Grund werden die Dateisystemfehler gehabt haben.

Re: mysql mariadb crash nach fsck
« Antwort #5 am: 27.08.2021, 21:12:39 »
Das "extra-Medium" gabs halt damals (vor wirklich ewigen Jahren) zu nem Smartphone dazu, lag jahrelang nur im Schrank. Für 2GB hat ja eigentlich keiner mehr wirklich Verwendung. Daher ist die SD-Karte eigentlich so gesehen werksneu. Kaputt geschrieben sollten da keine Cluster sein. Ist mir ein Rätsel wie da nen Fehler auftauchen kann.
Wieder Erwarten habe ich doch noch eine 2 Monate alte DB, also praktisch den kompletten /var gefunden. Aber wirklich nur dummer Zufall. Das sollte dort alles i.O. sein. Problem ist hier, dass vermutlich die Daten der Cloud (Nutzdaten) nicht zur sql passen, da ich kein exakt 2 Monate altes Backup der Cloud selber habe. Ich meine, ewig viel passiert da auf dem Ding nicht und speziell die letzten 2 Monate ist meiner Erinnerung nach auch nicht irre viel passiert. Dennoch, ist es irgendwie denkbar die sql mit den Nutzdaten (leider nur aktuelle) zu verheiraten? Ich wäre auch schon zufrieden wenn nur das gröbste wieder da wäre und funktioniert.

Re: mysql mariadb crash nach fsck
« Antwort #6 am: 27.08.2021, 23:03:41 »
Deine Datenbankdateien - sogar dann ganzes /var - liegen auf einer viele Jahre alten 2GB SD-Karte!? Ich habe keine Ahnung, wie lange eine viele Jahre alte 2GB SD-Karte durchhält, finde das aber ziemlich gewagt. Einmal abgesehen davon, dass meine /var Verzeichnisse alle größer als 2 GB sind.

Deinen Zusammenhang - Cloud zu Datenbank - verstehe ich überhaupt nicht.

Wenn du ein Backup / eine Kopie von /var/lib/mysql/ hast, kannst du so vorgehen https://wiki.ubuntuusers.de/MySQL/Backup/#Datenbankdateien-auf-ein-anderes-System-zurueck-spielen