# The database is not running **URL:** \ **Category:** MySQL & MariaDB\ **Tags:** percona\ **Created:** [April 14, 2022, 4:23am UTC](https://forums.percona.com/t/the-database-is-not-running/15220 "2022-04-14T04:23:12Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![kdokdo](https://avatars.discourse-cdn.com/v4/letter/k/3be4f8/32.png) [@kdokdo](https://forums.percona.com/u/kdokdo)\ **Post date:** [April 14, 2022, 4:23am UTC](https://forums.percona.com/t/the-database-is-not-running/15220/1 "2022-04-14T04:23:12Z")
When I run mysql //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > Thu Apr 14 13:20:45 2022 PerconaFT recovery starting in env /var/lib/mysql/ > Thu Apr 14 13:20:45 2022 PerconaFT recovery scanning backward from 12564896439 > Thu Apr 14 13:20:45 2022 PerconaFT recovery bw\_end\_checkpoint at 12564891742 timestamp 1649903938270494 xid 12564891448 (bw\_newer) > Thu Apr 14 13:20:45 2022 PerconaFT recovery bw\_begin\_checkpoint at 12564891448 timestamp 1649903934833060 (bw\_between) > Thu Apr 14 13:20:45 2022 PerconaFT recovery turning around at begin checkpoint 12564891448 time 3437434 > Thu Apr 14 13:20:45 2022 PerconaFT recovery starts scanning forward to 12564896439 from 12564891448 left 4991 (fw\_between) > /home/buildbot/buildbot/build/mariadb-10.4.12/storage/tokudb/PerconaFT/ft/serialize/ft\_node-serialize.cc:1175:verify\_ftnode\_sub\_block - file[unknown], blocknum[733], stored\_xsum[1179653659] != actual\_xsum[148357199] > 0x7f6987d9cf00: BB250000000100000000007D1E2C060204000000D00C3DA90000000001000000050000000024650400B10700000AE0FCCA020079000000265A08000000000002 > 0x7f6987d9cf40: 0000000001B93C000000000000000000000000000000000000000000000000000062455226625621FC0001000000010000004D0059008600E600E6005B3131EB > 0x7f6987d9cf80: A788ECA1B45D20EC838CEB9494EC8AA4ED81AC20ED9CB4EB8C80EC9AA9207373642032ED858CEB9DBC20283234382C373430EC9B902FEC9AB0ECA3BCED8CA8EC > … > … > … > … > 0x7f6987daf1c0: 0000A6AC00007FB4000058BC000031C400000ACC0000E3D30000BCDB000095E300006EEB000047F3000020FB0000F9020100D20A0100AB120100841A01000000 > 0x7f6987daf200: 00001B165046 > /home/buildbot/buildbot/build/mariadb-10.4.12/storage/tokudb/PerconaFT/ft/serialize/ft\_node-serialize.cc:1394:deserialize\_ftnode\_partition - file[unknown], blocknum[733], verify\_ftnode\_sub\_block failed with -100015 > Checksum failure while reading node partition in file ./\_mqoo\_sql\_5d2\_700890\_main\_22064335d\_1\_1d\_B\_0.tokudb. > 220414 13:20:46 [ERROR] mysqld got signal 6 ; > This could be because you hit a bug. It is also possible that this binary > or one of the libraries it was linked against is corrupt, improperly built, > or misconfigured. This error can also be caused by malfunctioning hardware. > > To report this bug, see [MariaDB Community Bug Reporting - MariaDB Knowledge Base](https://mariadb.com/kb/en/reporting-bugs) > > 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. > > Server version: 10.4.12-MariaDB-1:10.4.12+maria~disco-log > key\_buffer\_size=16777216 > read\_buffer\_size=131072 > max\_used\_connections=0 > max\_threads=129 > thread\_count=5 > It is possible that mysqld could use up to > key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 684859 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 = 0x0 thread\_stack 0x30000 > /usr/sbin/mysqld(my\_print\_stacktrace+0x2e)[0x564aedb316de] > /usr/sbin/mysqld(handle\_fatal\_signal+0x54d)[0x564aed62722d] > /lib/x86\_64-linux-gnu/libpthread.so.0(+0x13f40)[0x7f69c12c0f40] > /lib/x86\_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f69c09d1ed7] > /lib/x86\_64-linux-gnu/libc.so.6(abort+0x121)[0x7f69c09b3535] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z23toku\_ftnode\_pf\_callbackPvS\_S\_iP11pair\_attr\_s+0xad2)[0x7f69c070a712] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z28toku\_deserialize\_ftnode\_fromi10blocknum\_sjPP6ftnodePP16ftnode\_disk\_dataP18ftnode\_fetch\_extra+0x8cc)[0x7f69c06f5c5c] > /usr/lib/mysql/plugin/ha\_tokudb.so(_Z26toku\_ftnode\_fetch\_callbackP9cachefileP6ctpairi10blocknum\_sjPPvS5\_P11pair\_attr\_sPiS4_+0x4c)[0x7f69c070a81c] > /usr/lib/mysql/plugin/ha\_tokudb.so(+0x101fe2)[0x7f69c071afe2] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z42toku\_cachetable\_get\_and\_pin\_with\_dep\_pairsP9cachefile10blocknum\_sjPPv25CACHETABLE\_WRITE\_CALLBACKPFiS0\_P6ctpairiS1\_jS3\_S3\_P11pair\_attr\_sPiS2\_EPFbS2\_S2\_EPFiS2\_S2\_S2\_iS8\_E14pair\_lock\_typeS2\_jPS6\_P16cachetable\_dirty+0x43a)[0x7f69c07239aa] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z30toku\_pin\_ftnode\_with\_dep\_nodesP2ft10blocknum\_sjP18ftnode\_fetch\_extra14pair\_lock\_typejPP6ftnodeS7\_b+0x128)[0x7f69c06a2318] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z15toku\_pin\_ftnodeP2ft10blocknum\_sjP18ftnode\_fetch\_extra14pair\_lock\_typePP6ftnodeb+0x19)[0x7f69c06a23b9] > /usr/lib/mysql/plugin/ha\_tokudb.so(+0xf3cbc)[0x7f69c070ccbc] > /usr/lib/mysql/plugin/ha\_tokudb.so(+0xf42ac)[0x7f69c070d2ac] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z20toku\_ft\_root\_put\_msgP2ftRK6ft\_msgP11txn\_gc\_info+0x423)[0x7f69c070de23] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z19toku\_ft\_send\_insertP9ft\_handleP10\_\_toku\_dbtS2\_P6XIDS\_S11ft\_msg\_typeP11txn\_gc\_info+0x3d)[0x7f69c070e56d] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z20toku\_ft\_maybe\_insertP9ft\_handleP10\_\_toku\_dbtS2\_P7tokutxnb10\_\_toku\_lsnb11ft\_msg\_type+0x21c)[0x7f69c070e79c] > /usr/lib/mysql/plugin/ha\_tokudb.so(+0xb04b2)[0x7f69c06c94b2] > /usr/lib/mysql/plugin/ha\_tokudb.so(\_Z14tokuft\_recoverP13\_\_toku\_db\_envPFvS0\_P7tokutxnEPFvS0\_P10cachetableEP10tokuloggerPKcSC\_PFiP9\_\_toku\_dbPK10\_\_toku\_dbtSH\_EPFiSE\_SH\_SH\_SH\_PFvSH\_PvESK\_EPFiSE\_SE\_P9DBT\_ARRAYSQ\_SH\_SH\_EPFiSE\_SE\_SQ\_SH\_SH\_Em+0x21e)[0x7f69c06ca8ce] > /usr/lib/mysql/plugin/ha\_tokudb.so(+0x130c51)[0x7f69c0749c51] > /usr/lib/mysql/plugin/ha\_tokudb.so(+0x59e32)[0x7f69c0672e32] > /usr/sbin/mysqld(\_Z24ha\_initialize\_handlertonP13st\_plugin\_int+0x68)[0x564aed62a5f8] > /usr/sbin/mysqld(+0x6b3b69)[0x564aed42eb69] > /usr/sbin/mysqld(\_Z11plugin\_initPiPPci+0xaaa)[0x564aed42ff9a] > /usr/sbin/mysqld(+0x5e396b)[0x564aed35e96b] > /usr/sbin/mysqld(\_Z11mysqld\_mainiPPc+0x426)[0x564aed363bd6] > /lib/x86\_64-linux-gnu/libc.so.6(\_\_libc\_start\_main+0xeb)[0x7f69c09b4b6b] > /usr/sbin/mysqld(\_start+0x2a)[0x564aed35777a] > The manual page at [http://dev.mysql.com/doc/mysql/en/crashing.html](http://dev.mysql.com/doc/mysql/en/crashing.html) contains > information that should help you find out what is causing the crash. > Writing a core file… > Working directory at /var/lib/mysql > Resource Limits: > Limit Soft Limit Hard Limit Units > Max cpu time unlimited unlimited seconds > Max file size unlimited unlimited bytes > Max data size unlimited unlimited bytes > Max stack size 8388608 unlimited bytes > Max core file size 0 unlimited bytes > Max resident set unlimited unlimited bytes > Max processes 257219 257219 processes > Max open files 16364 16364 files > Max locked memory 67108864 67108864 bytes > Max address space unlimited unlimited bytes > Max file locks unlimited unlimited locks > Max pending signals 257219 257219 signals > Max msgqueue size 819200 819200 bytes > Max nice priority 0 0 > Max realtime priority 0 0 > Max realtime timeout unlimited unlimited us > Core pattern: |/usr/share/apport/apport %p %s %c %d %P /////////////////////////////////////////////////////////////////////////////////////////////////////////////// It comes out as above. The data being written does not need to be (and its integrity not required to be guaranteed). I want to save past data. What is the fastest way to recover? ---
**Author:** ![kdokdo](https://avatars.discourse-cdn.com/v4/letter/k/3be4f8/32.png) [@kdokdo](https://forums.percona.com/u/kdokdo)\ **Post date:** [April 14, 2022, 4:29am UTC](https://forums.percona.com/t/the-database-is-not-running/15220/2 "2022-04-14T04:29:17Z")
I don’t need to recover data. `log000000052602.tokulog29` I moved the file to another location and ran it. > 2022-04-14 13:26:04 0 [ERROR] TokuDB: Recovery log is missing (persistent environment information is present) while looking for recovery log files in [/var/lib/mysql/] > > 2022-04-14 13:26:04 0 [ERROR] TokuDB unknown error 2 > 2022-04-14 13:26:04 0 [ERROR] Plugin ‘TokuDB’ init function returned error. > 2022-04-14 13:26:04 0 [ERROR] Plugin ‘TokuDB’ registration as a STORAGE ENGINE failed. > The above error occurred. ---
**Author:** ![Iori\_yagami](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/iori_yagami/32/6316_2.png) [@Iori\_yagami](https://forums.percona.com/u/Iori_yagami)\ **Post date:** [April 15, 2022, 1:25am UTC](https://forums.percona.com/t/the-database-is-not-running/15220/3 "2022-04-15T01:25:49Z")
You should configure innodb\_force\_recovery =1, save that parameter in my.cnf AND then, you should start the service with service mysql start or systemctl mysql start ---
**Author:** ![Peter](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/peter/32/2_2.png) [@Peter](https://forums.percona.com/u/Peter)\ **Post date:** [April 15, 2022, 1:01pm UTC](https://forums.percona.com/t/the-database-is-not-running/15220/4 "2022-04-15T13:01:43Z")
innodb\_force\_recovery would not do much as the crash is TokuDB/PerconaFT Related Do you have backups to recover from and do log forward recovery with binlogs - this is generally safest thing to do in this case Also note TokuDB is depreciated by Percona as such I would consider migrating to different storage engine (MyRocks is good alternative if you need high compression)