You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by darshit kandpal <dk...@gmail.com> on 2016/07/05 17:28:51 UTC

Re: Hbase replucation

Hello James,
Thanks for the update. There was another issue:
Once the table has been created and replication has been enabled, if I do
alter table in master cluster it should be replicated at the slave since
the column family and table structure remains same at base level. However
the phoenix table structure remains the same in the slave cluster. Is there
a way to enable this automatically?

Thanks,
Darshit

On Sun, Jun 26, 2016 at 3:19 AM, James Taylor <ja...@apache.org>
wrote:

> Hi Darshit,
> The way I've seen this dealt with in the past is really more through
> process: have a upgrade schema client that's responsible for running DDL
> both on the primary and secondary cluster (and disable replication while
> these commands are running to prevent any race conditions). More details
> here [1].
> Thanks,
> James
>
> [1]
> http://mail-archives.apache.org/mod_mbox/phoenix-user/201606.mbox/%3CCAAF1JdggbF5YSCjHAnrjqTZU04dxLdNkCLvh-tpdeok0j853Gg%40mail.gmail.com%3E
>
>
> On Sun, Jun 26, 2016 at 12:14 AM, darshit kandpal <dk...@gmail.com>
> wrote:
>
>> Hello folks,
>>
>> I was struggling with the problem of automatically syncing up the table
>> schema of the phoenix tables as soon as any change is made or a new table
>> is created because hbase replication works only if the two clusters have
>> same tables.
>>
>>
>> Is there a trap based method for this which triggers the same table to be
>> created in the other cluster as soon as it is created in the master cluster.
>>
>> Also when the waledits are shipped only the puts and deletes are
>> replayed. Shouldnt replaying the creates and alters solve this problem
>> permanently? If not i wanted to understand why not?
>>
>> Thanks for your time
>>
>> Darshit
>>
>>
>

RE: Hbase replucation

Posted by ashish singhi <as...@huawei.com>.
Hi.

From HBase side, only table data is replicated once the table is enabled for replication. If any modification done later to table properties it will not be replicated automatically, client has to do it manually.

Regards,
Ashish

-----Original Message-----
From: darshit kandpal [mailto:dkandpal7@gmail.com] 
Sent: 06 July 2016 01:29
To: James Taylor; dev@hbase.apache.org
Subject: Re: Hbase replucation

Hello James,
Thanks for the update. There was another issue:
Once the table has been created and replication has been enabled, if I do alter table in master cluster it should be replicated at the slave since the column family and table structure remains same at base level. However the phoenix table structure remains the same in the slave cluster. Is there a way to enable this automatically?

Thanks,
Darshit

On Sun, Jun 26, 2016 at 3:19 AM, James Taylor <ja...@apache.org>
wrote:

> Hi Darshit,
> The way I've seen this dealt with in the past is really more through
> process: have a upgrade schema client that's responsible for running 
> DDL both on the primary and secondary cluster (and disable replication 
> while these commands are running to prevent any race conditions). More 
> details here [1].
> Thanks,
> James
>
> [1]
> http://mail-archives.apache.org/mod_mbox/phoenix-user/201606.mbox/%3CC
> AAF1JdggbF5YSCjHAnrjqTZU04dxLdNkCLvh-tpdeok0j853Gg%40mail.gmail.com%3E
>
>
> On Sun, Jun 26, 2016 at 12:14 AM, darshit kandpal 
> <dk...@gmail.com>
> wrote:
>
>> Hello folks,
>>
>> I was struggling with the problem of automatically syncing up the 
>> table schema of the phoenix tables as soon as any change is made or a 
>> new table is created because hbase replication works only if the two 
>> clusters have same tables.
>>
>>
>> Is there a trap based method for this which triggers the same table 
>> to be created in the other cluster as soon as it is created in the master cluster.
>>
>> Also when the waledits are shipped only the puts and deletes are 
>> replayed. Shouldnt replaying the creates and alters solve this 
>> problem permanently? If not i wanted to understand why not?
>>
>> Thanks for your time
>>
>> Darshit
>>
>>
>