0

My MemcacheQ is started with:

memcacheq -d -r -H /db/baamboo -N -R -L 2048 -T 300 -l 192.168.6.29 -p 22211 -u memcacheq -t 8 -m 512 -P /var/run/baamboo.pid -v

It's eating the hard disk space. Found this topic by Google but I have checked the help page: the -e option has other meaning:

-e <num>      percent of the pages in the cache that should be clean, default is 60%

As mark mentioned in the above link, I also clean up the log files with db_archive -a -h ... | xargs rm -f (memcacheq has -R option to do it automatically). But after that, the __dbq.* file seems not corresponding to the log files. So, the db_stat claims:

# db_stat -d BBKeyword
db_stat: PANIC: fatal region error detected; run recovery
...

something like this: http://forums.oracle.com/forums/thread.jspa?threadID=2146996&tstart=15

I cannot give you the output exactly, because db_stat run forever and seems to hang.

I have a lot of the __dbq.* files:

# ls -1 __dbq.* | wc -l
11849

The size of the single db file is 4K * 16 * 1024 = 64MB, so the total size is 743GB.

Berkeley DB 4.7.25


UPDATE 1

# db_stat -d BBKeyword
Wed Aug 17 11:34:59 2011    Local time
db_stat: PANIC: fatal region error detected; run recovery
db_stat: PANIC: fatal region error detected; run recovery
db_stat: close: DB_RUNRECOVERY: Fatal error, run database recovery
db_stat: File handles still open at environment close
db_stat: Open file handle: BBKeyword
db_stat: Open file handle: queue.list
db_stat: Open file handle: BBUpdateViewQt
db_stat: Open file handle: BBUpdateViewVn
db_stat: Open file handle: BBUpdateViewYt
db_stat: Open file handle: log.0000083311
db_stat: Open file handle: ./__dbq.BBKeyword.285
db_stat: Open file handle: ./__dbq.BBKeyword.286
db_stat: Open file handle: ./__dbq.BBKeyword.287
db_stat: Open file handle: ./__dbq.BBKeyword.288
db_stat: PANIC: fatal region error detected; run recovery
db_stat: dbenv->close: DB_RUNRECOVERY: Fatal error, run database recovery

db_verify give a lots of bad page number:

...
db_verify: Page 16379: bad page number 4734972
db_verify: Page 16380: bad page number 4734973
db_verify: Page 16381: bad page number 4734974
db_verify: Page 16382: bad page number 4734975
db_verify: Page 16383: bad page number 4734976
db_verify: __dbq.BBKeyword.288: DB_VERIFY_BAD: Database verification failed

So, I stop the memcacheq and run db_recover:

# db_recover -v -h /data/memcacheq/db/baamboo/
Finding last valid log LSN: file: 83311 offset 1795753
Recovery starting from [83310][1429052]
Recovery complete at Wed Aug 17 12:03:09 2011
Maximum transaction ID 8000ac4f Recovery checkpoint [83311][1796460]

and check again with db_verify:

# db_verify -h . __dbq.BBKeyword.288
db_verify: Page 0: metadata page corrupted
db_verify: Page 0: could not check metadata page
db_verify: __dbq.BBKeyword.288: DB_VERIFY_BAD: Database verification failed

1 Answer 1

0

It seems you are trying to use verify on a region file instead of on the database file. See this thread on OTN.

1
  • Thanks, through Google, I also read this thread, but it's not really my problem. My problem is the same as Steve Chu's (memcacheq's author) which has been raised here.
    – quanta
    Aug 22, 2011 at 14:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .