ubuntuusers.de

via DuckDuckGo

MySQL - Fehler SQLSTATE[HY000]

Status: Ungelöst | Ubuntu-Version: Ubuntu 14.04 (Trusty Tahr)
Antworten |

DaBlackSheep

Anmeldungsdatum:
17. September 2018

Beiträge: 8
Zitieren
20. Oktober 2018 00:01 (zuletzt bearbeitet: 20. Oktober 2018 00:18)

Guten Abend zusammen,

ich habe heute versucht einen Fehler zu beheben. Es handelt sich um einen Strato vServer mit Ubuntu 14.04.

Ursprünglich hatte ich dieses Problem:

1
2
3
4
5
181003  5:00:26  InnoDB: ERROR: the age of the last checkpoint is 9448470,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

Ich bin nach dieser Anleitung vorgegangen: https://dba.stackexchange.com/questions/16510/mysql-innodb-innodb-error-the-age-of-the-last-checkpoint-is-innodb-which-exc

Und zwar:

STEP 01) Change the following in /etc/my.cnf

[mysqld]
innodb_log_buffer_size          = 32M
innodb_buffer_pool_size         = 3G
innodb_log_file_size            = 768M
STEP 02) mysql -uroot -p -e"SET GLOBAL innodb_fast_shutdown = 0;"

STEP 03) service mysql stop

STEP 04) rm -f /var/lib/mysql/ib_logfile*

STEP 05) service mysql start

Beim Aufbau der Seite erhalte ich nun den Fehler:

"Fehler beim Aufbau einer Datenbankverbindung"

Versuche ich mich an Plesk anzumelden heißt es (Siehe Bild für genaueres:

Server Error
500
Zend_Db_Adapter_Exception
SQLSTATE[HY000] [2002] No such file or directory

Type	Zend_Db_Adapter_Exception
Message	SQLSTATE[HY000] [2002] No such file or directory
File	Abstract.php
Line	144

https://www.bilder-upload.eu/bild-c06cd7-1539986377.jpg.html

Unter var/log/mysql/error.log finde ich folgendes:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346701 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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x562e053b7500]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x562e0529fe65]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f0c377e5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f0c36e38c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f0c36e3c028]
/usr/sbin/mysqld(+0x59e187)[0x562e0545f187]
/usr/sbin/mysqld(+0x62c59c)[0x562e054ed59c]
/usr/sbin/mysqld(+0x62d0d3)[0x562e054ee0d3]
/usr/sbin/mysqld(+0x58c07b)[0x562e0544d07b]
/usr/sbin/mysqld(+0x55b438)[0x562e0541c438]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x562e052a1e91]
/usr/sbin/mysqld(+0x305031)[0x562e051c6031]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x92a)[0x562e051ca06a]
/usr/sbin/mysqld(+0x28cafb)[0x562e0514dafb]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x562e0515296b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f0c36e23f45]
/usr/sbin/mysqld(+0x288638)[0x562e05149638]
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.
181020  0:11:07 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated $
181020  0:11:07 [Warning] option 'innodb-additional-mem-pool-size': signed value 512000 adjusted to 524288
181020  0:11:07 [Note] Plugin 'FEDERATED' is disabled.
181020  0:11:07 InnoDB: The InnoDB memory heap is disabled
181020  0:11:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
181020  0:11:07 InnoDB: Compressed tables use zlib 1.2.8
181020  0:11:07 InnoDB: Using Linux native AIO
181020  0:11:07 InnoDB: Initializing buffer pool, size = 3.0G
181020  0:11:07 InnoDB: Completed initialization of buffer pool
181020  0:11:07 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 355424117659
181020  0:11:07  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Warning: database page corruption or a failed
InnoDB: file read of space 0 page 50655.
InnoDB: Trying to recover it from the doublewrite buffer.
InnoDB: Dump of the page:
181020  0:11:07  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 8e7e4b9a0000c5df0000c5deffffffff00000052c0edd59b45bf00000000000000000000000000021b8d8005000000001294$
InnoDB: End of page dump
181020  0:11:07  InnoDB: Page checksum 3341418796, prior-to-4.0.14-form checksum 2986911153
InnoDB: stored checksum 2390641562, prior-to-4.0.14-form stored checksum 2986911153
InnoDB: Page lsn 82 3236812187, low 4 bytes of lsn at page end 3236812187
InnoDB: Page number (if stored to page already) 50655,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Page may be an index page where index id is 528992
InnoDB: Dump of corresponding page in doublewrite buffer:
181020  0:11:07  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 912e739b0000c5df0000c5deffffffff00000052c0edc1b945bf0000000000000000000000000002097f8003000000000086$
InnoDB: End of page dump
181020  0:11:07  InnoDB: Page checksum 2911917979, prior-to-4.0.14-form checksum 3711903609
InnoDB: stored checksum 2435740571, prior-to-4.0.14-form stored checksum 3711903609
InnoDB: Page lsn 82 3236807097, low 4 bytes of lsn at page end 3236807097
InnoDB: Page number (if stored to page already) 50655,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Page may be an index page where index id is 528992
InnoDB: Also the page in the doublewrite buffer is corrupt.
InnoDB: Cannot continue operation.
InnoDB: You can try to recover the database with the my.cnf
InnoDB: option:
InnoDB: innodb_force_recovery=6
181020  0:11:07  InnoDB: Assertion failure in thread 140629990156160 in file trx0sys.c line 606
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
22:11:07 UTC - 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.
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.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346701 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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55fad9bbc500]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55fad9aa4e65]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fe6f7b38330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fe6f718bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fe6f718f028]
/usr/sbin/mysqld(+0x59e187)[0x55fad9c64187]
/usr/sbin/mysqld(+0x62c59c)[0x55fad9cf259c]
/usr/sbin/mysqld(+0x62d0d3)[0x55fad9cf30d3]
/usr/sbin/mysqld(+0x58c07b)[0x55fad9c5207b]
/usr/sbin/mysqld(+0x55b438)[0x55fad9c21438]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x55fad9aa6e91]
/usr/sbin/mysqld(+0x305031)[0x55fad99cb031]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x92a)[0x55fad99cf06a]
/usr/sbin/mysqld(+0x28cafb)[0x55fad9952afb]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x55fad995796b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fe6f7176f45]
/usr/sbin/mysqld(+0x288638)[0x55fad994e638]
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.

