问题1:
$ /etc/init.d/mysqld1 status
MySQL is not running, but lock exists
解决方案:
A MySQL crash on Red Hat system resulted with:
/etc/init.d/mysql status
coming back with:
mysql is not running but lock exists
Solved by removing the lock file:
rm /var/lock/subsys/mysql
If this happens again it may also be necessary to remove the pid file from /var/lib/mysql
问题2:
$ /etc/init.d/mysqld1 start
Starting MySQL/data_big/mysql/data1
.Manager of pid-file quit without updating file. [FAILED]
解决方案:
首先查看mysql日志:
找到mysql安装目录下.err后缀的文件,可以通过 sudo sz *.err 下载下来查看
异常消息如下:
171107 16:56:09 mysqld_safe Starting mysqld daemon with databases from /data_big/mysql/data1
-11-07 16:56:10 0 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
-11-07 16:56:10 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
-11-07 16:56:10 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.6.29-log) starting as process 9060 ...
-11-07 16:56:10 9060 [Warning] Using unique option prefix myisam_recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
-11-07 16:56:10 9060 [Note] Plugin 'FEDERATED' is disabled.
-11-07 16:56:10 9060 [Note] InnoDB: Using atomics to ref count buffer pool pages
-11-07 16:56:10 9060 [Note] InnoDB: The InnoDB memory heap is disabled
-11-07 16:56:10 9060 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
-11-07 16:56:10 9060 [Note] InnoDB: Memory barrier is not used
-11-07 16:56:10 9060 [Note] InnoDB: Compressed tables use zlib 1.2.3
-11-07 16:56:10 9060 [Note] InnoDB: Using Linux native AIO
-11-07 16:56:10 9060 [Note] InnoDB: Using CPU crc32 instructions
-11-07 16:56:10 9060 [Note] InnoDB: Initializing buffer pool, size = 4.0G
-11-07 16:56:10 9060 [Note] InnoDB: Completed initialization of buffer pool
-11-07 16:56:10 9060 [Note] InnoDB: Highest supported file format is Barracuda.
-11-07 16:56:10 9060 [Note] InnoDB: The log sequence numbers 1600614 and 1600614 in ibdata files do not match the log sequence number 15629474422 in the ib_logfiles!
-11-07 16:56:10 9060 [Note] InnoDB: Database was not shutdown normally!
-11-07 16:56:10 9060 [Note] InnoDB: Starting crash recovery.
-11-07 16:56:10 9060 [Note] InnoDB: Reading tablespace information from the .ibd files...
-11-07 16:56:10 9060 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/slave_master_i
仔细查看,发现日志消息中给出了三种解决方案:
To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in f
InnoDB: and force InnoDB to continue crash recovery here.
171107 16:56:10 mysqld_safe mysqld from pid file /data_big/mysql/data1/iZwz9istfz0zvx3yuaf6tqZ.pid ended
拓展:
看看日志文件的大小 看看f 设定的日志文件大小 看看磁盘使用百分比 备份并清除日志文件吧！ 再重启试试看
这个命令可以查看默认f文件的位置
mysql --help|grep 'f'
