[gelöst] SQL Server startet nicht

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
inetsurfer88
Beiträge: 61
Registriert: 18.06.2017 13:22:42

[gelöst] SQL Server startet nicht

Beitrag von inetsurfer88 » 11.04.2020 18:22:52

Hallo,

eins vorweg: ich habe unter anderen die Pakete "mariadb-server-10.0, python-mysqldb, sqlite3" vor einiger Zeit installiert. Bei allen Befehlen und Ausgaben steht immer MySQL. Ich denke eines von den Paketen wird die Datenbank sein. Ich kenne mich hier nicht wirklich aus und war froh das es bei der Installation nach einem Tutorial geklappt hat.

Ich habe auf einem Raspberry unter Raspbian (alle Pakete sind aktuell) einen Seafile-Cloudserver laufen. Seit gestern ist der Seahub-Dienst nicht mehr korrekt erreichbar und gibt nur Fehlermeldungen aus.
Meine bisherigen Versuche auch mit dem Seafile-Forum sind jetzt zu dem Ergebnis gekommen das die MySQL-Datenbank nicht gestartet wird.

Ich habe folgenden Befehl eingegeben:

Code: Alles auswählen

sudo service mysql stop
Danach:

Code: Alles auswählen

sudo service mysql start
Ausgabe:

Code: Alles auswählen

Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.
Der Befehl:

Code: Alles auswählen

systemctl status mysql.service
ergibt folgende Ausgabe:

Code: Alles auswählen

● mysql.service - LSB: Start and stop the mysql database server daemon
   Loaded: loaded (/etc/init.d/mysql; generated)
   Active: failed (Result: exit-code) since Sat 2020-04-11 18:10:46 CEST; 48s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3250 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)

Apr 11 18:10:15 server mysqld_safe[3437]: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Apr 11 18:10:46 server /etc/init.d/mysql[3716]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Apr 11 18:10:46 server /etc/init.d/mysql[3716]: [61B blob data]
Apr 11 18:10:46 server /etc/init.d/mysql[3716]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")'
Apr 11 18:10:46 server /etc/init.d/mysql[3716]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Apr 11 18:10:46 server /etc/init.d/mysql[3716]:
Apr 11 18:10:46 server mysql[3250]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
Apr 11 18:10:46 server systemd[1]: mysql.service: Control process exited, code=exited, status=1/FAILURE
Apr 11 18:10:46 server systemd[1]: mysql.service: Failed with result 'exit-code'.
Apr 11 18:10:46 server systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
Das Verzeichnis "/var/run/mysqld/" existiert, aber es ist leer. Es bfindet sich darin werder eine Datei noch ein Ordner.

Der Befehl:

Code: Alles auswählen

journalctl -xe
ergibt folgende Ausgabe:

Code: Alles auswählen

--
-- A start job for unit mysql.service has finished with a failure.
--
-- The job identifier is 1526 and the job result is failed.
Apr 11 18:10:46 server sudo[3222]: pam_unix(sudo:session): session closed for user root
Apr 11 18:13:34 server rngd[394]: stats: bits received from HRNG source: 120064
Apr 11 18:13:34 server rngd[394]: stats: bits sent to kernel pool: 64608
Apr 11 18:13:34 server rngd[394]: stats: entropy added to kernel pool: 64608
Apr 11 18:13:34 server rngd[394]: stats: FIPS 140-2 successes: 6
Apr 11 18:13:34 server rngd[394]: stats: FIPS 140-2 failures: 0
Apr 11 18:13:34 server rngd[394]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Apr 11 18:13:34 server rngd[394]: stats: FIPS 140-2(2001-10-10) Poker: 0
Apr 11 18:13:34 server rngd[394]: stats: FIPS 140-2(2001-10-10) Runs: 0
Apr 11 18:13:34 server rngd[394]: stats: FIPS 140-2(2001-10-10) Long run: 0
Apr 11 18:13:34 server rngd[394]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Apr 11 18:13:34 server rngd[394]: stats: HRNG source speed: (min=161.922; avg=310.724; max=518.827)Kibits/s
Apr 11 18:13:34 server rngd[394]: stats: FIPS tests speed: (min=10.874; avg=13.209; max=29.617)Mibits/s
Apr 11 18:13:34 server rngd[394]: stats: Lowest ready-buffers level: 2
Apr 11 18:13:34 server rngd[394]: stats: Entropy starvations: 0
Apr 11 18:13:34 server rngd[394]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Apr 11 18:14:27 server sudo[3726]:       pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/su
Apr 11 18:14:27 server sudo[3726]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
Apr 11 18:14:27 server su[3731]: (to root) pi on pts/0
Apr 11 18:14:27 server su[3731]: pam_unix(su:session): session opened for user root by pi(uid=0)
Apr 11 18:17:01 server CRON[3739]: pam_unix(cron:session): session opened for user root by (uid=0)
Apr 11 18:17:01 server CRON[3743]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr 11 18:17:01 server CRON[3739]: pam_unix(cron:session): session closed for user root
Apr 11 18:19:05 server su[3731]: pam_unix(su:session): session closed for user root
Apr 11 18:19:05 server sudo[3726]: pam_unix(sudo:session): session closed for user root
Da ich mich überhaupt nicht auskenne hoffe ich das mir jemand Tipps geben kann wie ich die Datenbank wieder ans Laufen bekomme.
Zuletzt geändert von inetsurfer88 am 12.04.2020 19:25:53, insgesamt 1-mal geändert.

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: SQL Server startet nicht

