since today Nextcloud dosen’t work anymore. In syslog I found:
systemd[1]: Starting LSB: Start and stop the mysql database server daemon…
/etc/init.d/mysql[2799]: 0 processes alive and ‘/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping’ resulted in
/etc/init.d/mysql[2799]: #007/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
/etc/init.d/mysql[2799]: error: ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’
/etc/init.d/mysql[2799]: Check that mysqld is running and that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
/etc/init.d/mysql[2799]:
mysql[2060]: Starting MySQL database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
systemd[1]: mysql.service: control process exited, code=exited status=1
systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
systemd[1]: Unit mysql.service entered failed state.
I guess, that you recently updated the mysql and the configuration went wrong with a new file. I would also check the configuration file. Otherwise I would change it testwise to IP/TCP and then back again to socket if TCP is working
Another hint. journalctl -xe or systemctl
Maybe the error is there more specific
The mysqld.sock file will be created if the service get started. But your service start is failing, so no file is created. Well you hadn´t change a running system, then it is strange.
Maybe an easy reboot will fix it
180318 20:17:53 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please $
180318 20:17:53 [Note] Plugin ‘FEDERATED’ is disabled.
180318 20:17:53 InnoDB: The InnoDB memory heap is disabled
180318 20:17:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180318 20:17:53 InnoDB: Compressed tables use zlib 1.2.8
180318 20:17:53 InnoDB: Using Linux native AIO
180318 20:17:53 InnoDB: Initializing buffer pool, size = 128.0M
180318 20:17:53 InnoDB: Completed initialization of buffer pool
180318 20:17:53 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 48919897
180318 20:17:53 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: Doing recovery: scanned up to log sequence number 49164482
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 837.
InnoDB: You may have to recover from a backup.
180318 20:17:54 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 1be21b6b000003450000000000000000000000000291e93f0002000000000000000000000000000101100120ffffffff0000ffffffff000000020056000000000000021c25b200000001$
InnoDB: End of page dump
180318 20:17:54 InnoDB: Page checksum 3676414679, prior-to-4.0.14-form checksum 26149024
InnoDB: stored checksum 467802987, prior-to-4.0.14-form stored checksum 26149024
InnoDB: Page lsn 0 43116863, low 4 bytes of lsn at page end 43116863
InnoDB: Page number (if stored to page already) 837,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an insert undo log page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 837.
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
180318 20:17:54 InnoDB: Assertion failure in thread 1996333584 in file buf0buf.c line 3623
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.
19:17:54 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 = 346093 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
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.
mysqlcheck --check database
mysqlcheck: Got error: 2002: Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2) when trying to connect
I had no chance to repair my system. I think the SD-card is damaged.
I used a backup from a couple of weeks ago to recover to a second card. But I lost a few of files.
All datas of MySQL are stored on the SD-card (my.cnf).
My files in Nextcloud are stored at a USB-stick (/home/pi/nextcloud). I like to change MySQL-configuration so that the database and every file of MySQL in the future will be stored at the USB-stick, as well.
Would it work, if I change “datadir= /var/lib/mysql” to “datadir= /home/pi/nextcloud/mysql”?
I could reconstruct the problem with my database. It always will be destroyed when I pull out the power cable. I pulled it out because I want to make a backup of the SD-card with PC.
Any ideas how I could prevent destroying the database in case of power failure?
Are you using a raspberry pi or something like that? SD-Cards get often broken there. Try with another one.
Why are you using the flag -f? Usually the -f flag is used to force commands. In this case it has the same effect like unplugging the power cable
Use sudo reboot or sudo shutdown -r
See manual page: http://man7.org/linux/man-pages/man8/shutdown.8.html
