OK got it to work. It seems that the problem was in a non-related network issue.
The CopyTable ran with the syntax I specified earlier. Thanks! Tom On Thu, Sep 8, 2011 at 5:14 AM, Tom Goren <t...@tomgoren.com> wrote: > J-D, thanks a lot. > However I was not able to understand the correct usage from your > explanation. I was only able to use the tool to copy a table from one server > to itself (w/new.name or w/o) as I stated earlier. > > In addition, according to > http://ofps.oreilly.com/titles/9781449396107/clusteradmin.html > > Another supplied tool is *CopyTable*, which is primarily designed to >> bootstrap cluster replication. You can use is to make a copy of an existing >> table from the master cluster to the slave one > > > Now, in my case, the two 'clusters' (pseudo-distributed) are entirely > independent from from another. > Could this be my problem perhaps? > > Again, I will state my goal: copying tables from a so-called production > server, to a so called development server. Thus as is implied, these > machines are mutually exclusive, however are accessible network wise in both > directions. > > From what I gather and my experience has shown till now, the nearest option > is manual or scripted creation of the tables, and then copying the data with > the export tool via hdfs -> localfiles -> scp -> hdfs_on_new_server -> > import tool (this is as per these instructions: > http://www.sethcall.com/blog/2010/04/10/how-to-export-and-import-an-hbase-table/ > more > or less) > > Surely there is something better? > > Thanks in advance, your help is greatly appreciated! > Tom > > On Wed, Sep 7, 2011 at 8:07 PM, Jean-Daniel Cryans <jdcry...@apache.org>wrote: > >> Inline. >> >> J-D >> >> On Wed, Sep 7, 2011 at 8:02 PM, Tom Goren <t...@tomgoren.com> wrote: >> > 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. >> >> That's currently how it works, eg it doesn't create the table for you. >> >> > >> > When running: >> > >> > hbase org.apache.hadoop.hbase.mapreduce.CopyTable >> > --peer.adr=serverB:2181:/hbase table_name >> >> That's not the format, the last part of the peer address is >> zookeeper.znode.parent which by default is /hbase (that's the root >> znode where you can find the bootstrap information to contact hbase, >> not a table name). >> > >
