Hi, Andrew.
It is hard to repeat the problem. Because the pitfall that I described
only work under the edge conditions, such as DC has a high payload, or
some crmd broadcasts NON-VOTE messages slowly.
However, I indeed ever encountered that condtions.
This pitfall is based on two facts:
1. VOTE may be launched in non-atomic manner
2. Once receiving a NON-VOTE from some node, no matter it's outdated
or not, no matter the 'voted' hash is empty (because the lastest ELECTION
is already over) that time or not, it will be recorded in the 'voted' hash.
Of course, I also found there exists some casual remedy for the pitfall.
1. callback of CCM event will skip the obsolete items in 'voted'
2. g_hash_table_replace() will replace the old key with the new key
(NO-VOTEDs
which come from the same node), though their corresponding
"current_election_id" are different.
The exist documents is old, will you please provide (write) some
fresh & detail documents (about the design & key implementation of crmd
family)
for the linux-ha-fans? After all, the code of crmd family (including cib,pe,
te,ccm,lrm) take up the biggest part of the whole hb, I think.
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
