與 InnoDB Cluster 不同，後者支援在主要執行個體發生意外故障時自動容錯移轉，而 InnoDB ReplicaSet 沒有自動故障偵測或像 Group Replication 所提供的基於共識的協定。如果主要執行個體不可用，則需要手動容錯移轉。遺失主要執行個體的 InnoDB ReplicaSet 實際上是唯讀的，且為了能夠進行任何寫入變更，必須選擇新的主要執行個體。如果您無法連線至主要執行個體，且無法使用 ReplicaSet.setPrimaryInstance() 安全地執行切換至新主要執行個體（如第 9.7 節，「變更主要執行個體」中所述），請使用 ReplicaSet.forcePrimaryInstance() 操作來執行主要執行個體的強制容錯移轉。這是一種最後手段的操作，只能在目前的 主要執行個體不可用且無法以任何方式還原的災難情況下使用。

如果目標執行個體無法連線 (或為 null)，則會自動選取最新的執行個體並升級為新的主要執行個體。如果目標執行個體可連線，則會將其升級為新的主要執行個體。其他可連線的次要執行個體會從這個新的主要執行個體進行複製。目標執行個體必須在可連線的執行個體中擁有最新的 GTID_EXECUTED 集，否則操作會失敗。

容錯移轉與計畫中的主要變更不同，因為前者會在沒有與舊的主要執行個體同步或更新的情況下，升級次要執行個體。這會造成以下主要後果

如果最後已知的主要執行個體仍然可連線，ReplicaSet.forcePrimaryInstance() 操作會失敗，以降低發生腦裂情況的風險。但是，管理員有責任確保舊的主要執行個體無法被其他執行個體連線，以防止或最大程度地減少這種情況。

在強制容錯移轉之後，新的主要執行個體會認為舊的主要執行個體無效，且舊主要執行個體無法再成為 ReplicaSet 的一部分。如果您稍後發現可以復原的執行個體，您必須從 ReplicaSet 移除它，並將其新增為新的執行個體。如果次要執行個體在容錯移轉期間無法切換至新的主要執行個體，則會被視為無效。

在容錯移轉之後可能會發生資料遺失，因為舊的主要執行個體可能具有尚未複製到升級的次要執行個體的交易。此外，如果假設為已失敗的執行個體仍然可以處理交易，例如因為它所在的網路仍在運作但無法從 MySQL Shell 連線，則它會持續與升級的執行個體分歧。一旦執行個體上的交易集分歧，復原就需要手動介入，而且在某些情況下可能無法復原，即使可以復原失敗的執行個體。通常，從需要強制容錯移轉的災難中復原最快且最簡單的方法是捨棄此類分歧的交易，並從新升級的主要執行個體重新佈建新的執行個體。