Check the MySQL error log. It looks like trying to read table 44 is actually crashing the server.
"Lost connection to MySQL server during query" is (or should be) heart-stopping time for a MySQL DBA because it often means that whatever your query just did has actually crashed the server.
The subsequent messages seem to bear this out:
mysqldump: Got error: 2003: Can't connect to MySQL server on 'localhost' (10061) when
trying to connect
Operation failed with exitcode 2
A quick test of mysqldump on Windows 7 against a MySQL server that is not running returns exactly that same error and exits with %ERRORLEVEL%
set to 2. The nature of error 10061 can be found with the perror
utility.
C:\>perror 10061
Win32 error code 10061: No connection could be made because the target machine actively refused it.
...so, check the MySQL error log. What's likely happening is that you're hitting corruption severe enough that in spite of innodb_force_recovery
, the MySQL Server is crashing. I will then usually restart on its own, but this takes time so may not complete before mysqldump gets an IP connection refused on the subsequent connection attempts. This should all show up in the error log.
I assume that when the dump does not yield any error, the table's data is non-corrupted.
Incorrect assumption. If the dump does not yield any error, it could also mean that that innodb_force_recovery
allowed the server to retrieve some of the data. A "successful" dump of a table only means it's not corrupted so severely that innodb_force_recovery
can't survive it.
1 (SRV_FORCE_IGNORE_CORRUPT)
Let the server run even if it detects a corrupt page. Try to make SELECT * FROM tbl_name
jump over corrupt index records and pages, which helps in dumping tables.
http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Again, you should see chatter from InnoDB in the MySQL error log.
Final suggestion, don't use workbench. Use the mysql
command line client to explore the server schemata and use mysqldump
directly from the command line to try to restore individual schemas or individual databases.
update/additional:
how do you recover stored procedures? I get an error because they access corrupt tables
It shouldn't be because the procedures access corrupt tables, because stored procedures and functions aren't validated against their referenced tables in the way views are (drop a table that a view references, and then SHOW CREATE VIEW
doesn't work -- the same isn't the case with procs or functions)... MySQL doesn't care whether tables referenced by stored procedures and functions even exist (except at runtime)... however, unlike view definitions, which are stored in individual files, the definitions of procedures and functions are stored in the proc
table in the mysql
schema, which is a MyISAM table... so I would expect that you'd see error messages referencing that table and CHECK TABLE mysql.proc;
and REPAIR TABLE mysql.proc;
might get you going again. Note that the version of MySQL Server that you're using for your recovery needs to be the same release series (e.g. 5.5) or the table definition of mysql.proc
will be wrong... that shouldn't be the issue here, since if I read the question correctly, the crashed server and the recovery server are both 5.5.31.
If you can SELECT * FROM mysql.proc
then you can retrieve the definitions that way if for some reason the SHOW CREATE PROCEDURE
statement doesn't work.
And what options for a (partial) rescue are there for the tables that yielded an error in the dumps?
It depends on the nature and scope of the errors encountered. One option, discussed here, involves repeated INSERT ... SELECT ... LIMIT ... OFFSET
, extracting blocks of rows from readable pages into a MyISAM table (because you can't write to an InnoDB table while innodb_force_recovery
is on). There's also the Percona Data Recovery Tool for InnoDB, though I have never had occasion to use it.
This is what I do to start the mysql daemon manually.
I've also included my own my.cnf. By specifying the correct corresponding paths in your system, you should be able to do the same thing. I would also point out that this is a source install, but again, it should apply generally.
Start the daemon like this:
./bin/mysqld --defaults-file=./my.cnf
And start the client with:
./bin/mysql -S ./mysql.sock -u root -pdba
Both mysqld and mysql client are launched from the basedir. This can be scripted easily of course.
This is my my.cnf - it's a bit of a mess, but hopefully it should help. I stress that this is not a production server!
[mysqld]
#
# * Basic Settings
#
user = pol
pid-file = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/mysqld.pid
socket = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/mysql.sock
port = 3306
basedir = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64
datadir = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/data
tmpdir = /tmp
pid-file = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/mysql.pid
lc-messages-dir = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/share
lc-messages = en_US
general_log = on
general_log_file= /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/logfile.txt
#log_error = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/error.log
log-error = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/error.log
slow_query_log_file = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/slow_query.log
slow_query_log = 0
explicit-defaults-for-timestamp = TRUE
#language = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/share/english
# bind-address = 0.0.0.0 - may not need c.f. host...
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY
[client]
port = 3306
socket = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/mysqld.sock
host = 127.0.0.1
user = pol
# or maybe localhost... cf. bind-address above...
# added from http://dev.mysql.com/doc/refman/5.6/en/load-data-local.html
# to allow for abrowse to load data!
#loose-local-infile = 1
local-infile = 1 -- ignore this, it's a setting for abrowse, an external programme.
[mysqld_safe]
#user = linehanp
#socket = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/mysql.sock
#err-log = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/error.log
#pid-file = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/mysql.pid
#log_error = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/error.log
#log-error = /home/pol/Downloads/mysql/mysql5.6.19/mysql-5.6.19-linux-x86_64/error.log
Best Answer
They are needed for the mysql to generate nbew ssl keys
So to answer your question
When you active ssl in my.ini
like
you can allow a user only to access via ssl
First you generate a new ssl certificate for a user exampleuser
and add like this the use of ssl
fionaööy you can access mysql via ssl like this