MySQL problems caused by disk problems

After receiving Nagios notifications, the company's MySQL has a synchronization problem from the library slave.

Similar problems arise when a power outage has been tried before, and the problem is suspected to originate from the Master Repository master server;

After logging into the main library, subconsciously did not check MySQL for the first time, but to view disk space,

I found out that the Mount command didn't show my data disk, and it was strange to have access to the data directory.

Try Mount-a prompt disk busy,

Since the production services provided by this server are not important, try Reboot

I guess the reboot will be problematic, so log on to ESXi to observe the console (the server is a virtual machine),

There is a problem, the disk detects the prompt disk is not contiguous,

Enter the password, and then fsck-y check the disk for the corresponding prompt

There's a total of 3 disks in a discontinuous situation.

After the repair, the normal restart, the disk also came out

And found that Mysqld couldn't start.

View error log file, prompt disk full, unable to write PID file

Check/Table of contents, sure enough space left 0, delete some useless files, and then try to start mysqld

But the error message changed.

160405 9:24:40 [ERROR]/usr/libexec/mysqld:table './syslog/systemevents ' is marked as crashed and should be repaired

It is most likely caused by a problem with disk discontinuities.

So Myisamchk-r/data/mysql/syslog/systemevents.myi

Fixed an index that attempted to start successfully.

The main library is back to normal.

View tips from the library, changes have occurred

Mysql> Show Slave Status\g

Last_error:relay Log read failure:could not parse Relay log event entry. The possible reasons Are:the master ' s binary log is corrupted (you can check this by running ' mysqlbinlog ' on the binary Log), the slave ' s relay log is corrupted (you can check this by running ' Mysqlbinlog ' on the relay log), a network problem , or a bug in the master's or slave ' s MySQL code. If you want to check the master's binary log or slave ' s relay log, you'll be a able to know their names by issuing ' SHOW s Lave STATUS ' on this slave.

The main idea is that your relay log file cannot be parsed, usually caused by binlog corruption of the master library.

The scenario I chose is to redo the data from the library

The repository is then backed up and imported into the library.

Main Library:

Mysqldump-uroot-ppassword-b Syslog--single-transaction--events--opt--master-data=1|gzip >/data/Syslog-full-' Date +%f '. sql.gz

From library:

mysql> slave stop;

Mysql-u Root-ppassword <syslog-full-2016-04-05.sql

mysql> slave start;

Query OK, 0 rows Affected (0.00 sec)

Mysql> Show Slave Status\g

This returns to normal from the library.

MySQL problems caused by disk problems