一次惊险的"恢复"过程

  今天某个客户说他们的磁盘整列出来问题，供应商修复了问题后，启动数据库发现某些表不见了，还有一些表数据丢失了。
这个问题给我的第一反应就是磁盘问题导致数据丢失，客户说这个数据库一直没有备份，心里想估计没办法恢复了，后来细想了下，
既然某些表存在，只是少了些记录数，说明ibdata文件是完好的(损坏的话也是整个文件损坏)，心里想莫非是启动的时候引用的my.cnf配置文件的不是正确的配置文件导致的。

咨询了客户，说他们是在root用户下执行service mysql start启动的，该方式启动的,读取的配置文件应该是/etc/my.cnf，但是进如该目录发现没有该文件，不过mysql没有配置文件的情况下也是可以启动的，所有的参数都是默认的，数据文件目录默认是/var/lib/mysql/data目录下，进入该目录发现只有一个ibdata1文件，该文件总大小才是30M,而客户说他们的数据库有上千万的数据，目前mysql读取数据文件估计就是ibdata1文件，所以感觉到数据少了。

这个时候查找系统中所有的my.cnf文件
cd /
find . -name my.cnf
发现/home/mysql_app/config/my.cnf有一个配置文件,该文件的内容如下：
[client]
port=3306
socket=/home/mysql_app/dbdata/mysql.sock
loose-default-character-set = utf8  
default-character-set=utf8


[mysqld]
port=3306
server-id=1
datadir=/home/mysql_app/dbdata
socket=/home/mysql_app/dbdata/mysql.sock
character-set-server=utf8
max_connections = 1500


skip-external-locking
key_buffer_size=16M
max_allowed_packet=16M
myisam_sort_buffer_size=16M
query_cache_size=32M
read_buffer_size=2M  
sort_buffer_size=2M
table_cache=512
thread_cache=20
thread_concurrency=4
interactive_timeout=86400
wait_timeout=86400
#log_slow_queries=1


innodb_file_per_table=1
innodb_additional_mem_pool_size=16M
innodb_buffer_pool_size=512M
innodb_data_home_dir=/home/mysql_app/pro_data
innodb_data_file_path=ibdata1:100M;ibdata2:100M;ibdata3:100M;ibdata4:100M:autoextend
innodb_file_io_threads=4
innodb_flush_log_at_trx_commit=0
innodb_lock_wait_timeout=50
innodb_log_buffer_size=128M
innodb_log_file_size=256M
innodb_log_files_in_group=5
innodb_log_group_home_dir=/home/mysql_app/redolog
innodb_thread_concurrency=8
log_bin_trust_function_creators=1


event_scheduler=1


max_binlog_size=100M
log_bin=/home/mysql_app/mysqllog/binlog/binlog.bin
slow_query_log_file=/home/mysql_app/mysqllog/logfile/slow-query.log
long_query_time=1
log-error=/home/mysql_app/mysqllog/logfile/mysql-err.log
binlog_format=mixed
expire_logs_days=7
binlog_cache_size=4MB
skip-host-cache
skip-name-resolve


#read-only
skip-slave-start
relay-log-index=/home/mysql_app/mysqllog/relay-log/slave-relay-bin.index
relay-log=/home/mysql_app/mysqllog/relay-log/relay-log
replicate-ignore-db=information_schema,performance_schema
slave_net_timeout=60
log_slave_updates=1


[mysql]
#character-set-server=GBK
no-auto-rehash
port=3306
socket=/home/mysql_app/dbdata/mysql.sock


[mysqldump]
max_allowed_packet=16M


发现数据库的目录是在datadir=/home/mysql_app/dbdata，进入该目录发现发现这里有好几个ibdata文件，每个文件的大小都好几个G，
这个才是原来正常情况下的配置文件，在mysql用户下指定该配置文件启动数据库
[mysql@Q302-OSSTJ01 config]$ mysqld_safe --defaults-file=/home/mysql_app/config/my.cnf
140928 18:10:43 mysqld_safe Logging to '/home/mysql_app/mysqllog/logfile/mysql-err.log'.
140928 18:10:43 mysqld_safe Starting mysqld daemon with databases from /home/mysql_appdata

数据库启动后，让用户验证数据，之前不见的表现在找回来了，丢失的数据也找回来了，呵呵！

总结:
1.采用service mysql start启动数据库，默认读取的配置文件是在/etc/my.cnf，若该文件不存在，数据库是可以启动的，一切参数都是默认的，
数据文件目录默认是在/var/lib/mysql/data目录下。


2.定制了配置参数的话，启动的时候一定要制定自己配置的配置参数,不指定的话，数据库也能启动，但读取的参数都是默认的。


-- The End --