Könnt ihr mir da bitte weiter helfen?

DaBlackSheep

(Themenstarter)

Anmeldungsdatum:
17. September 2018

Beiträge: 8
Zitieren
20. Oktober 2018 08:04 (zuletzt bearbeitet: 20. Oktober 2018 12:51)

Guten Morgen zusammen,

nun habe ich mir die halbe Nacht um die Ohren geschlagen. Ich bin gefühlt tausend Seiten im Netz durchgegangen - aber ich habe es geschafft das mySQL Server wieder läuft:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
root@h2535220:~# service mysql start
 * Starting MySQL database server mysqld                                                                                                                                                                                              [ OK ]
 * Checking for tables which need an upgrade, are corrupt or were
not closed cleanly.
root@h2535220:~# service mysql status
 * /usr/bin/mysqladmin  Ver 8.42 Distrib 5.5.61, for debian-linux-gnu on x86_64
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Server version          5.5.61-0ubuntu0.14.04.1
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/run/mysqld/mysqld.sock
Uptime:                 50 sec

Threads: 1  Questions: 778  Slow queries: 0  Opens: 143  Flush tables: 1  Open tables: 132  Queries per second avg: 15.560

Das ist schön und gut, jetzt habe ich jedoch noch ein Problem.... Jetzt äußert sich der Fehler noch mal anders:

Server Error
500
Plesk\Exception\Database
DB query failed: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'psa.sessions' doesn't exist, query was: DESCRIBE `sessions`

Type	Plesk\Exception\Database
Message	DB query failed: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'psa.sessions' doesn't exist, query was: DESCRIBE `sessions`
File	Mysql.php
Line	53

Ich denke ausschlaggebend ist der Table psa.sessions

DaBlackSheep

(Themenstarter)

Anmeldungsdatum:
17. September 2018

Beiträge: 8
Zitieren
20. Oktober 2018 12:53

So nun konnte ich die psa.session aus einem daily.dump wiederherstellen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
gunzip mysql.daily.dump.0.gz
mv mysql.daily.dump.0 mysql.daily.dump
mysql -f -uadmin -p`cat /etc/psa/.psa.shadow` < /var/lib/psa/dumps/mysql.daily.dump

mysql -u admin -p$(cat /etc/psa/.psa.shadow)

mysql> use psa;

mysql> show databases;

mysql -f -uadmin -p`cat /etc/psa/.psa.shadow` < /var/lib/psa/dumps/mysql.daily.dump

Damit habe ich nun wieder Zugriff auf Plesk, aber beim Aufruf der Website bekomme ich weiterhin einen Datenbankfehler angezeigt. Der ist im Browser auch nicht spezifisch dargestellt.
Antworten |