Hello, after installing updates to the Ubuntu 16.04.3 I noticed that the ‘mariadb’ didn’t stop properly during shutdown and reboot. It timed out (3 minutes) and then the machine continued to shutdown and reboot. But then the Nextcloud didn’t work anymore after booting up.
The apache2/error.log shows these errors:
[client 192.168.25.100:5504] PHP Fatal error: Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [2002] No such file or directory in /var/www/nextcloud/lib/private/DB/Connection.php:61\nStack trace:\n#0
stopping and starting apache didn’t help. I actually don’t know what to do, tried to google this error and noticed some solutions which change permissions on certain files.
I think the database is corrupt or something like that. What is the best way to recover?
Hello Jason, Michaing, thank you for your help.
I do have a config backup of Nextcloud. The database itself is ‘too big’ to backup; actually I keep all folders on my local pc and then picks the things I need from my laptop or tablet. In worst case I have to reinstall the vm but to synchronize it then takes days, what I hope to prevent.
My experience with databases is not that much; I noticed that mysql is not running. When I try to start it, I get this output:
root@cloud:/home/ncadmin# /etc/init.d/mysql start
[…] Starting mysql (via systemctl): mysql.serviceJob for mariadb.service failed because the control process exited with error code. See “systemctl status mariadb.service” and “journalctl -xe” for details.
Then, when I give that command I get this:
root@cloud:/home/ncadmin# systemctl status mariadb.service
â mariadb.service - MariaDB database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/mariadb.service.d
ââmigrated-from-my.cnf-settings.conf
Active: failed (Result: exit-code) since Thu 2017-10-26 10:31:40 CEST; 8min ago
Process: 6711 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
Process: 6504 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=/usr/bin/galera_recovery; [ $? -eq 0 ] && systemctl set-environment _WSRE
Process: 6499 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 6494 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Main PID: 6711 (code=exited, status=1/FAILURE)
Status: “MariaDB server is down”
Oct 26 10:31:38 cloud.domain1.com mysqld[6711]: 2017-10-26 10:31:38 139855941114048 [Note] InnoDB: Transaction contains changes to 1 rows
Oct 26 10:31:38 cloud.domain1.com mysqld[6711]: 2017-10-26 10:31:38 139855941114048 [Note] InnoDB: 1 transactions in prepared state after recovery
Oct 26 10:31:38 cloud.domain1.com mysqld[6711]: 2017-10-26 10:31:38 139855941114048 [Note] Found 1 prepared transaction(s) in InnoDB
Oct 26 10:31:38 cloud.domain1.com mysqld[6711]: 2017-10-26 10:31:38 139854713177856 [Note] InnoDB: Buffer pool(s) load completed at 171026 10:31:38
Oct 26 10:31:38 cloud.domain1.com mysqld[6711]: 2017-10-26 10:31:38 139855941114048 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properl
Oct 26 10:31:38 cloud.domain1.com mysqld[6711]: 2017-10-26 10:31:38 139855941114048 [ERROR] Aborting
Oct 26 10:31:40 cloud.domain1.com systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Oct 26 10:31:40 cloud.domain1.com systemd[1]: Failed to start MariaDB database server.
Oct 26 10:31:40 cloud.domain1.com systemd[1]: mariadb.service: Unit entered failed state.
Oct 26 10:31:40 cloud.domain1.com systemd[1]: mariadb.service: Failed with result ‘exit-code’.
lines 1-22/22 (END)
I know yes, the database wasn’t shutdown correctly since the ‘shutdown sequence of the database’ timed out during shutdown of the machine. What can I do best now to repair this?
I just recognize the galera thing inside your logs, do you somehow use galera, since this is just for clustered databases if I didn’t get something wrong. Could/Should be disabled in case.
Read carefully and slowly increase the value until mariadb starts up. And then do a dump/backup of the nextcloud tables at least. How come your database is too big for regular backup? How big is it?
Hello, I tried to recover and ultimately ended up to ‘level 6’ . That made mysql start, however, even after waiting a while and then reset the recovery mode setting to 0, nextcloud doesn’t work.
What I do now is rebuild the vm from scratch (i.e. load the preconfigured vm appliance) and then import the Terabyte of files back.
What I also will do is make an alias with a shutdown command that shuts down mysql first and then shuts down the server. I think this won’t break the mysql database ‘shutdown’ when the computer is shutdown or rebooted. Please correct me if I’m wrong.
By the way I found a Nextcloud backup of the config but from an earlier Nextcloud version, grrr.
Yes I should backup more frequently! Thanks anyway for your help all.
Ralph
Uh, yes level 6 is high, seemed to be scrembled . So you were able to dump or repair the database there? (Of course just waiting will not repair it…)
But as stated on the mariadb manual, further errors can occure if you use a level higher than 4, so we need to be lucky to make it work fine again, I guess.
I had this once too and also wasn’t able to fully recover from there. At least I was able to identity and just remove the corrupted table, thus save all the others, contacts, shares, etc. Corrupted was the oc_filecache which was usually the by far biggest table and easy to rebuild by nextcloud/occ files:scan --all.
. So you were able to dump or repair the database there? (Of course just waiting will not repair it…)