[ https://issues.apache.org/jira/browse/ZOOKEEPER-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007605#comment-13007605 ]
Ivan Kelly commented on ZOOKEEPER-1016: --------------------------------------- I've try to summarise offline discussion from Tuesday. Please let me know if my understanding was off the mark. Ben asked how TeaKeeper will differ from Hedwig. The main difference is that TeaKeeper will be a library colocated with the service writing to it. There'll be no extra server running the service, not even a daemon. Only one service will write to teakeeper at a time. As such, TeaKeeper is a subset of the functionally of Hedwig, aimed at the specific problem of hot standby. Mahadev raised concern that TeaKeeper would need knowledge of the service to be effective. For example, in the namenode case, teakeeper would have to know that only the primary can make progress, and so only the primary could log. The design addresses this by stipulating that only primary can indeed log. TeaKeeper manages who is primary and who are the secondaries through zookeeper. There will need to be a notifier for the situation where the primary changes, but apart from that, I don't see this as a big issue. > 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 > > > 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