Thanks, I did now. However it failed miserably.
It completed successfully on server A as destination and as source, however only after I created the table with all the correlating column families (specified by "--new.name=new_table_name"). Without that step being done manually it failed as well. When running: hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=serverB:2181:/hbase table_name It failed, regardless whether I created the table with the same name and column families, or a new table and specified 'new.name'. Would very much appreciate any additional feedback. Thanks! Tom On Wed, Sep 7, 2011 at 6:03 PM, Doug Meil <[email protected]>wrote: > > Hi there- > > Have you tried this? > > http://hbase.apache.org/book.html#copytable > > It's the Java invocation of the copy-table function (without the ruby) > > > > On 9/7/11 8:29 PM, "Tom Goren" <[email protected]> wrote: > > >So I have read http://blog.sematext.com/2011/03/11/hbase-backup-options/ > > > >The built-in solution, namely the 'Export' and 'Import' classes are > >relatively straight forward to use, however, the exports include the data > >alone, and nothing in regards to the table description (column families, > >versioning etc.). > > > >Manually creating the table seems wrong to me, and parsing the output of > >'describe table_name' seems like something that someone must have done > >before me. > > > >There is this: > >http://svn.apache.org/repos/asf/hbase/trunk/bin/copy_table.rb > >But surely there is something nicer? > > > >Is there an all encompassing solution that I am unaware of? > > > >What is the basic correlating option to: > > > >mysqldump db_name table_name > file > >mysql db_name < file > > > >Or, if this is too Utopian in an hbase world, what is the next best thing? > > > >Thanks. > >Tom > >
