Честито! 🙂

Може би имате сериозен проблем с mysql, който може да се степенува в скалата от 1 до 6, където 6 не е отлечен 🙂 а точно обратното. (ще стане ясно защо малко по-долу)

Наскоро се сблъсках точно с този проблем при стартирането на база данни с InnoDB таблици. При мен проблема се оказа в следствие с неточност при записването на логовете в “ib_logfile”. Проблема може да е в следсвие на неправилно спиране на сървъра или проблем с хард диска, или пък нещо различно, което е свързано с процеса за писане във файла като цяло. Аз лично смятам, че е заради принудително спиране на сървъра, тъй като проблема се яви на Development машина, която като цяло бива спирана от време на време по този начин.

Неприятното в случая при мен е, че на машината има стотици бази данни, като почти във всички има InnoDB таблици и беше трудно да прегледам всяка една по една за несъответствия. Така, че моя съвет е да се опитате да се сетите кои са последните бази, в които са правени промени в схемата на таблиците. Аз лично извадих късмет и втората база, която проверих се оказа виновника.

Разбира се, за да можете да гледате базите трябва да стартирате първо MySQL сървъра, като точно тук идва 6 степенната скала на проблем.
А именно можете да използвате “innodb_force_recovery“, което приема стойности от 1 до 6, и можете да добавите реда в началото на my.ini файла при стартиране

  • Mode 1 – Doesn’t crash MySQL when it sees a corrupt page
  • Mode 2 – Doesn’t run background operations
  • Mode 3 – Doesn’t attempt to roll back transactions
  • Mode 4 – Doesn’t calculate stats or apply stored/buffered changes
  • Mode 5 – Doesn’t look at the undo logs during start-up
  • Mode 6 – Doesn’t roll-forward from the redo logs (ib_logfiles) during start-up

!!! Важно е да знаете, че трябва да направите backup на всичките таблици, както и на ibdata ib_logfile, както и други файловете с логове и data файлове, които се намират в директорията /data на mysql. Особено, ако стигнете до стойности 4, 5, 6, които могат да унищожат почти безвъзвратно данните ви. Също така имайте предвид, че 4,5,6 активират Read Only Mode и можете само да четете данните.
!!! Много важно е да имате предвид, че трябва да започнете с най-малкото число 1 и да опитате да стартирате, ако не успява да увеличавате с +1 и така нататък!

Аз успях да стартирам със стойност 6, успях да намеря коя база причинява проблема (при опит за отваряне и repair на таблици MySQL сървъра crash-ваше). За жалост не успях да спася данните от базата, тъй като при всеки опит за итерация MySQL-а crash-ваше, но някак успях да drop-всички таблици и след това да изтрия директорията на базата в /data директорията. Не успях да Drop-на таблицата с команда в MySQL, отново поради crash-ване на сървъра при всеки опит. Определено е важно да се правят регулярни backup-и за въстанояване при такива ситуации! 🙂

След като затрих директорията смених имената на ib_logfile0 и ib_logfile1 съответно на ib_logfile0_bak и ib_logfile1_bak, за да се прегенерират отново. Имайте предвид, че ibdata файла трябва да бъде пазен много, защото без него не можете да възстановите данните. Махнах innodb_force_recovery от my.ini и стартирах наново сървъра. Логовете се генерираха и всичко изглеждаше да работи. Върнах от backup базата, която се наложи за затрия грубо и си “отворих бира” след като няколко часа четене и ръчкане бяха загубени :).

Не твърдя, че решението ми е приложимо за production сървъри, поради затриването на данни, за това ще приложа малко връзки към решения, на които се натъкнах при борбата с проблема, ако могат да ви бъдат полезни:
https://twindb.com/recover-corrupt-mysql-database/

https://twindb.com/repair-corrupted-innodb-table-with-corruption-in-secondary-index/

https://www.percona.com/forums/questions-discussions/mysql-and-percona-server/11217-corrupted-innodb-table-crashing-mysql-instance-how-to-recover-table

http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html

https://forums.cpanel.net/threads/innodb-corruption-repair-guide.418722/

https://launchpad.net/mydumper – ако искате да dump-ите много бази едновременно докато сте влезнали в Mode 6 и сте решили да преинсталирате целия сървър

 

Прилагам и малко от логовете, които се случваха в процеса на ръчкане:

Когато MySQL отказва да стартира въобще:
2015-08-24 15:39:17 8376 [Note] Plugin ‘FEDERATED’ is disabled.
2015-08-24 15:39:17 8376 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-08-24 15:39:17 8376 [Note] InnoDB: The InnoDB memory heap is disabled
2015-08-24 15:39:17 8376 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-08-24 15:39:17 8376 [Note] InnoDB: Memory barrier is not used
2015-08-24 15:39:17 8376 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-08-24 15:39:17 8376 [Note] InnoDB: Not using CPU crc32 instructions
2015-08-24 15:39:17 8376 [Note] InnoDB: Initializing buffer pool, size = 32.0M
2015-08-24 15:39:17 8376 [Note] InnoDB: Completed initialization of buffer pool
2015-08-24 15:39:17 8376 [Note] InnoDB: Highest supported file format is Barracuda.
2015-08-24 15:39:17 8376 [Note] InnoDB: The log sequence numbers 2254979312 and 2254979312 in ibdata files do not match the log sequence number 4797004440 in the ib_logfiles!
2015-08-24 15:39:17 8376 [Note] InnoDB: Database was not shutdown normally!
2015-08-24 15:39:17 8376 [Note] InnoDB: Starting crash recovery.
2015-08-24 15:39:17 8376 [Note] InnoDB: Reading tablespace information from the .ibd files…
2015-08-24 15:39:17 8376 [ERROR] InnoDB: File (unknown): ‘read’ returned OS error 0. Cannot continue operation

Когато стартира с активиран innodb_force_recovery = 6:
2015-08-24 15:47:19 7984 [Note] Plugin ‘FEDERATED’ is disabled.
2015-08-24 15:47:19 7984 [Note] InnoDB: Started in read only mode
2015-08-24 15:47:19 7984 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-08-24 15:47:19 7984 [Note] InnoDB: The InnoDB memory heap is disabled
2015-08-24 15:47:19 7984 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-08-24 15:47:19 7984 [Note] InnoDB: Memory barrier is not used
2015-08-24 15:47:19 7984 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-08-24 15:47:19 7984 [Note] InnoDB: Not using CPU crc32 instructions
2015-08-24 15:47:19 7984 [Note] InnoDB: Disabling background IO write threads.
2015-08-24 15:47:19 7984 [Note] InnoDB: Initializing buffer pool, size = 32.0M
2015-08-24 15:47:19 7984 [Note] InnoDB: Completed initialization of buffer pool
2015-08-24 15:47:19 7984 [Note] InnoDB: Highest supported file format is Barracuda.
2015-08-24 15:47:19 7984 [Note] InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on, skipping log redo
2015-08-24 15:47:19 7984 [Note] InnoDB: 5.6.24 started; log sequence number 0
2015-08-24 15:47:19 7984 [Note] InnoDB: !!! innodb_force_recovery is set to 6 !!!

Когато прегенерира лог файловете за всяка база се генерира следното:
2015-08-24 15:56:53 6812 [Note] InnoDB: 5.6.24 started; log sequence number 2254979596
2015-08-24 15:56:53 6812 [Note] Server hostname (bind-address): ‘*’; port: 3306
2015-08-24 15:56:53 dcc InnoDB: Error: page 29070 log sequence number 4796820375
InnoDB: is in the future! Current system log sequence number 2254979606.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.

Leave a Reply

Your email address will not be published. Required fields are marked *