With the versioning of HBase, the old data is not overwritten so that is not conclusive proof of the problem. Those tables you paste hold state data, and on restart it is overwritten with new records. I have copied the hbase tables from one cluster to the other and restarted it successfully as well.
I'm afraid we are going to need more context to help debug this issue. What happens is during a start, the old server assignments are noticed to be bad (since there is no record of that server existing anymore) and new assignments are made and recorded in ROOT. Another issue could be that your table is not entirely online. Try > enable "table_name" at the hbase shell and see if that helps. -ryan On Tue, Mar 16, 2010 at 5:31 PM, Jinsong Hu <[email protected]> wrote: > Here is the content of the binary file > /hbase/-ROOT-/70236052/info/110463219710538426. you can see the IP address > 10.110.24.55 inside. > > This shows the hbase is saving the IP address of my cluster into the ROOT > data file. when I run the scan command > under shell , the log says it was trying to connect to 10.110.24.xx > machines. > > Jimmy > > > > DATABLK*# ? .META.,,1 inforegioninfo &?Ph= .META.,,1 .META. IS_ROOT > false IS_META true MEMSTORE_FLUSHSIZE 16384 historian BLOOMFILTER > false COMPRESSION NONE VERSIONS2147483647 TTL 604800 BLOCKSIZE 8192 > IN_MEMORY false > BLOCKCACHE false info BLOOMFILTER false COMPRESSION NONE VERSIONS 10 TTL > 2147483647 BLOCKSIZE 8192 IN_MEMORY false > BLOCKCACHE false I3 .META.,,1 infoserver 'J? ? 10.110.24.88:60020 > .META.,,1 infoserver '0?}? 10.110.24.85:60020 .META.,,1 infoserver '0?{? > 10.110.24.56:60020 .META.,,1 infoserver ' &^? 10.110.24.54:60020 > .META.,,1 infoserver ' #?? 10.110.24.55:60020 .META.,,1 infoserver ' ?? > 10.110.24.54:60020 .META.,,1 infoserver ' B?? 10.110.24.56:60020 > .META.,,1 infoserver ' R?z 10.110.24.55:60020 .META.,,1 infoserver &?NN? > 10.110.24.54:60020 .META.,,1 infoserver &?S?4 10.110.24.55:60020( > .META.,,1 infoserverstartcode 'J? ? 'J? ( .META.,,1 > infoserverstartcode '0?}? '0?V?( .META.,,1 infoserverstartcode '0?{? ' > &?C( .META.,,1 infoserverstartcode ' &^? ' &5?( .META.,,1 > infoserverstartcode ' #?? ' ?( .META.,,1 infoserverstartcode ' ?? ' > >> >> ( .META.,,1 infoserverstartcode ' B?? ' Q??( .META.,,1 >> infoserverstartcode ' R?z ' Q??( .META.,,1 infoserverstartcode >> &?NN? &?N&G( .META.,,1 infoserverstartcode &?S?4 &?R?? >> MAJOR_COMPACTION_KEY ? MAX_SEQ_ID_KEY N ? hfile.AVG_KEY_LEN # >> hfile.AVG_VALUE_LEN ! hfile.COMPARATOR >> 2org.apache.hadoop.hbase.KeyValue$RootKeyComparatorhfile.LASTKEY ( >> .META.,,1 infoserverstartcode &?S?4 IDXBLK)+ `# .META.,,1 inforegioninfo >> &?Ph= TRABLK"$ ` D ` > > > > > -------------------------------------------------- > From: "Stack" <[email protected]> > Sent: Tuesday, March 16, 2010 5:15 PM > To: <[email protected]> > Subject: Re: can't read all hbase tables after hbase cluster IP netmask > change > >> On Tue, Mar 16, 2010 at 5:02 PM, Jinsong Hu <[email protected]> >> wrote: >>> >>> yes, the dns name resolution is working file. it is not dns issue. it >>> looks >>> I have to regenerate my hbase data again >>> from my raw data. >>> >> >> We don't write machine names or ips into the data. You can take your >> data, copy it to another cluster altogether and it'll serve it without >> modification. >> >>> >>> Another observation I have is that if one region server dies, the region >>> served by that server won't be accessible any >>> more because of this binding to IP. the only way to resolve this is to >>> build >>> a new machine that takes over that IP and >>> add it to cluster. >>> >> >> Your premise is incorrect. The above does not hold at all. >> >> St.Ack >> >