Beitrag von schwedenmann » 11.04.2020 19:36:46

Hallo
Nur so aus neugier:

Einen mariadb.service existiert nciht ?

schau mal per
systemctl list-units
dir die units an, da sollte mariadb.service auftauchen,aber eben inactive.

mfg
schwedenmann

inetsurfer88
Beiträge: 61
Registriert: 18.06.2017 13:22:42

Re: SQL Server startet nicht

Beitrag von inetsurfer88 » 11.04.2020 20:04:09

Hallo,

ich habe die Ausgabe "systemctl list-units " nach dem Begriff "maria" durchsuchen lassen. Kein Treffer.

In der Liste erscheint folgende Zeile:

Code: Alles auswählen

mysql.service           loaded failed failed    LSB: Start and stop the m
Das ist die einzige Zeile mit einem Fehler. Der Rest ist alles ok.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: SQL Server startet nicht

Beitrag von eggy » 11.04.2020 22:43:16

Zuerst nachsehen, ob nen entsprechender Prozess läuft: "ps aux" bzw "ps aux |grep -i sql"
Logs ansehen, sollten in /var/log/mysql/ liegen
Dann testen, ob der Dienst startet, wenn Du ihn händisch anwirfst z.B. via "mysqld"

inetsurfer88
Beiträge: 61
Registriert: 18.06.2017 13:22:42

Re: SQL Server startet nicht

Beitrag von inetsurfer88 » 12.04.2020 00:04:23

Der Befehl: "ps aux |grep -i sql"
Ergibt:

Code: Alles auswählen

pi        1437  0.0  0.0   7360   528 pts/0    S+   23:50   0:00 grep --color=auto -i sql
Das schein der Befehl selbst zu sein? Mehr ist da nicht

Die Datei "error.log" ist komplett leer

Die Datei "error.log.1.gz" enthält:

Code: Alles auswählen

^_�^H^@⚏^^@^C^C^@^@^@^@^@^@^@^@^@
Das ist kein copy&paste-Fehler, da stehen wirklich diese komische Zeichen

Der Befehl "mysqld" ergibt folgende Ausgabe:

Code: Alles auswählen

200411 23:56:42 [Note] mysqld (mysqld 10.0.28-MariaDB-2+b1) starting as process 1484 ...
Wenn ich anschließend den Befehl "ps aux" eingebe gibt es keinen Prozess mit der Nummer 1484

Dann nochmals die Logs, "error.log.1.gz"

Code: Alles auswählen

