On Thu, Jul 7, 2011 at 2:39 AM, Mat Hofschen <[email protected]> wrote: > looking at the old 0.20.4 cluster the parent region is not written to any > more. (no data on filesystem) In META table I can not identify that this > parent region is offlined though. Where can I find that key? Why is the > region not being written to any more if there is no offline flag set? >
Dump the meta region: echo 'scan ".META."' | ./bin/hbase shell &> /tmp/meta.txt Then look in the outputted file for the parent region (has same start key as the first daughter and same end key as second daughter). Look through the output for the 'offline' and 'split' attributes. > So by copying over the data to new cloud and using add_table script the > information that the region was offlined is lost. I guess this is one of the > problems of using copy on dfs level. > The new cluster is therefore inconsitent at this point with data written to > the parent region and not the child regions. > When you do add_table.rb, you then disable and then enable the table to get it online? Or how do you get the regions assigned? Restart? Maybe this is the issue (enable/disable changed in how it works between 0.20 and 0.90 -- the offline attribute is not relied on as much). Its odd that your parent region over in 0.20.4 has no data. It should have a bunch (daughters reference the data up in parent until they are done with it... the data in parent is not deleted until the parent itself if deleted). Is there data under the daughters in the filesystem? You tried merging the daughter regions and then merging the resultant region with the parent region? > Is there a way to reuse the META table from old cloud and avoid using the > add_table script? > You could copy the .META. from old cluster. St.Ack
