The MySQL restart process cannot be underestimated.

The MySQL restart process cannot be underestimated.

The restart of the database seems to be very simple and has no technical skills. This is what I said before. This sentence is simply a pain point of mine. This kind of activity is so technical that people need to pay attention to too many things and need to do a lot of preliminary homework.
Some time ago, a hardware problem occurred and a hardware error was found on a mysql slave database server. Because the slave database server was faulty, it was not very anxious to handle the problem, if you find that the slave Database hardware problem cannot be fixed, apply for a new machine to try again. Preliminary analysis of the problem is as follows:

However, when preparing to build a slave database online, we found that binlog was not enabled in the master database. Therefore, we can see that the slave database is actually an independent master database, A real master database server has been running bare for a long time. In fact, it has not been removed from the database. If you think about this situation, it will make people feel cooler and you need to fix this problem quickly. The problem found at this time is as follows:

Therefore, we made a simple assessment and found that there is another mysql server that has not enabled binlog, and it has not been a slave database server. Therefore, we need to re-build two slave databases to solve this problem. When binlog is enabled, the mysql database needs to be restarted. Therefore, the task naturally becomes to restart the two mysql master database servers in a specific maintenance window, and then build a slave database on this basis.
The problem is as follows:

The binlog mode for enabling mysql is similar to the archive mode for Oracle. You can say that this process is complicated, but it is actually re-initialized during the restart process.
We have determined the detailed time range, operation steps, and coordination with other teams. It seems that the work has been fully done.
Dba is not so light-hearted. Apart from enabling binlog, I also asked my mysql colleagues to check what other parameters can be optimized. Therefore, it seems that restarting this job is not a disadvantage, by the way, you can also tune it.
The plan is as follows:

Everything is ready. During the several days after the restart, a remote backup is also made for emergency purposes.
There is no need to pay special attention to this restart, or even consider whether to set crontab to restart or use an automated script to build a slave database. Because I am a newbie to mysql, I still find out how to open the door.
The plan is this morning, and the agreement with the system is about 5 o'clock in the morning. When I woke up in the middle of the night, I was afraid of having slept over my head. Then I woke up again, and finally I felt like I was always waking up to watch my cell phone. The phone call was too loud to affect my family, simply holding the quilt to go to bed in the living room, the result was sleeping at half past five, finally the phone came, began to work.
First, use show processlist to check whether the connection is closed. Check whether the connection is closed. Finally, stop the mysql database and find out why the pid file is missing.
#/Etc/init. d/mysql stop
MySQL (Percona Server) PID file cocould not be found! [FAILED]
# Ll/home/mysql. pid
Ls:/home/mysql. pid: No such file or directory
Then you have to forge a pid file and manually enter the mysqld process number in it.
Then I tried again, and there was no problem. It was just a small false surprise.
After stopping the service, start to replace the parameter configuration and restart the service. Everything is done naturally. I also want to go back to bed for a while and then build the slave database.
My colleague suddenly said that there were many warnings in error. log.
Some of them are connection problems. The content is as follows:
07:57:41 26782 [Warning] Aborted connection 1417 to db: 'unconnected' user: 'unauthenticated 'host: 'test _ app_128.100' (Got an error reading communication pa
Ckets)
07:57:47 26782 [Warning] Aborted connection 1418 to db: 'unconnected' user: 'unauthenticated 'host: 'test _ app_4.176 '(Got an error reading communication pack
Ets)
This part is initially suspected to be caused by mysql parameter settings, but only log_bin, log_bin_index, and cache_size parameters are changed. The parameters of the two mysql master databases are modified in the same way. It is worth mentioning that the parameter values of one mysql database are 5.6 and the other is 5.5. If the parameter values are caused by problems in the version, that is also far-fetched. The other mysql master database also has a warning, but there are very few warnings.
Many factors have also been checked for this problem. The error information has not been returned from the application. We are also testing this problem to eliminate the cause of incorrect user name and password and slow query, it is initially suspected that the connection is not completely closed at the application end.
The other part is about mysql Data dictionary.
18:19:51 25011 [Warning] InnoDB: Cannot open table mysql/innodb_table_stats from the internal data dictionary of InnoDB though. frm file for the table exists. see http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
It was strange to see this error at first, but this type of helpless error already exists one year ago. I just restarted the mysql database. In fact, I should fix this problem along with it, however, it does not attract much attention. This type of restoration still requires rebuilding these data dictionary tables, and ibdata may need to be modified. Restarting the dictionary also requires matching the application to find a suitable window.
So through this case, we can see how technical the restart is, And the restart process plays a crucial role. We need to fully investigate the problem and check whether there are any issues left over and solve them together, we also need to constantly confirm other unclear issues, and gradually deepen the process. We should fill in all the pitfalls during the restart and smooth the process. It will be convenient for everyone in the future. This is also the starting point of standardization, so that it can be implemented.

This article permanently updates the link address: