在單主機群組中，若發生主要伺服器容錯移轉（當次要伺服器升級為主要伺服器時），新的主要伺服器可以立即提供給應用程式流量使用，而不論複寫待辦項目有多大；或者，可以限制對其的存取，直到套用待辦項目為止。

使用第一種方法，群組會花費最少的時間，在主要伺服器失敗後，藉由選出新的主要伺服器，然後在仍套用舊主要伺服器的任何可能待辦項目時，立即允許資料存取，來確保穩定的群組成員資格。寫入一致性會受到確保，但當新的主要伺服器套用待辦項目時，讀取可能會暫時擷取過時的資料。例如，如果用戶端 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。每種替代方案都有其優缺點，這些優缺點與您的系統工作負載直接相關。以下範例描述不同類型的工作負載，並建議使用哪種同步點。

想像以下情況

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

想像以下情況

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