Server outrages - Page 50

unconnected · 2020-01-10, 10:22

https://dev.mysql.com/doc/refman/5.7...-recovery.html
Or follow rebirther's link but start with innodb_force_recovery = 1
Recovering InnoDB databases isn't easy, possibly the simpliest way is to completely drop database and restore from latest backup if you have any.

gd_barnes · 2020-01-10, 21:02

I am trying Rebirther's suggested link. I was able to stop the SQL server in step 1. But I am unable to do steps 2 or 3 because I do not have permissions.

I get the following message:
You do not have the permissions necessary to open the file.

How do I get permissions to read, copy, write, or open these files?

I know it has something to do with having to be the root user but I cannot figure out how to do that.

One more thing: The my.cnf file is in /etc/mysql/my.cnf (not /etc/my.cnf).

rogue · 2020-01-10, 21:18

Quote:

Originally Posted by gd_barnes

I am trying Rebirther's suggested link. I was able to stop the SQL server in step 1. But I am unable to do steps 2 or 3 because I do not have permissions.

I get the following message:
You do not have the permissions necessary to open the file.

How do I get permissions to read, copy, write, or open these files?

I know it has something to do with having to be the root user but I cannot figure out how to do that.

One more thing: The my.cnf file is in /etc/mysql/my.cnf (not /etc/my.cnf).

Use "chown" or "chmod" to get access.

yoyo · 2020-01-10, 21:49

Yes, rebirther's link are the steps todo. Start with recovery=1 and check if the db starts.

You must be root, e.g. by "sudo bash" or "su -" to backup the IB files.

gd_barnes · 2020-01-10, 22:55

Using the link in Reb's post as a reference.

I was able to log in as root and backup the files in step #2.

Per step #3 I edited /etc/mysql/my.cnf to have the command:
innodb_force_recovery = 1

I'm now to step 4.

I stopped MySQL with:
sudo service mysql stop

Message said it stopped successfully.

I attempted to restart MySQL with:
sudo service mysql start

I got the following message:
* Starting MySQL database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
gary@jeepford:~$ ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query

This is the same message that I got before.

I then did an SQL status with this command:
sudo service mysql status

Output was this:

Code:

 * /usr/bin/mysqladmin  Ver 8.41 Distrib 5.0.75, for debian-linux-gnu on x86_64
Copyright (C) 2000-2006 MySQL AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version        5.0.75-0ubuntu10.5
Protocol version    10
Connection        Localhost via UNIX socket
UNIX socket        /var/run/mysqld/mysqld.sock
Uptime:            1 sec

Threads: 1  Questions: 2  Slow queries: 0  Opens: 12  Flush tables: 1  Open tables: 6  Queries per second avg: 2.000

My question is: Do I continue with step 5 by dumping all the tables? Or is the above error a problem that keeps me from continuing until it is fixed? I was hoping that the recovery line in my.cnf would correct this.

gd_barnes · 2020-01-11, 01:42

So...after doing steps 2 and 3 and running into that previous error on step 4...I thought I would try step 5 with the following command:

root@jeepford:/etc/mysql# mysqldump -u gary -p prpnet1300 > dump1300.sql

It then made me enter my root password, which I did. It then gave the following message:

mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect

I cannot seem to get away from that message.

Note that I only tried to dump one of the servers. It would not allow me to use the -A command as specified in the instructions for #5.

Somehow we need to get it to correctly connect to the DB so that it can be dumped.

Help!

Happy5214 · 2020-01-11, 04:26

