[
https://issues.apache.org/jira/browse/ZOOKEEPER-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011762#comment-13011762
]
Jitendra Nath Pandey commented on ZOOKEEPER-1016:
-------------------------------------------------
@Ivan
In the design, instead of registering a listener and receiving notification for
each update, can we do something like following ?
interface TeaKeeperReader {
open(byte[] logName, byte[] sinceTxnId);
TxnRecord next();
close(byte[] logName);
}
The next method blocks if next record is not available yet or until an
exception is received (or timeout). If no writer is writing, the next should
throw an exception as soon as all records have been read. next returns a
transaction record.
Then we can avoid having to register an Updater in listen. We won't need a
separate readRange method, the reader can read as much as it wants. If backup
is notified that it should take over, it will continue to call next until an
exception (say NoWriterException). This approach takes care of sync and makes
sure backup will attempt to take over only when primary stopped writing.
> TeaKeeper: Hot standby support using bookkeeper
> -----------------------------------------------
>
> Key: ZOOKEEPER-1016
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1016
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Priority: Minor
> Attachments: tledger.pdf, tledger.pdf
>
>
> Currently Bookkeeper provides functionality for cold backups. If the entity
> logging to bookkeeper fails, its replacement must recover the ledgers which
> had been used for backup before becoming available. This is acceptable in
> some cases, such as HBase Wals where a small delay in recovery only results
> in a small percentage of data being unavailable.
> However, systems such as the HDFS namenode, this delay can be unacceptable,
> such as cases where data is being served to customers. Secondary namenodes
> should be ready to go the instant the primary goes down.
> TeaKeeper proposes a wrapper library around Bookkeeper providing T-Junction
> like functionality for logging. It also provides for primary/secondary
> election and automated hot failover.
> HDFS namenode is primary target of this work.
> The attached design doc contains more details.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
