[
https://issues.apache.org/jira/browse/HBASE-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Demai Ni updated HBASE-9047:
----------------------------
Attachment: hbase-9047-0.94.9-v0
uploaded the prototype(built and tested on 0.94.9) for suggestions, comments
and a couple questions.
The good news is that the protoptye works. I tested with two tables,
replicatedd to at least two peers, with combination of put and deletes.
while, there are still a few items to be address. for instance, a testcase to
be completed for this. And I also have a couple questions(in the next comment
section) for your suggestions.
> Tool to handle finishing replication when the cluster is offline
> ----------------------------------------------------------------
>
> Key: HBASE-9047
> URL: https://issues.apache.org/jira/browse/HBASE-9047
> Project: HBase
> Issue Type: New Feature
> Reporter: Jean-Daniel Cryans
> Assignee: Demai Ni
> Attachments: hbase-9047-0.94.9-v0
>
>
> We're having a discussion on the mailing list about replicating the data on a
> cluster that was shut down in an offline fashion. The motivation could be
> that you don't want to bring HBase back up but still need that data on the
> slave.
> So I have this idea of a tool that would be running on the master cluster
> while it is down, although it could also run at any time. Basically it would
> be able to read the replication state of each master region server, finish
> replicating what's missing to all the slave, and then clear that state in
> zookeeper.
> The code that handles replication does most of that already, see
> ReplicationSourceManager and ReplicationSource. Basically when
> ReplicationSourceManager.init() is called, it will check all the queues in ZK
> and try to grab those that aren't attached to a region server. If the whole
> cluster is down, it will grab all of them.
> The beautiful thing here is that you could start that tool on all your
> machines and the load will be spread out, but that might not be a big concern
> if replication wasn't lagging since it would take a few seconds to finish
> replicating the missing data for each region server.
> I'm guessing when starting ReplicationSourceManager you'd give it a fake
> region server ID, and you'd tell it not to start its own source.
> FWIW the main difference in how replication is handled between Apache's HBase
> and Facebook's is that the latter is always done separately of HBase itself.
> This jira isn't about doing that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