I ran into this issue with my home server's previous OS install (Ubuntu 17.10 IIRC). I ended up reinstalling the OS (since I couldn't reinstall MySQL without killing my PIM setup), but this script may help get the server running so you can dump the contents (bypassing the permissions; make sure it's not publicly accessible):

Code:

#!/bin/sh

sudo mkdir /var/run/mysqld
sudo chown -R mysql /var/run/mysqld/
sudo mysqld --skip-grant-tables

gd_barnes · 2020-01-11, 06:05

Quote:

Originally Posted by Happy5214

I ran into this issue with my home server's previous OS install (Ubuntu 17.10 IIRC). I ended up reinstalling the OS (since I couldn't reinstall MySQL without killing my PIM setup), but this script may help get the server running so you can dump the contents (bypassing the permissions; make sure it's not publicly accessible):

Code:

#!/bin/sh

sudo mkdir /var/run/mysqld
sudo chown -R mysql /var/run/mysqld/
sudo mysqld --skip-grant-tables

This did not work. I got the following gibberish:

Code:

gary@jeepford:~$ sudo mysqld --skip-grant-tables
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
200111 0:04:20 InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
200111 0:04:33 InnoDB: ERROR: We were only able to scan the log up to
InnoDB: 65 3180301824, but a checkpoint was at 65 3180302287.
InnoDB: It is possible that the database is now corrupt!
200111 0:04:33 InnoDB: Error: page 1 log sequence number 65 3182452991
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 4 log sequence number 65 3181673642
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 6 log sequence number 65 3182821206
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 49172 log sequence number 65 3186685478
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 49153 log sequence number 65 3186345244
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 202272 log sequence number 65 3186682578
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 196609 log sequence number 65 3181146735
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 330293 log sequence number 65 3186631187
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 327681 log sequence number 65 3184275303
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 344075 log sequence number 65 3181039382
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 344065 log sequence number 65 3182245162
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 212993 log sequence number 65 3182730042
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 147457 log sequence number 65 3185010846
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 5 row operations to undo
InnoDB: Trx id counter is 0 2825215232
200111 0:04:33 InnoDB: Error: page 0 log sequence number 65 3182821206
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Cleaning up trx with id 0 2825225248
200111 0:04:33 InnoDB: Rollback of non-prepared transactions completed
200111 0:04:33 InnoDB: Error: page 311297 log sequence number 65 3183278764
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Error: page 114689 log sequence number 65 3181146898
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:33 InnoDB: Started; log sequence number 65 3180302287
InnoDB: !!! innodb_force_recovery is set to 1 !!!
200111 0:04:33 [Note] mysqld: ready for connections.
Version: '5.0.75-0ubuntu10.5' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
200111 0:04:34 InnoDB: Error: page 278529 log sequence number 65 3182822051
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 294913 log sequence number 65 3182821788
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 131073 log sequence number 65 3183083236
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 65537 log sequence number 65 3181343415
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 163841 log sequence number 65 3181146680
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 229377 log sequence number 65 3181075900
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 32769 log sequence number 65 3186349072
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 192040 log sequence number 65 3180871058
InnoDB: is in the future! Current system log sequence number 65 3180302379.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 180225 log sequence number 65 3181147455
InnoDB: is in the future! Current system log sequence number 65 3180302379.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111 0:04:34 InnoDB: Error: page 43376 log sequence number 65 3181145698
InnoDB: is in the future! Current system log sequence number 65 3180302379.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
InnoDB: Error: trying to access page number 1768430057 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
200111 0:04:34InnoDB: Assertion failure in thread 139684868266320 in file fil0fil.c line 3959
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.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
200111 0:04:34 - mysqld got signal 11 ;
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=134217728
read_buffer_size=6291456
max_used_connections=0
max_connections=200
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
frame pointer is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
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.

I tried it both with MySQL stopped and then again with it started. No luck.

yoyo · 2020-01-11, 06:59

First enable mysql logging. I have in [mysql]
log_error = /var/log/mysql/error.log

After you restarted mysql, check with e.g. "ps -ef | grep mysql" if mysql is running and with some sql command if you can access a table. You can also try to run an mysqldump. Check also the mysql error log. If mysql crashes you would see some segmentation fault of memory dumps.

If mysql is not running, set recovery=2 and try again.
And so on.
At least with recovery=5 mysql should start and report some error in error log.
But now you can run mysqldump.

gd_barnes · 2020-01-11, 10:17

With all of your help I've made quite a bit of progress.

I changed the recovery command to:
innodb_force_recovery = 5

That successfully started MySQL and allowed me to dump the databases.

When doing the dump with the -A command of course it dumps them all in one file. But I got a new database error message after a long time of dumping. I had a strong suspicion which database was corrupt on my machine. It is my personal server prpnet1470. Suspecting this I dumped only prpnet1470 and there it was with the same error message! All of the other databases dumped just fine.

Here is the message that I am getting for database prpnet1470 when I try to dump it:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `CandidateTestResult` at row: 251210

So if I follow Reb's link's instructions I'm going to be dumping all the databases, dropping them all, removing some files, restarting MySQL, and restoring all of the databases from the dump.

At this point, that seems like overkill.

My question is:
Should I just dump and drop prpnet1470? If so do I want to do step 8 which is: Remove /var/lib/mysql/ib*

I'm afraid to remove all of the ib* files from that library if I am dropping only one database.

I guess what I need is more specific instructions on fixing the one database that I know is corrupt, which is causing problems for MySQL.

I could even just permanently delete prpnet1470 and not restore it. I was able to do enough select statements to know where I'm at in my testing so there would be no data loss. It would be nice to keep it intact but if it is too much of a problem to do so there are other personal servers that I could use.

rebirther · 2020-01-11, 13:23

If you know the lib name of the affected database remove only the name of the lib file not all.

2020-01-10, 10:22	#540
unconnected May 2009 Russia, Moscow 43×59 Posts	https://dev.mysql.com/doc/refman/5.7...-recovery.html Or follow rebirther's link but start with innodb_force_recovery = 1 Recovering InnoDB databases isn't easy, possibly the simpliest way is to completely drop database and restore from latest backup if you have any. Last fiddled with by unconnected on 2020-01-10 at 10:24

2020-01-10, 22:55	#544
gd_barnes May 2007 Kansas; USA 11×937 Posts	Using the link in Reb's post as a reference. I was able to log in as root and backup the files in step #2. Per step #3 I edited /etc/mysql/my.cnf to have the command: innodb_force_recovery = 1 I'm now to step 4. I stopped MySQL with: sudo service mysql stop Message said it stopped successfully. I attempted to restart MySQL with: sudo service mysql start I got the following message: * Starting MySQL database server mysqld [ OK ] * Checking for corrupt, not cleanly closed and upgrade needing tables. gary@jeepford:~$ ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query This is the same message that I got before. I then did an SQL status with this command: sudo service mysql status Output was this: Code: * /usr/bin/mysqladmin Ver 8.41 Distrib 5.0.75, for debian-linux-gnu on x86_64 Copyright (C) 2000-2006 MySQL AB This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license Server version 5.0.75-0ubuntu10.5 Protocol version 10 Connection Localhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime: 1 sec Threads: 1 Questions: 2 Slow queries: 0 Opens: 12 Flush tables: 1 Open tables: 6 Queries per second avg: 2.000 My question is: Do I continue with step 5 by dumping all the tables? Or is the above error a problem that keeps me from continuing until it is fixed? I was hoping that the recovery line in my.cnf would correct this. Last fiddled with by gd_barnes on 2020-01-10 at 22:56

2020-01-11, 01:42	#545
gd_barnes May 2007 Kansas; USA 24103₈ Posts	So...after doing steps 2 and 3 and running into that previous error on step 4...I thought I would try step 5 with the following command: root@jeepford:/etc/mysql# mysqldump -u gary -p prpnet1300 > dump1300.sql It then made me enter my root password, which I did. It then gave the following message: mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect I cannot seem to get away from that message. Note that I only tried to dump one of the servers. It would not allow me to use the -A command as specified in the instructions for #5. Somehow we need to get it to correctly connect to the DB so that it can be dumped. Help! Last fiddled with by gd_barnes on 2020-01-11 at 01:43

2020-01-11, 04:26	#546
Happy5214 "Alexander" Nov 2008 The Alamo City 2⁴·31 Posts	I ran into this issue with my home server's previous OS install (Ubuntu 17.10 IIRC). I ended up reinstalling the OS (since I couldn't reinstall MySQL without killing my PIM setup), but this script may help get the server running so you can dump the contents (bypassing the permissions; make sure it's not publicly accessible): Code: #!/bin/sh sudo mkdir /var/run/mysqld sudo chown -R mysql /var/run/mysqld/ sudo mysqld --skip-grant-tables Last fiddled with by Happy5214 on 2020-01-11 at 04:28

2020-01-11, 10:17	#549
gd_barnes May 2007 Kansas; USA 11·937 Posts	With all of your help I've made quite a bit of progress. I changed the recovery command to: innodb_force_recovery = 5 That successfully started MySQL and allowed me to dump the databases. When doing the dump with the -A command of course it dumps them all in one file. But I got a new database error message after a long time of dumping. I had a strong suspicion which database was corrupt on my machine. It is my personal server prpnet1470. Suspecting this I dumped only prpnet1470 and there it was with the same error message! All of the other databases dumped just fine. Here is the message that I am getting for database prpnet1470 when I try to dump it: mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `CandidateTestResult` at row: 251210 So if I follow Reb's link's instructions I'm going to be dumping all the databases, dropping them all, removing some files, restarting MySQL, and restoring all of the databases from the dump. At this point, that seems like overkill. My question is: Should I just dump and drop prpnet1470? If so do I want to do step 8 which is: Remove /var/lib/mysql/ib* I'm afraid to remove all of the ib* files from that library if I am dropping only one database. I guess what I need is more specific instructions on fixing the one database that I know is corrupt, which is causing problems for MySQL. I could even just permanently delete prpnet1470 and not restore it. I was able to do enough select statements to know where I'm at in my testing so there would be no data loss. It would be nice to keep it intact but if it is too much of a problem to do so there are other personal servers that I could use. Last fiddled with by gd_barnes on 2020-01-11 at 10:31

2020-01-10, 21:02	#541
gd_barnes May 2007 Kansas; USA 24103₈ Posts	I am trying Rebirther's suggested link. I was able to stop the SQL server in step 1. But I am unable to do steps 2 or 3 because I do not have permissions. I get the following message: You do not have the permissions necessary to open the file. How do I get permissions to read, copy, write, or open these files? I know it has something to do with having to be the root user but I cannot figure out how to do that. One more thing: The my.cnf file is in /etc/mysql/my.cnf (not /etc/my.cnf).

2020-01-10, 21:49	#543
yoyo Oct 2006 Berlin, Germany 607 Posts	Yes, rebirther's link are the steps todo. Start with recovery=1 and check if the db starts. You must be root, e.g. by "sudo bash" or "su -" to backup the IB files.

2020-01-11, 06:59	#548
yoyo Oct 2006 Berlin, Germany 607 Posts	First enable mysql logging. I have in [mysql] log_error = /var/log/mysql/error.log After you restarted mysql, check with e.g. "ps -ef \| grep mysql" if mysql is running and with some sql command if you can access a table. You can also try to run an mysqldump. Check also the mysql error log. If mysql crashes you would see some segmentation fault of memory dumps. If mysql is not running, set recovery=2 and try again. And so on. At least with recovery=5 mysql should start and report some error in error log. But now you can run mysqldump.

2020-01-11, 13:23	#550
rebirther Sep 2011 Germany 2·3²·151 Posts	If you know the lib name of the affected database remove only the name of the lib file not all.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
What exactly is sent to the server?	paul0	NFS@Home	2	2015-03-12 23:00
Server bug -- new?	Christenson	Information & Answers	5	2011-07-12 21:44
Server Down?	Grant	Information & Answers	13	2008-11-24 19:37
New ECM-server available	andi314	Factoring	3	2003-08-31 11:22
New Server Hardware and price quotes, Funding the server	Angular	PrimeNet	32	2002-12-09 01:12