RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Document URL: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/High_Availability_Add-On_Overview/ch-operation-HAAO.html#s1-quorumoverview-HAAO

Section Number and Name: 

Describe the issue: 
"In a situation where there is no majority (such as an odd-numbered cluster where one node becomes unavailable, resulting in a 50% cluster split), votequorum can be configured to have a tiebreaker policy, which administrators can configure to continue quorum using the remaining cluster nodes that are still in contact with the available cluster node that has the lowest node ID. "

Suggestions for improvement: 
"In a situation where there is no majority (such as an 2-node cluster where one node becomes unavailable, resulting in a 50% cluster split), votequorum can be configured to have a tiebreaker policy, which administrators can configure to continue quorum using the remaining cluster nodes that are still in contact with the available cluster node that has the lowest node ID. "

Additional information: 
odd-numbered -> 2-node

odd-numbered (3, 5, 7, etc) would be good, from a quorum POV.

I'm not certain whether that original phrasing is really incorrect -- if you have an odd-numbered cluster and one node becomes unavailable, that leaves an even number of nodes which can result in a 50% split. In a two-node cluster where one node becomes unavailable, that results in one working node so there's not really a split. The confusion might be in the phrase "becomes unavailable" -- meaning not in communication rather than not operational.

I'll pass this by one of the developers.

7.1 is going out the door any day, so I'm moving this to 7.2. But if this does result in a change to the documentation I will push it out when it is ready.

The example quoted is doubly incorrect, as you point out. As it's meant to be an example I would keep it simple and state the 2 node case something like this:

"In a situation where there is no majority (such as an 2 node cluster where the internal communication network link becomes unavailable, resulting in a 50% cluster split), ..."

I have updated the document -- in time for 7.1 -- as per Comment 5. Thanks Chrissie.