Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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
share|improve this question

1 Answer 1

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

share|improve this answer
    
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 '11 at 14:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.