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). >