LebronAl commented on issue #3954: URL: https://github.com/apache/iotdb/issues/3954#issuecomment-918793656
> IMO, this depends on what kinds of properties IoTDB'd like to guarantee for user. If IoTDB says, I won't lost any data in any situation, then persist each log every time is required and relative performance lose should be acceptable. But if it's doesn't do such guarantee, then it's OK to do some optimization. Of course, we can make it configurable just like standalone WAL in IoTDB. As I didn't look into Ratis, I'm not sure if it makes this configurable. Seems can be [configurable](https://github.com/apache/ratis/blob/7a852736de1588bc645f86a92a1d6b4d37b21e2b/ratis-server-api/src/main/java/org/apache/ratis/server/RaftServerConfigKeys.java#L268). Anyway, Let's speed some time exploring it. >I don't understand, on zhihu, it says "proposal id" is generated by client, and filter when do apply(often implemented by State Machine). So I think the retry logic is transparent for raft, the retry operation is new log for raft. Not sure my understanding is right or not. maybe you could read my [doc](https://github.com/LebronAl/MIT6.824-2021/blob/master/docs/lab3.md) of MIT 6.824 lab3, which is slightly more understandable. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: reviews-unsubscr...@iotdb.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
