Questions regarding transfer_leadership_to and vote APIs (有关transfer_leadership_to 和 vote API 的问题)

[vpshastry]

In our application we sometimes use multiple braft state machines from the same instance. It is a problem if multiple nodes' leaders land on the same application instance. To avoid this, we looked at leadership control APIs transfer_leadership_to and vote. Appreciate if you can answer my following question.

Using transfer_leadership_to API, what happens if I choose the peer to be the leader that happens to be 'not compatible'? I'm not sure all the cases that makes a node 'incompatible'. One thing we can think of is if it is lagging in applying the logs. I looked at the implementation of this API and we seem to have checks against transferring the leadership if it failed the heartbeat. But no other checks. Would you be able to explain what would happen in this case? If it indeed a problematic call is there a way we can choose the set of 'healthy' peers? Would such errors be bubbled up in the return value?

Note:

1. Separating braft state machines to its own application instance is something we are aware and is a future task.

Thanks in advance

使用在线工具将英语翻译成简体中文：
在我们的应用程序中，我们有时会使用同一实例中的多个 brat 状态机。 如果多个节点的领导者登陆同一个应用程序实例，就会出现问题。 为了避免这种情况，我们研究了领导力控制 API“transfer_leadership_to”和“vote”。 如果您能回答我的以下问题，将不胜感激。

使用“transfer_leadership_to” API，如果我选择的对等点恰好是“不兼容”的领导者，会发生什么？ 我不确定所有导致节点“不兼容”的情况。 我们可以想到的一件事是应用日志是否滞后。 我查看了这个 API 的实现，我们似乎对在心跳失败时转移领导权进行了检查。 但没有其他检查。 您能解释一下在这种情况下会发生什么吗？ 如果这确实是一个有问题的调用，我们是否可以选择一组“健康”的对等点？ 这样的错误会在返回值中出现吗？

提前致谢

笔记：

1. 我们已经意识到将 braft 状态机分离到其自己的应用程序实例，并且是未来的任务。