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

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

容錯移轉與計畫的主要執行個體變更不同，因為它會在不與舊的主要執行個體同步或更新的情況下升級次要執行個體。這會產生以下主要後果：

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

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

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