Thank you, Rob, for pointing me in the right direction. 

"ipa-replica-manage list-ruv" lists the two unused RUVs which matched the number of Ghost reported:

# ipa-replica-manage list-ruv
Directory Manager password:
unable to decode: {replica 29} 627e26a50005001d0000 627e26a50005001d0000
unable to decode: {replica 42} 627e21590005002a0000 627e21590005002a0000
Replica Update Vectors:
    ...
Certificate Server Replica Update Vectors:
    ...
[root@ipa0 ~]#

"ipa-replica-manage clean-dangling-ruv"  cleaned one of the two. 

Followed https://access.redhat.com/solutions/1529903 manually cleaned the second one (by ldapmodify). 

Thanks again, Rob, for your help. 

Kathy. 

On Thu, Jun 9, 2022 at 6:02 AM Rob Crittenden <rcritten@redhat.com> wrote:
Kathy Zhu via FreeIPA-users wrote:
> Hello team, 
>
> We use ipa_check_consistency
> <https://github.com/peterpakos/checkipaconsistency/blob/master/README.md> tool
> to check IPA master consistency every night via cron. One of the masters
> failed at Ghost last night. Here is the check for Ghost: 
>
> |ldapsearch -o ldif-wrap=no -ZZ -LLLx -h ipa1.example.com
> <http://ipa1.example.com> -D ||"cn=Directory Manager"| |-W -s sub
> -b ||"dc=example,dc=com"| |"(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))"| |nscpentrywsi|
>
> What is the significance of this inconsistency? Is there a way to fix
> this other than reinitialize? 

It is a check for unused RUV. Did you recently remove a server?

ipa-replica-manage(1) has several commands to help identify and clean
these up.

For the gory details see
https://directory.fedoraproject.org/docs/389ds/howto/howto-cleanruv.html

rob