Features of the fall of InnoDB in central Russia
Having decided to somehow check the operation of my site for the “guests”, without thinking twice, I pressed [EXIT] and started the check.
When the check was over - I could not log in back.
Requests update just did not apply.
Having conjured a dozen minutes, I, without hesitation, clicked on the server reset
Thank God that the action took place on the local version of the site.
Reset is software restart of the server OS.
After a couple of seconds, I was again on the entry form, which had just said that I had successfully logged in and threw at the main page, where I was told that I was a “guest”.
Now she told me that the table with the authorization data is corpulent and let's do it as a dude.
But, as you know (?), InnoDB is so easy not to repair, and you will not kill the table with the input data (updated each time) in MyISAM format - there will be one big lock.
Binlogs and so on and so on, on my working laptop, are not maintained.
Well, I demolished the table nafig and then filled in its place a dump from the server ...
And he did not get up ...
Mysql was rebooted again ... And the dump didn't get up ... (error 121)
After which the table was flooded under a different name ...
It was yesterday.
Today, the login form again began to not take me ...
Winds at this moment caught the next update and required a reboot. What was done.
')
Well, after the restart, all InnoDB tables of the required database do not work.
Cannot be fixed (?)
At the moment, three months old backup is flooded, and at night you have to download a 800 meter dump from the server ...
Before the "death" muscle log scored structures of the form
Unfortunately, this is not the first time my InnoDB is falling.
And if more precisely - the second.
The first time they fell like a server. In the logs, too, he wrote that he constantly does rollback trades.
After that, all the bases fell, their own binlogs did not eat muscle. Only reinstallation helped.
Fortunately, tama dumps every day + important data on email are duplicated.
In general, I, from my side, wept, and really looking forward to the community of tips and decisions on how to create the appearance of InnoDB reliability and not stay at the broken trough for those 10 minutes, when “if there is absolutely Khan” a dump is filled.
If he is.
When the check was over - I could not log in back.
Requests update just did not apply.
Having conjured a dozen minutes, I, without hesitation, clicked on the server reset
Thank God that the action took place on the local version of the site.
Reset is software restart of the server OS.
After a couple of seconds, I was again on the entry form, which had just said that I had successfully logged in and threw at the main page, where I was told that I was a “guest”.
Now she told me that the table with the authorization data is corpulent and let's do it as a dude.
But, as you know (?), InnoDB is so easy not to repair, and you will not kill the table with the input data (updated each time) in MyISAM format - there will be one big lock.
Binlogs and so on and so on, on my working laptop, are not maintained.
Well, I demolished the table nafig and then filled in its place a dump from the server ...
And he did not get up ...
InnoDB: drop queue.
080609 13:39:24 InnoDB: Error: table `kusers` already exists in InnoDB internal
InnoDB: data dictionary. Have you deleted the .frm file
Mysql was rebooted again ... And the dump didn't get up ... (error 121)
After which the table was flooded under a different name ...
It was yesterday.
Today, the login form again began to not take me ...
Winds at this moment caught the next update and required a reboot. What was done.
')
Well, after the restart, all InnoDB tables of the required database do not work.
Cannot be fixed (?)
At the moment, three months old backup is flooded, and at night you have to download a 800 meter dump from the server ...
Before the "death" muscle log scored structures of the form
080606 17:42:53 [Warning] MySQL InnoDB transaction. 7 row modifications will roll back.
080606 17:42:53 InnoDB: Error: MySQL is freeing a thd
InnoDB: though trx-> n_mysql_tables_in_use is 1
InnoDB: and trx-> mysql_n_tables_locked is 7.
TRANSACTION 0 3793293, not started, OS thread id 4056
mysql tables in use 1, locked 7
MySQL thread id 2045, query id 57959 localhost 127.0.0.1 root
len 808; hex 065c6e051c9086000c00000001000000dc3e4948030000000100000001000000000000008…
asc \ n ђ †>> IH Ќ9 äääЋ 99 = H + R їЏ Pї¤ ¤ › W F 'ЂM @H! @ †! ј9 'Џ Ђ! € 9 @y; Ђ! Ђ! q8 € $ "Ђ" "T„ „¤„ "„ „4;„ 8; „T;„; „; 0“;
Unfortunately, this is not the first time my InnoDB is falling.
And if more precisely - the second.
The first time they fell like a server. In the logs, too, he wrote that he constantly does rollback trades.
After that, all the bases fell, their own binlogs did not eat muscle. Only reinstallation helped.
Fortunately, tama dumps every day + important data on email are duplicated.
In general, I, from my side, wept, and really looking forward to the community of tips and decisions on how to create the appearance of InnoDB reliability and not stay at the broken trough for those 10 minutes, when “if there is absolutely Khan” a dump is filled.
If he is.
Source: https://habr.com/ru/post/27107/
All Articles