hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Goren <...@tomgoren.com>
Subject Re: Copying tables from one server to another
Date Thu, 08 Sep 2011 12:14:16 GMT
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 <jdcryans@apache.org>wrote:

> Inline.
>
> J-D
>
> On Wed, Sep 7, 2011 at 8:02 PM, Tom Goren <tom@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).
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message