^_�^H^@^[=�^^@^C��{o�F^R��ק�^C�ks�e��$�A^N�^K��I�K�;^T��X�K�0�Uw��ʧ���^^^TE��,'�����^Tww�;K˩m^O^F�e1{x1^Z_86��g�����i*_$3?ǑǬ��w��^Wq^?^S��^]Ky^V}^R���_�V�+Ѓ+������^_�^LB����"�^^��i�E<�>��R~O��>^K��Y��^_���|,2�=Z
䨟ɰ,�"fX^U�*��
�1��fR��0�^E&#�^Y��^Y���y��m���byʹ�#�ܲ4O<�4���p䞛�Z^CAD^�3n�AuJ�B`A�?eY�$�L��x4��8%��:�����^Y�^BTy^\���k�IO�,��)�^@W�x�*.��r�`�B6y�=f%^[�       �;��YhO��2^?�9�^\z^T��g^Z��ia^R�>���3��=8^]8�e'�q8rlk�r�^]J^O�d����^_E������`���üy&���^^�!@��c3$�.^S�"�^K�o��s�3�]�F������Z�^NwP7�VM;��M_wu�ј��V�w7����d�S^]_ʱ;�m��bw9�������㞂M�ꠥKA��eie7o��b��ٛzjm��S^O�^W��E��^MW��IeI��pܖ����6vs�^\v(�ؼ� �W�5:W}ɵ�VlP=w����,�F��0]�rk^^G^]N�4w��ľ^[}gb7^F��}�S^K�^^�^]ҭGÛٵGNi�]c'�ִ�#��y}UoM[�[^L�>^Qݣ�o�fU��1ݣ�7L뚲N�ػT�Շn��/k¶�{�n�^]/�4Ү�Y��(�i�{o�^K�ꋆo3^\����;������5u{^U\��ֽ�:��rcx��.k����G���^|x���^P^DA^P^DA^P^DA^P^DA^P#|�T>�"�2�/��^M��q^V�(^V�jQ^H�^X*[�^S^X�_^M�&s�t�?      �O      _~^B�C%^S^P�q�&�����X��z^M��ZG^^^HϦ^Pù�^U�3�x^V� �^K7�\$˘�C^OѰ�1^Y^Z����<�L.n<�^?1^]3�^E��Ay�Fql:^Vv
O���^]PԂ�3�e�[ �E\��)�^T��^[�"���ޮS��    ^O8^LALN�^ZLG
�٭(N��9������P8�^N^���^H�42�{�$��vh^\�B��^G�?^H�'
��^P�^Kf^M���ힾEW_<;�^?��ލ�_���^R���g��^ZO&^S�^Z�P����^ZL�^���0�W��T�P�'^Cs��^[��5^Z��k���^Y^L^WųY7�Z,�^N^K^NB^H����~d?T$^L^D>D�^]&��0J���;\����4��b^Z�Lb�S^Wlp^G^?zO38rg�^@��^[z�_9}PL(cx^Z2y�JQ��Y^\����g�ۢ�^T� ",�E�ÂM%��5�x��Z^Q��u}�B^K����P$
Die Datei "error.log" ist weiterhin komplett leer.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: SQL Server startet nicht

Beitrag von eggy » 12.04.2020 00:36:28

gz bedeutet, dass die Datei komprimiert ist, am einfachsten nach /tmp kopieren und dort entpacken

Code: Alles auswählen

cp datei.gz /tmp/
cd /tmp
gunzip datei.gz
dann verschwindet die gz Endung und der Inhalt der Datei wird lesbar

inetsurfer88
Beiträge: 61
Registriert: 18.06.2017 13:22:42

Re: SQL Server startet nicht

Beitrag von inetsurfer88 » 12.04.2020 01:12:08

OK, auf das .gz hätte ich auch selber kommen können. Mist.

Code: Alles auswählen

200411 23:56:42 [Note] InnoDB: Using mutexes to ref count buffer pool pages
200411 23:56:42 [Note] InnoDB: The InnoDB memory heap is disabled
200411 23:56:42 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
200411 23:56:42 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
200411 23:56:42 [Note] InnoDB: Compressed tables use zlib 1.2.8
200411 23:56:42 [Note] InnoDB: Using Linux native AIO
200411 23:56:42 [Note] InnoDB: Not using CPU crc32 instructions
200411 23:56:42 [Note] InnoDB: Initializing buffer pool, size = 128.0M
200411 23:56:42 [Note] InnoDB: Completed initialization of buffer pool
200411 23:56:43 [Note] InnoDB: Highest supported file format is Barracuda.
200411 23:56:43 [Note] InnoDB: The log sequence numbers 1623589 and 1623589 in ibdata files do not match the log sequen$200411 23:56:43 [Note] InnoDB: Database was not shutdown normally!
200411 23:56:43 [Note] InnoDB: Starting crash recovery.
200411 23:56:43 [Note] InnoDB: Reading tablespace information from the .ibd files...
200411 23:56:43 [Note] InnoDB: Restoring possible half-written data pages
200411 23:56:43 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 279.
InnoDB: You may have to recover from a backup.
2020-04-11 23:56:43 b6f54210 InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex ccfab26b000001170000000000000000000000000048566f0006000000000000000000000000fffffffe0000000000000015000$InnoDB: End of page dump
2020-04-11 23:56:43 b6f54210 InnoDB: uncompressed page, stored checksum in field1 3438981739, calculated checksums for $InnoDB: Page may be a system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 279.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
2020-04-11 23:56:43 b6f54210  InnoDB: Assertion failure in thread 3069526544 in file buf0buf.cc line 4527
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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.
200411 23:56:43 [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.0.28-MariaDB-2+b1
key_buffer_size=16777216
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 = 351246 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
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
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.
addr2line: 'mysqld': No such file  
So wie ich das sehe wurde die Datenbank wohl nicht ordnungsgemäs herunter gefahren. Wol zu schnell nach dem shutdown den Stecker gezogen?????
Aber wie kann ich das Problem jetzt am einfachsten beheben. Die 3 Seafile-Datenbanken werden täglich gesichert, aber auch diese Rücksicherung scheitert mit Fehlermeldungen.

Der Befehl

Code: Alles auswählen

mysql -u<user> -p<passwort> ccnet-db < /home/seafile/datenstick/mysql_sicherung/ccnet-db.sql.2020-04-09-21-38-21
ergibt folgende Meldung:

Code: Alles auswählen

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: SQL Server startet nicht

Beitrag von eggy » 12.04.2020 06:34:00

Dass das Backup sich so nicht einspielen lässt, ist klar: die Datenbank läuft nicht. Wie soll der Client da seine Datensätze an die DB übergeben?

Am schnellsten lösbar vermutlich durch vollständiges Entfernen der entsprechenden Pakete, Neuinstallation von MariaDB und Zurückspielen des Backups.
Rausfinden welche Pakete betroffen sind : dpkg -l "*maria*" | grep "^ii"
diese via "apt-get purge mariadb-server-irgendwas mariadb-server-core-foo maria-usw" entfernen und anschließend neu installieren "apt-get install mariadb-server mariadb-client", dann Backup zurückspielen.

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: SQL Server startet nicht

Beitrag von TRex » 12.04.2020 07:53:41

Moin,

Erstmal ein paar Aufklärungen vorweg:

1. die mariadb befindet sich im Paket mariadb-server-10.0
2. die logs findest du auch im journal, du wusstest nur nicht, wie man es bedient (das war nur der Anfang).
3. die Dateien in /var/log/ könnten auch sehr viel älter sein und aus einer älteren Konfiguration stammen (zumindest siehts so aus, wenn du die Einträge aus dem journal dort nicht wiederfindest).
4. die systemd-Unit mysql.service startet jene Datenbank, weil mariadb von mysql abstammt und viele Namen übernommen/noch nicht geändert hat (@schwedenmann).

Da du in systemctl status das Ende des tatsächlichen Log siehst, sollte der Rest auch dort zu finden sein (starker Indikator @eggy, ein redhat 7.8 macht das leider noch inkonsistent). Gib doch bitte ein:

Code: Alles auswählen

journalctl -e -u mysql.service
und navigiere dann mit den Bild auf/ab Tasten. Das -e sorgt dafür, dass du direkt am Ende landest, also beim neuesten Eintrag.

Allerdings befürchte ich, dass die selbe Fehlermeldung dort nur nochmal auftaucht - vermutlich hast du den Pi einfach ausgestöpselt - das solltest du nicht tun mit ner Datenbank. Oder die SD-Karte hat nen Knacks.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

inetsurfer88
Beiträge: 61
Registriert: 18.06.2017 13:22:42

Re: SQL Server startet nicht

Beitrag von inetsurfer88 » 12.04.2020 09:25:01

Hallo,

"normalerweise" fahre ich den PI vor dem Ausschalten schon sauber herunter. Ich habe an die GPIO auch einen Taster fürs herunterfahren angebracht der über ein Python Script ein "shuddown -h now" auslöst. Ausschließen kann ich es natürlich nicht, das ich mal zu früh den Stecker gezogen habe. Ein mal mit den Gedanken woanders und schon ist es passiert.

Das wichtigste für mich wäre jetzt die Info ob es ein paar wenige Befehle gibt mit denen man das System "reparieren" kann, notfalls auch nur Übergangsweise damit es erst mal wieder läuft. Dann hätte ich Zeit mir eine vernünftige Speicherkarte zu besorgen (ich tendiere zu SanDisk Extreme PRO) und danach in Ruhe das System neu aufzusetzen. Morgen soll die Kiste erst mal wieder laufen. Wenn ich es nicht repariert bekomme müsste ich au die aktuelle Karte neu installieren. Das ist eine Karte die in einem Raspberry Set dabei war. Keine Ahnung was die für eine Qualität hat. Hersteller ist keiner aufgedruckt.

Wenn ich auf dem jetzigen System einfach die Datenbank neu installieren möchte, was müsste ich vorher alles deinstallieren?

Ich hatte damals laut Tutorial folgendes installiert:

Code: Alles auswählen

sudo apt-get install python2.7 libpython2.7 python-setuptools python-ldap python-mysqldb python-memcache python-urllib3 python-pil python-certifi python-idna python-requests mariadb-server-10.0 sqlite3
Einfach die komplette Zeile mit "purge" anstelle "install"?? Oder reichen einzelne Pakete daraus. Ich denke das ganze Python-Zeugs kann man drau lassen, oder?

Noch ein Wort zum Datenverlust bei dieser Methode:
Es handelt sich um einen Seafile-Cloudserver. Die Daten sind auf die Rechner synchronisiert, außerdem gibt es eine aktuelle Sicherung der Dateien. Ein kompletter Datenbankverlust würde nur den Verlust der Dateiversionierung des Cloudservers zur Folge haben. Diese habe ich ohnehin noch nie verwendet. Der effektive Datenverlust wäre also null. Allerdings existiert auch ein aktueller Dump der drei Seafile-Datenbanken. Also lässt sich vermutlich auch dieser Verlust vermeiden. die Rücksicherung dieser Dumps ergibt aber aktuell auch Fehler (siehe oben).

Code: Alles auswählen

journalctl -e -u mysql.service
ergibt:

Code: Alles auswählen

Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: The log sequence numbers 1623589 and 1623589 in ibdata files do not match the log sequence number 4745655 in the ib_logfiles!
-- Logs begin at Sun 2020-04-12 01:31:19 CEST, end at Sun 2020-04-12 09:07:32 CEST. --
Apr 12 01:31:36 server systemd[1]: Starting LSB: Start and stop the mysql database server daemon...
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] /usr/sbin/mysqld (mysqld 10.0.28-MariaDB-2+b1) starting as process 887 ...
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: Using mutexes to ref count buffer pool pages
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: The InnoDB memory heap is disabled
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: Compressed tables use zlib 1.2.8
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: Using Linux native AIO
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: Not using CPU crc32 instructions
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M
Apr 12 01:31:37 server mysqld[888]: 200412  1:31:37 [Note] InnoDB: Completed initialization of buffer pool
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: Highest supported file format is Barracuda.
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: The log sequence numbers 1623589 and 1623589 in ibdata files do not match the log sequence number 4745655 in the ib_logfiles!
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: Database was not shutdown normally!
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: Starting crash recovery.
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: Reading tablespace information from the .ibd files...
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: Restoring possible half-written data pages
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [Note] InnoDB: from the doublewrite buffer...
Apr 12 01:31:38 server mysqld[888]: InnoDB: Database page corruption on disk or a failed
Apr 12 01:31:38 server mysqld[888]: InnoDB: file read of page 279.
Apr 12 01:31:38 server mysqld[888]: InnoDB: You may have to recover from a backup.
Apr 12 01:31:38 server mysqld[888]: 2020-04-12 01:31:38 b6f3f210 InnoDB: Page dump in ascii and hex (16384 bytes):
Apr 12 01:31:38 server mysqld[888]:  len 16384; hex ccfab26b000001170000000000000000000000000048566f0006000000000000000000000000fffffffe0000000000000015000001cc1f24000001cc007800000000000000f31a72000001a2000001ccfffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000100000000000000000000001000088008000000000000000000002000000000000000000000000000040000000000040000400000000
Apr 12 01:31:38 server mysqld[888]: 008000000000000000000000000000000000101000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000008000000000000001000000000000000000000000000000000000000200000000020000000000000000000000000400080000002000000000000000000000000000000000000000000000000000000000000010000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000100000008000800000000000000000000000000000200000000000000000000000000000000000000000000000000000000000008000000000001000008000000000000000000000000000000180000000000000000080000000000000001000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000008000000000000000000000001000000000000000000000000000000000080000000000000000000000100000000000040000000000000004000008000000000010000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000008008000000000000000000000000008000000000000000000000100080000000000000000400004000000000000000000000000000000000000000000040000000000010000000000004000044000000000000008000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000020800000000800000000000000000000200000000000000000000000000000000004000000000000000000000000000000000000000000000008000000000000000000000000000000004000000040000000004000000020000000000000000000
Apr 12 01:31:38 server mysqld[888]: 0000000800000000000000080000000000008000200000008000000000000001000000000000000000000000000000000000000000000000000002010000000000000000000000000000000000000080000000000000a0000000004000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:                               $                                                                                           A   @                              @       @
Apr 12 01:31:38 server mysqld[888]:                  @                                                              @                                                                          @            @
Apr 12 01:31:38 server mysqld[888]:      @
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]: InnoDB: End of page dump
Apr 12 01:31:38 server mysqld[888]: 2020-04-12 01:31:38 b6f3f210 InnoDB: uncompressed page, stored checksum in field1 3438981739, calculated checksums for field1: crc32 2290587878, innodb 2717101534, none 3735928559, stored checksum in f
Apr 12 01:31:38 server mysqld[888]: InnoDB: Page may be a system page
Apr 12 01:31:38 server mysqld[888]: InnoDB: Database page corruption on disk or a failed
Apr 12 01:31:38 server mysqld[888]: InnoDB: file read of page 279.
Apr 12 01:31:38 server mysqld[888]: InnoDB: You may have to recover from a backup.
Apr 12 01:31:38 server mysqld[888]: InnoDB: It is also possible that your operating
Apr 12 01:31:38 server mysqld[888]: InnoDB: system has corrupted its own file cache
Apr 12 01:31:38 server mysqld[888]: InnoDB: and rebooting your computer removes the
Apr 12 01:31:38 server mysqld[888]: InnoDB: error.
Apr 12 01:31:38 server mysqld[888]: InnoDB: If the corrupt page is an index page
Apr 12 01:31:38 server mysqld[888]: InnoDB: you can also try to fix the corruption
Apr 12 01:31:38 server mysqld[888]: InnoDB: by dumping, dropping, and reimporting
Apr 12 01:31:38 server mysqld[888]: InnoDB: the corrupt table. You can use CHECK
Apr 12 01:31:38 server mysqld[888]: InnoDB: TABLE to scan your table for corruption.
Apr 12 01:31:38 server mysqld[888]: InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
Apr 12 01:31:38 server mysqld[888]: InnoDB: about forcing recovery.
Apr 12 01:31:38 server mysqld[888]: InnoDB: Ending processing because of a corrupt database page.
Apr 12 01:31:38 server mysqld[888]: 2020-04-12 01:31:38 b6f3f210  InnoDB: Assertion failure in thread 3069440528 in file buf0buf.cc line 4527
Apr 12 01:31:38 server mysqld[888]: InnoDB: We intentionally generate a memory trap.
Apr 12 01:31:38 server mysqld[888]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Apr 12 01:31:38 server mysqld[888]: InnoDB: If you get repeated assertion failures or crashes, even
Apr 12 01:31:38 server mysqld[888]: InnoDB: immediately after the mysqld startup, there may be
Apr 12 01:31:38 server mysqld[888]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Apr 12 01:31:38 server mysqld[888]: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
Apr 12 01:31:38 server mysqld[888]: InnoDB: about forcing recovery.
Apr 12 01:31:38 server mysqld[888]: 200412  1:31:38 [ERROR] mysqld got signal 6 ;
Apr 12 01:31:38 server mysqld[888]: This could be because you hit a bug. It is also possible that this binary
Apr 12 01:31:38 server mysqld[888]: or one of the libraries it was linked against is corrupt, improperly built,
Apr 12 01:31:38 server mysqld[888]: or misconfigured. This error can also be caused by malfunctioning hardware.
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]: We will try our best to scrape up some info that will hopefully help
Apr 12 01:31:38 server mysqld[888]: diagnose the problem, but since we have already crashed,
Apr 12 01:31:38 server mysqld[888]: something is definitely wrong and this may fail.
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]: Server version: 10.0.28-MariaDB-2+b1
Apr 12 01:31:38 server mysqld[888]: key_buffer_size=16777216
Apr 12 01:31:38 server mysqld[888]: read_buffer_size=131072
Apr 12 01:31:38 server mysqld[888]: max_used_connections=0
Apr 12 01:31:38 server mysqld[888]: max_threads=153
Apr 12 01:31:38 server mysqld[888]: thread_count=0
Apr 12 01:31:38 server mysqld[888]: It is possible that mysqld could use up to
Apr 12 01:31:38 server mysqld[888]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 351246 K  bytes of memory
Apr 12 01:31:38 server mysqld[888]: Hope that's ok; if not, decrease some variables in the equation.
Apr 12 01:31:38 server mysqld[888]:
Apr 12 01:31:38 server mysqld[888]: Thread pointer: 0x0x0
Apr 12 01:31:38 server mysqld[888]: Attempting backtrace. You can use the following information to find out
Apr 12 01:31:38 server mysqld[888]: where mysqld died. If you see no messages after this, something went
Apr 12 01:31:38 server mysqld[888]: terribly wrong...
Apr 12 01:31:38 server mysqld[888]: stack_bottom = 0x0 thread_stack 0x30000
Apr 12 01:31:38 server mysqld[888]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Apr 12 01:31:38 server mysqld[888]: information that should help you find out what is causing the crash.
Apr 12 01:31:38 server mysqld_safe[929]: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Apr 12 08:02:27 server /etc/init.d/mysql[1342]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Apr 12 08:02:27 server /etc/init.d/mysql[1342]: [61B blob data]
Apr 12 08:02:27 server /etc/init.d/mysql[1342]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")'
Apr 12 08:02:27 server /etc/init.d/mysql[1342]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Apr 12 08:02:27 server /etc/init.d/mysql[1342]:
Apr 12 08:02:27 server mysql[621]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
Apr 12 08:02:27 server systemd[1]: mysql.service: Control process exited, code=exited, status=1/FAILURE
Apr 12 08:02:27 server systemd[1]: mysql.service: Failed with result 'exit-code'.
Apr 12 08:02:27 server systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: SQL Server startet nicht

Beitrag von eggy » 12.04.2020 09:52:29

Das was kaputt ist reicht, in dem Fall mariadb-server-10.0. Bei dem von mir oben genannten hättest Du etwas mehr (client/libraries/etc) entfernt, bei der Installation wären die anderen nötigen Sachen dann als Abhängigkeiten automatisch installiert worden.

inetsurfer88
Beiträge: 61
Registriert: 18.06.2017 13:22:42

Re: SQL Server startet nicht

Beitrag von inetsurfer88 » 12.04.2020 10:14:21

@eggy

Danke das du dich nochmal gemeldet hast. Deinen Beitrag hatte ich komplett übersehen.

inetsurfer88
Beiträge: 61
Registriert: 18.06.2017 13:22:42

Re: [gelöst] SQL Server startet nicht

Beitrag von inetsurfer88 » 12.04.2020 19:35:10

Ich habe mariadb-server mit purge deinstalliert und danach wie vom System vorgeschlagen mit autoremove weitere 21 Pakete. Danach mit install alles wieder installiert.
Zunächst meldete apt-get einen Fehler beim Installieren der Datenbank. Es waren noch Reste der alten Installation unter /var/lib/mysql/

Also nochmals alles deinstalliert, das Verzeichnis mit rm -r gelöscht und wieder alles Installiert. Dieses mal hat es funktioniert.

Danach habe ich Seafile entfernt und neu installiert. Vor der Seafile-Installation habe ich das Datenverzeichnis umbenannt. Nach der Installation habe ich das neu erstellte Datenverzeichnis gelöscht und das alte wieder zurückbenannt. Dann die 3 Datenbanksicherungen eingespielt und Seafile gestartet.

Funktioniert Top!

Da nicht so ganz klar ist was die Ursache war werde ich mir bei nächster Gelegenheit eine vernünftige mikroSD-Karte besorgen und wenn ich mal Zeit und Lust habe das System in aller Ruhe neu Aufsetzen.

Danke für die Hilfe!
Zuletzt geändert von hikaru am 07.04.2022 21:34:58, insgesamt 1-mal geändert.
Grund: Anschlussdiskussion 2022 abgetrennt: https://debianforum.de/forum/viewtopic.php?p=1299513

Antworten