New Message: Re: Databases corrupting

[webmaster at userland.com]

A new message was posted:

Address: http://frontier.userland.com/discuss/msgReader$14086

By: Robert Cassidy (rmcassid at uci.edu)

Ah, splendid. I'll walk through your script and work it into my process.

I have recurring corruption in the root. I have a maintentance script which does a decent job of completely building out a new root file, drilling down through the accounts and copying bits over as it determines that they're okay. I must say, doing that without crashing Frontier is dicey when it happens. That leaves me with a totally rebuilt root file that I can make sure is compacted and good and then trade back in. I used to have to do that one a year, then once every few months, and I'm not at my 3rd time in a week. Since I haven't added a stitch of code anywhere in ages, I have to conclude that I've reached some kind of inflection point on traffic/writes/etc.

A heavy day for me is 12,000 table writes to the membership group. It's not a lot of data, but it's a lot of transactions (relatively speaking).

During a data import, when I walk through user accounts alphabetically, I'll find one of the new tables is corrupted - say down in the 'G' accounts. Every table added after that point will be similarly corrupted, so the problem is almost certainly happening when the data is being appended, and somehow the block pointers into the appended entries is getting wholloped. Bad offset or some such.

I can do the big updates at my discretion and lock everything down for the 15 minutes that it takes, compact the account file, deal with the backups, etc. etc. but was really just looking for a good process to implement.

I'll have to run out and buy a cactus, though. Does the cactus need to be in the office, or can I do it at home? I'm thinking there's got to be an office policy that I might be breaking...

This is a Manila site.. http://manila.userland.com/.