It turned out our fs.defaultFS was in hdfs-site.xml and not core-site.xml
This makes sense since the application manager was dumping the job
resources onto its local FS, also hdfs dfs -ls / was returning the local
filesystem on each node.
Moving this property to core-site.xml and restarting dfs a
Anyone have any advice on this? I'm going to cross post to the hadoop users
group since this seems to be a YARN related issue
Best,
The dfs test we ran spawned a m/r job that functioned fine. It seemed like
the copytable m/r job could not localize the needed the jars from the
application master. Seems like a configuration oversight but having trouble
finding it.
Thank you,
Iain
On Sep 26, 2014 6:14 PM, "Elliott Clark" wrote:
Do any map-reduce jobs work on this cluster ?
On Fri, Sep 26, 2014 at 5:13 PM, iain wright wrote:
> Forgot to include the actual copy table command:
> [hbase@master2 bin]$ ./hbase org.apache.hadoop.hbase.mapreduce.CopyTable
> --starttime=1409128964 --peer.adr=master0.hbasex1.test.cloud.domain.tv
Forgot to include the actual copy table command:
[hbase@master2 bin]$ ./hbase org.apache.hadoop.hbase.mapreduce.CopyTable
--starttime=1409128964 --peer.adr=master0.hbasex1.test.cloud.domain.tv,
master1.hbasex1.test.cloud.v.tv,master2.hbasex1.test.cloud.domain.tv:2181:/hbase
moderation
Replication
Hi folks,
I'm having trouble using copyTable to seed an existing tables data to a
replication peer. Surely its an oversight in configuration on our part, but
I've scoured the web and doc's for a couple days now.
We have been able to run these jobs with success (perhaps they don't
require localiza
