Simple troubleshooting for MySQL database startup failures

Generally, experienced administrators usually detach the operating system from the application software when deploying the operating system, and install the two in different disks or partitions, and there will be a certain amount of resource balance to meet the needs of long-term operation in the future

Generally, experienced administrators usually detach the operating system from the application software when deploying the operating system, and install the two in different disks or partitions, and there will be a certain amount of resource balance to meet the needs of long-term operation in the future

Generally, experienced administrators usually detach the operating system from the application software when deploying the operating system, and install the two in different disks or partitions, in addition, there will be a certain amount of resource balance to meet the needs of long-term operation in the future. However, in a virtualized environment, resource shortage and chaotic management often occur. In particular, resource waste is very serious, which is often caused by unbalanced resource allocation and inaccurate initial measurement of physical servers. No matter what the reason is, only taking time to clean up and solve the problem is a kind of sound O & M. Otherwise, it will be very troublesome to accumulate hundreds of virtual machines in the future, in particular, template problems are very serious.

Database systems are often the most demanding applications, not only demanding CPU memory requirements (especially memory), but also demanding hard disk speed (I/O) and size. It is worthwhile to allocate a large memory and a fast hard disk when deploying the MySQL database. At least carefully configure the my. cnf file. Of course, it is best to make an effective assessment of the physical server. First, develop a script system configuration that meets the running conditions, and then calculate the running status for a long time, the distribution of CPU, memory, hard disk, and network pressure, and the peak time are concentrated at which stage. Then, a more accurate configuration and optimization result is obtained based on log analysis.

Find the location of the log from the configuration file/etc/my. cnf of the MySQL database, and delete the error log after confirmation.

[Root @ zabbixserver ~] # Rm-rf/var/log/mysqld. log

Restart the MySQL database once and observe the error log.
[Root @ zabbixserver ~] # Service mysqld start
MySQL Daemon failed to start.
Starting mysqld: [FAILED]
[Root @ zabbixserver ~] # Cat/var/log/mysqld. log
140505 11:22:52 mysqld_safe Starting mysqld daemon with databases from/var/lib/mysql
140505 11:22:52 InnoDB: Initializing buffer pool, size = 8.0 M
140505 11:22:52 InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 2 2955725186
140505 11:22:52 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the. ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 2 2955745512
InnoDB: 1 transaction (s) which must be rolled back or cleaned up
InnoDB: in total 4 row operations to undo
InnoDB: Trx id counter is 0 43004160.
140505 11:22:52 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 19 20 21 22 23 24 26 26 28 29 30 31 32 33 34 35 36 38 39 40 41 42 43 44 45 46 48 49 50 51 53 54 55 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 1735848, file name./mysql-bin.000018
InnoDB: Starting in background the rollback of uncommitted transactions
140505 11:22:52 InnoDB: Rolling back trx with id 0 41354738, 4 rows to undo
140505 11:22:52 InnoDB: Started; log sequence number 2 2955745512
140505 11:22:52 [Note] Recovering after a crash using mysql-bin
140505 11:22:52 [ERROR] Error in Log_event: read_log_event (): 'read error', data_len: 990, event_type: 24
140505 11:22:52 [Note] Starting crash recovery...
140505 11:22:52 [Note] Crash recovery finished.
03:22:52 UTC-mysqld got signal 11;
This cocould be because you hit a bug. It is also possible that this binary
Or one of the libraries it was linked against is too upt, improperly built,
Or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
Diagnose the problem, but since we have already crashed,
Something is definitely wrong and this may fail.

Key_buffer_size = 8384512
Read_buffer_size = 131072
Max_used_connections = 0
Max_threads = 700
Thread_count = 0
Connection_count = 0
It is possible that mysqld cocould use up
Key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 1538661 K bytes of memory
Hope that's OK; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
Where mysqld died. If you see no messages after this, something went
Terribly wrong...
Stack_bottom = 0 thread_stack 0x40000
/Usr/libexec/mysqld (my_print_stacktrace + 0x29) [0x84f539]
/Usr/libexec/mysqld (handle_fatal_signal + 0x483) [0x6a3713]
/Lib64/libpthread. so.0 (+ 0xf500) [0x7ff1f5519500]
The manual page at contains
Information that shocould help you find out what is causing the crash.
140505 11:22:52 mysqld_safe mysqld from pid file/var/run/mysqld. pid ended
[Root @ zabbixserver ~] # Grep error/var/log/mysqld. log
140505 11:22:52 [ERROR] Error in Log_event: read_log_event (): 'read error', data_len: 990, event_type: 24
Or misconfigured. This error can also be caused by malfunctioning hardware.

Based on experience, check whether the disk space is sufficient. If you are in a hurry, you can only stop the binary log and start the service first. If you are not in a hurry, you can only resize or migrate the log to the hard disk. Of course, MySQL Cluster and Master/Slave databases need additional processing.