在單主機群組中，如果發生主要伺服器容錯移轉，且將次要伺服器升級為主要伺服器，則可以立即將新的主要伺服器提供給應用程式流量，而無需考慮複製待辦事項的大小，或者可以限制對其的存取，直到應用待辦事項為止。

使用第一種方法，群組會以最短的時間在主要伺服器失敗後，透過選出新的主要伺服器來確保穩定的群組成員資格，然後允許立即進行資料存取，同時仍在應用舊主要伺服器的任何可能待辦事項。這樣可以確保寫入一致性，但讀取操作可能會在新的主要伺服器應用待辦事項時，暫時擷取過時的資料。例如，如果用戶端 C1 在舊的主要伺服器失敗之前寫入 A=2 WHERE A=1，則當用戶端 C1 重新連線至新的主要伺服器時，可能會讀取 A=1，直到新的主要伺服器應用其待辦事項，並趕上舊主要伺服器在離開群組之前的狀態。

使用第二種方法，系統會在主要伺服器失敗後確保穩定的群組成員資格，並以與第一種方法相同的方式選出新的主要伺服器，但在這種情況下，群組會等待直到新的主要伺服器應用所有待辦事項，然後才會允許資料存取。這可以確保在先前描述的情況下，當用戶端 C1 重新連線至新的主要伺服器時，會讀取 A=2。但是，權衡之處是容錯移轉所需的時間與待辦事項的大小成正比，而在正確設定的群組中，待辦事項應該很小。

您可以使用 group_replication_consistency 變數設定成員在主要伺服器容錯移轉期間提供的交易一致性保證層級。請參閱 一致性對主要伺服器選取的影響。

由於針對群組執行的讀取和寫入作業，資料流與群組一致性保證相關，尤其是在所有成員之間分配這些作業時。資料流作業適用於群組複製的兩種模式：單主機和多主機，但是為了使此說明更清楚，它限制為單主機模式。在單主機群組的成員之間分割傳入讀取或寫入交易的常見方式是將寫入路由至主要伺服器，並將讀取均勻分配至次要伺服器。由於群組應該像單一實體一樣運作，因此可以合理地預期主要伺服器的寫入會立即在次要伺服器上可用。儘管群組複製是使用實作 Paxos 演算法的群組通訊系統 (GCS) 通訊協定撰寫，但群組複製的某些部分是異步的，這表示資料會以異步方式套用至次要伺服器。這表示用戶端 C2 可以在主要伺服器上寫入 B=2 WHERE B=1，立即連線至次要伺服器並讀取 B=1。這是因為次要伺服器仍在應用待辦事項，且尚未應用主要伺服器套用的交易。

您可以根據想要在群組中同步交易的時間點，設定群組的一致性保證。為了協助您理解此概念，本節將簡化群組中同步交易的時間點，使其位於讀取作業的時間或寫入作業的時間。如果在讀取時同步資料，則目前的用戶端工作階段會等待到給定的時間點，這是在開始執行之前已套用所有先前更新交易的時間點。使用這種方法，只會影響此工作階段，而不會影響所有其他並行的資料作業。

如果在寫入時同步資料，則寫入工作階段會等待直到所有次要伺服器都寫入其資料為止。群組複製會在寫入時使用總排序，因此這表示等待此寫入和次要伺服器佇列中所有先前的寫入套用。因此，當使用此同步點時，寫入工作階段會等待所有次要伺服器佇列套用。

任何替代方案都能確保在為客戶端 C2 描述的情況中，即使立即連線到次要節點，也總是會讀取到 B=2。每個替代方案都有其優缺點，這與您的系統工作負載直接相關。以下範例描述了不同類型的工作負載，並建議適當的同步點。

想像以下情況

在這些情況下，您應該選擇在寫入時進行同步。

想像以下情況

在這些情況下，您應該選擇在讀取時進行同步。