Yes the command enable_table_replication will check whether a table exists
in peer cluster and if so compare the CFs. Ya you correctly said. The
difference in the table description results in failure of this command. You
can enable replication at src using the alter table command. We can fix
this issue. WDYT @Wellington ?
Anoop
On Thu, May 20, 2021 at 5:07 PM bq zhao <zbq.d...@gmail.com> wrote:
> We tested replication between Apache HBase1.4 and Apache HBase2.2. We found
> that if you use 'enable_table_replication' command to enable replication,
> it will compares table schemas before start. But HBase2 has more default
> parameters than HBase1, which leads to schema comparison failed. However,
> if you use alter command like “alter 'test:test_replication',{NAME =>
> 'f',REPLICATION_SCOPE => '1'}”, the replication can start successfully !
>
> There is also a related jira tracking this issue:
> https://issues.apache.org/jira/browse/HBASE-24353
>
> Wellington Chevreuil <wellington.chevre...@gmail.com> 于2021年5月20日周四
> 下午5:07写道：
>
> > Yes, replication interfaces are compatible between these two major
> > versions.
> >
> > So I created two clusters in AWS and tried enable replication between
> HBase
> > > 1.4.13 and 2.2.5. But have got error "table exists but descriptors are
> > not
> > > the same" (I will put screenshot in the attachment but not sure it will
> > > work here).
> > >
> > Can you describe in detail which steps (commands/configurations) have you
> > executed to get the mentioned error? After which exact action have you
> seen
> > this message? And are the tables schema identical in both clusters?
> >
> > Em qua., 19 de mai. de 2021 às 21:00, Sergey Semenoff <
> > box4semen...@gmail.com> escreveu:
> >
> > > We are thinking about simulator issue. Our clusters much less - 4 by
> 100
> > > RS however we need process data continuously too. So I created two
> > clusters
> > > in AWS and tried enable replication between HBase 1.4.13 and 2.2.5. But
> > > have got error "table exists but descriptors are not the same" (I will
> > put
> > > screenshot in the attachment but not sure it will work here).
> > >
> > > I have some ideas how to make upgrade by another way and would glad to
> > > discuss it with you. So you could write me at box4semen...@gmail.com
> to
> > > dig to details.
> > >
> > > ср, 19 мая 2021 г., 15:50 Bryan Beaudreault
> > > <bbeaudrea...@hubspot.com.invalid>:
> > >
> > >> We are running about 40 HBase clusters, with over 5000 regionservers
> > >> total.
> > >> These are all running cdh5.16.2. We also have thousands of clients
> (from
> > >> APIs to kafka workers to hadoop jobs, etc) hitting these various
> > clusters,
> > >> also running cdh5.16.2.
> > >>
> > >> We are starting to plan an upgrade to hbase 2.x and hadoop 3.x. I've
> > read
> > >> through the docs on https://hbase.apache.org/book.html#_upgrade_paths
> ,
> > >> and
> > >> am starting to plan our approach. More than a few seconds of downtime
> is
> > >> not an option, but rolling upgrade also seems risky (if not impossible
> > for
> > >> our version).
> > >>
> > >> One thought I had is whether replication is compatible between these
> two
> > >> versions. If so, we probably would consider swapping onto upgraded
> > >> clusters
> > >> using backup/restore + replication. If we were to go this route we'd
> > >> probably want to consider bi-directional replication so that we can
> roll
> > >> back to the old cluster if there's a regression.
> > >>
> > >> Does anyone have any experience with this approach? Is replication
> > >> protocol
> > >> compatible across the seversions? Any concerns, tips or other
> > >> considerations to keep in mind? We do the backup/restore + replication
> > >> approach pretty regularly to move tables between clusters.
> > >>
> > >> Thanks!
> > >>
> > >
> >
>
