On Thu, Jan 27, 2011 at 9:12 PM, Chris Howe <[email protected]> wrote: > Howdy, >
Howdy back. See in below. > ERROR: Region test,,1296067171940.0200bfe58a9e9fadf8ebfa523c47332f. found on > server 10.101.45.82:60020 but is listed in META to be on server ip-10-117-86- > 81.ec2.internal:60020. Could this region have been deployed on this server before you ran add_table? Or 'test' was a completely new addition. If the latter, then this is a new spin. add_table.rb effectively just edits .META. Somehow, the assignment of the just-added regions went awry. Can you grep this region name in your master log? You might be able to make some sense of what happened; was the region assigned two places? > Now, this table is not at all important to me. However, if I drop it, these > two > regions end up surviving, and hbck gives me a different inconsistency message > (... not listed in META...). > Yeah. Disable and drop are going by the content in .META. Thats supposed to be the authority. You could restart these individual regionservers (or restart cluster)? That'd clean up the mess. > Is there a way that I can just zot these regions out and make hbase hbck happy > again? I do have a fair amount of data in some other tables that I would > rather > not lose. > Not in 0.89.x. I believe you can send a direct close region to the individual servers in 0.90 (I'd have to check) so you don't have to do full regionserver restart. > Also, does any one have any pointers for getting add_table.rb to work > properly? > Whenever I run it, it creates the table schema ok, but it seems to miss the > mark > on getting the regions registered. They either get assigned to the wrong > regionservers or they dont get assigned to anything. In either case, when I > do a > scan of the table, I come up with nothing. > How did you make the table? Was it with bulk loader? St.Ack
