Innodb和MyISAM表问题

Question

I had a hard drive crash that led to some issues on an SQL database. Since then, I have rebuilt from a backup, but an issue keeps coming up that makes no sense to me. Hopefully it will to someone here. I am really just looking for help on where to find the source of the issue. I can fix from there. I have read hundreds of posts and searched the web endlessly on this one. Of course, someone might post a link that has the answer that I missed.

Server is old, running CentOS 5 and MySQL 5.0.77. I intend to upgrade after fixing this issue.

The database has both MyISAM and InnoDB tables. Through phpmyadmin, I see that InnoDB is not running. I checked my.cnf and there are no indications there that it is not running, unless I am missing something.

    [mysqld]
innodb_file_per_table = 1
log-bin=/var/lib/mysql/

binlog-ignore-db=supp
server-id=5
#master-host=
#master-user=
#master-password=
#master-connect-retry=60
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
skip-name-resolve
relay-log=/data1/mysqld/mysqld-relay-bin
skip-slave
#set-variable    = join_buffer_size=60M
set-variable    = key_buffer=128M
set-variable    = max_allowed_packet=30M
set-variable    = table_cache=64
set-variable    = sort_buffer=8M
set-variable    = record_buffer=2M
set-variable    = myisam_sort_buffer_size=8M
set-variable    = thread_cache=4
set-variable    = thread_concurrency=2
set-variable    = max_connections=500
set-variable    = wait_timeout=3600

#


# Uncomment the following if you are using BDB tables
#set-variable   = bdb_cache_size=64M

# Point the following paths to different dedicated disks
tmpdir          = /var/tmp/
#log-update     = /path-to-dedicated-directory/hostname

innodb_data_home_dir=
innodb_data_file_path = /data1/ibdata/ibdata1:5000M;/data1/ibdata/ibdata2:5000M;/data1/ibdata/ibdata3:5000M;/data1/ibdata/ibdata4:5000M:autoextend
set-variable = innodb_buffer_pool_size=1G
set-variable = innodb_additional_mem_pool_size=5M
innodb_log_group_home_dir= /data1/iblogs
innodb_log_arch_dir = /data1/iblogs
set-variable = innodb_log_files_in_group=3
##
set-variable = innodb_log_file_size=100M
set-variable = innodb_log_buffer_size=16M
set-variable = innodb_file_io_threads=8
set-variable = innodb_lock_wait_timeout=100
set-variable = innodb_autoextend_increment=200
#
innodb_flush_log_at_trx_commit=0
innodb_log_archive=0

set-variable = innodb_lock_wait_timeout=100
#innodb_flush_method = O_DSYNC

[mysqldump]
quick
set-variable    = max_allowed_packet=16M

[mysql]
no-auto-rehash
#safe-updates   # Remove the comment character if you are not familiar with SQL

[isamchk]
set-variable    = key_buffer=2M
set-variable    = sort_buffer=1M
set-variable    = read_buffer=1M
set-variable    = write_buffer=1M

[myisamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

In phpmyadmin, all InnoDB tables show as 'In Use' and report a 1033 error. When I create a new database and copy the tables over, the same thing happens. The only thing that worked was to create the database from an sql dump file, but this created old data, as the backup is a bit old. The new database had all MyISAM tables and they work, minus some syntax errors from CGI files seeking data from them. I can work around that for now.

I didn't create this server and never managed one before. I have fixed a host of problems and am working on getting someone to help out, but it's been difficult. I only ask that someone point me in the right direction.

What would cause only the InnoDB tables to have a problem with incorrect information? I have searched the error logs and they report much the same, a slew of 'Incorrect information in table.frm' errors.

To keep this as short as possible, I will stop here, but am happy to explain more if necessary.

mysqld log:

    190122 12:45:02  mysqld started
190122 12:45:02 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
190122 12:45:02 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/error-creating-innodb.html
190122 12:45:03 [Warning] 'user' entry 'root@fmdb2' ignored in --skip-name-resolve mode.
190122 12:45:03 [Warning] 'user' entry 'leadtraffic@www.bravelcon.com' ignored in --skip-name-resolve mode.
190122 12:45:03 [Warning] 'db' entry 'leadtraffic leadtraffic@www.bravelcon.com' ignored in --skip-name-resolve mode.
190122 12:45:03 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.77-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Answer 1

Here's a blog that I think is similar to your case: https://eric.lubow.org/2010/mysql-error-1033-incorrect-information-in-file/

In that case, the user started MySQL Server, but the InnoDB storage engine couldn't initialize. In old versions of MySQL, if the InnoDB engine can't start, it isn't a fatal error, but as you might guess, you won't be able to read or write InnoDB tables without that engine. There was an option to force the server to stop if it can't initialize InnoDB, but this option was not enabled by default in those days.

As shown in the blog, you can confirm if InnoDB is disabled or not present in the list of engines:

mysql> SHOW ENGINES;

The .FRM files are metadata files that are present for tables regardless of storage engine, so when you query a table, it first opens the .FRM file to get the table definition. That's fine, but then if it can't read the table data because the InnoDB engine isn't running, it gets confused. " There's table metadata but no table?? "

You need to figure out why InnoDB couldn't start, and correct that problem. The clues will likely be in the MySQL error log. See for example the case reported in that blog.

In the blog, the user found that another mysqld process was already running, and was holding a file lock on the InnoDB tablespace ibdata1 . So in the second instance, the startup of MySQL Server couldn't get the lock on that file and gave up.

In your case, as you reported in your question a couple of weeks ago ( ERROR /usr/libexec/mysqld: Incorrect information in file ), there was some sign that you had another instance of mysqld running:

190105 17:11:09 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use
190105 17:11:09 [ERROR] Do you already have another mysqld server running on port: 3306 ?

---

The error you showed in your error log:

InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.

This indicates something is seriously wrong with the InnoDB log files, ib_logfile0 and ib_logfile1 . They could be corrupt or unusable. This sometimes happens when you try to move the log files around while the mysqld is running.

You've gotten your MySQL instance into a risky state, and you might lose all your data. I really recommend you get some qualified data recovery specialist. I made this recommendation in my last answer as well.

The other option is to chalk it up to experience. Remove all your InnoDB files, restart the MySQL Server, and let it initialize a new tablespace (which will be empty).