Как мне кажется, там немного другие цели преследуются. Самое интересное на мой взгляд:
However, it is also allowed to call InitializeCluster on a server that is already part of an initializedcluster (that has one or more members). This could be necessary for a number of reasons. Inthe Raft algorithm itself, it is for example possible to get into a state where a majority of servershave been lost permanently. The cluster is now without a leader and will not be able to acceptnew events from clients, and also will not be able to elect a new leader. Without a leader it isalso impossible to correct the situation, since AddServer and RemoveServer should be calledon the leader.In such cases the solution is to call InitializeCluster again, essentially starting a new cluster fromthe remains of the one that was just lost. As the databaseId is now regenerated, this also helpsprevent split brain. Or, in the case that the admin would call InitializeCluster on multiple parts ofthe lost cluster, they would still split into separately identifiable parts, each with their own distinctdatabaseId.
А пока в имплементации raft-rs нет databaseId, нам остается только прикручивать эту проверку сбоку — в тарантульных хранимках. Но потом, не сейчас (c).
Но cluster_id закладывался с другой целью. К его появлению нас привели примерно следующие рассуждения:
Что делать пикодате, если пользователь по невнимательности добавит инстанс не в тот кластер, в который хотел?
Давайте заставим пользователя на каждом инстансе прописывать один и тот же cluster_id, так он точно не ошибется.
Последнее утверждение мне кажется наивным и ложным. Поэтому пусть cluster_id хотя бы не мешается в первом релизе.