search

Tokutek / mongo

TokuMX is a high-performance, concurrent, compressing, drop-in replacement engine for MongoDB | Issue tracker: https://tokutek.atlassian.net/browse/MX/ |
http://www.tokutek.com/products/tokumx-for-mongodb/
704 stars 97 forks source link

Cannot connect to tokumx #1220

Open fydot opened 9 years ago

fydot commented 9 years ago

I run sudo service tokumx start, and Then I run 'sudo service tokumx status', it told me tokumx is running. BUT, I use telnet to connect to the port 27017, I got Connection refused. tokumx.log is below.

* SERVER RESTARTED *

Sat Mar 28 13:56:56.358 [initandlisten] TokuMX starting : pid=11126 port=27017 dbpath=/var/lib/tokumx 64-bit host=spamhunter01 Sat Mar 28 13:56:56.358 [initandlisten] TokuMX mongod server v2.0.0-mongodb-2.4.10, using TokuKV rev 668f1118593ba0976b6ec68768062f64d418ec83 Sat Mar 28 13:56:56.358 [initandlisten] git version: c7f2e017eb71d93ca51d5073eb1570f6c9ce0ba1 Sat Mar 28 13:56:56.358 [initandlisten] build info: Linux 217b861cf5d7 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 GNU/Linux BOOST_LIB_VERSION=1_49 Sat Mar 28 13:56:56.358 [initandlisten] options: { config: "/etc/tokumx.conf", dbpath: "/var/lib/tokumx", logappend: "true", logpath: "/var/log/tokumx/tokumx.log", pluginsDir: "/usr/lib/tokumx/plugins" } Sat Mar 28 13:56:56.375 [initandlisten] [tokumx] startup Sat Mar 28 13:56:56 2015 TokuFT recovery starting in env /var/lib/tokumx Sat Mar 28 13:56:56 2015 TokuFT recovery scanning backward from 384276973 Sat Mar 28 13:56:56 2015 TokuFT recovery bw_end_checkpoint at 384276973 timestamp 1427520260775675 xid 384126469 (bw_newer) Sat Mar 28 13:56:57 2015 TokuFT recovery bw_begin_checkpoint at 384126469 timestamp 1427520225970716 (bw_between) Sat Mar 28 13:56:57 2015 TokuFT recovery turning around at begin checkpoint 384126469 time 34804959 Sat Mar 28 13:56:57 2015 TokuFT recovery starts scanning forward to 384276973 from 384126469 left 150504 (fw_between)

herrsebi commented 9 years ago

I'm seeing the same thing on a tokumx after a crash. any updates?

fydot commented 9 years ago

I had to delete all my db data, and restart then.

herrsebi commented 9 years ago

That's rather unpleasant... Our server came up after a couple of hours. I'll post a separate issue as there seems to be an underlying ydb bug...

prohaska7 commented 9 years ago

TokuDB (the fractal tree engine for MySQL) uses the same fractal tree code as TokuMX. We have long crash recovery times in TokuDB caused by the existence of big transactions. Big transactions have big rollback logs that will take a long time to unwind. Unfortunately, there is no visibility into the progress of handling a big transaction rollback log during crash recovery in TokuMX. Do you have any big transactions running in your application?