MySQL 8.4 版本注意事項
雖然交易同步點章節說明概念上您可以選擇兩個同步點：在讀取時或在寫入時，但這些術語簡化了，而群組複寫中使用的術語是：交易執行之前和之後。如同本節所展示，一致性層級可能會對群組處理的唯讀 (RO) 和讀寫 (RW) 交易產生不同的影響。
以下列表顯示您可以使用group_replication_consistency變數，在群組複寫中設定的可能一致性層級，依交易一致性保證遞增順序排列
EVENTUALRO 和 RW 交易都不會在執行之前等待先前的交易套用。這是新增
group_replication_consistency變數之前，群組複寫的行為。RW 交易不會等待其他成員套用交易。這表示交易可以在一個成員上外部化，然後再在其他成員上外部化。這也表示在主要節點故障轉移時，新的主要節點可以在套用所有先前主要節點的交易之前，接受新的 RO 和 RW 交易。RO 交易可能會導致過時的值，而 RW 交易可能會因為衝突而導致回滾。BEFORE_ON_PRIMARY_FAILOVER當新選出的主要節點套用舊主要節點的待處理交易時，新的 RO 或 RW 交易會被保留 (不套用)，直到任何待處理交易都已套用為止。這確保在發生主要節點故障轉移 (無論是有意還是無意) 時，用戶端始終在主要節點上看到最新值。這保證了一致性，但也表示用戶端必須能夠處理正在套用待處理交易時的延遲。通常此延遲應該很短，但它確實取決於待處理交易的大小。
BEFORERW 交易會在套用之前，等待所有先前的交易完成。RO 交易會在執行之前，等待所有先前的交易完成。這確保此交易會讀取最新值，只會影響交易的延遲。這減少每個 RW 交易上同步處理的額外負荷，方法是確保同步處理僅用於 RO 交易。此一致性層級也包括
BEFORE_ON_PRIMARY_FAILOVER所提供的一致性保證。AFTERRW 交易會等待，直到其變更已套用至所有其他成員。此值對 RO 交易沒有任何影響。此模式確保當在本機成員上提交交易時，任何後續交易都會在任何群組成員上讀取寫入的值或更新的值。將此模式用於主要用於 RO 作業的群組，以確保已套用的 RW 交易在提交後會套用至任何地方。您的應用程式可以使用此模式，確保後續讀取會擷取包含最新寫入的最新資料。這減少每個 RO 交易上同步處理的額外負荷，方法是確保同步處理僅用於 RW 交易。此一致性層級也包括
BEFORE_ON_PRIMARY_FAILOVER所提供的一致性保證。BEFORE_AND_AFTER一個 RW 交易在套用之前，會等待 1) 所有先前的交易完成，以及 2) 直到其變更已套用至其他成員。一個 RO 交易會等待所有先前的交易完成，才會執行。此一致性層級也包含
BEFORE_ON_PRIMARY_FAILOVER提供的一致性保證。
BEFORE 和 BEFORE_AND_AFTER 一致性層級都可用於 RO 和 RW 交易。AFTER 一致性層級對 RO 交易沒有影響，因為它們不會產生變更。
不同的ㄧ致性層級為 DBA 提供設定基礎架構的彈性；也為開發人員提供彈性，讓他們可以使用最適合其應用程式需求的一致性層級。以下情境說明如何根據您使用群組的方式選擇一致性保證層級。
情境 1 您想要對讀取進行負載平衡，而不用擔心讀取到過時的資料，且您的群組寫入操作遠少於群組讀取操作。在這種情況下，您應該選擇
AFTER。情境 2 您有一個執行大量寫入的資料集，且您想要偶爾執行讀取，而不用擔心讀取到過時的資料。在這種情況下，您應該選擇
BEFORE。情境 3 您希望工作負載中的特定交易始終從群組讀取最新的資料，以便在更新敏感資料（例如檔案的憑證或類似資料）時，確保讀取始終讀取最新的值。在這種情況下，您應該選擇
BEFORE。情境 4 您有一個主要包含唯讀 (RO) 資料的群組，您希望您的讀寫 (RW) 交易在提交後套用至所有位置，以便後續讀取會在包含最新寫入的最新資料上執行，且您不必在每個 RO 交易上進行同步，而僅需在 RW 交易上進行同步。在這種情況下，您應該選擇
AFTER。情境 5 您有一個主要包含唯讀資料的群組，您希望您的讀寫 (RW) 交易始終從群組讀取最新的資料，並在提交後套用至所有位置，以便後續讀取會在包含最新寫入的最新資料上執行，且您不必在每個唯讀 (RO) 交易上進行同步，而僅需在 RW 交易上進行同步。在這種情況下，您應該選擇
BEFORE_AND_AFTER。
您可以自由選擇強制執行一致性層級的範圍。這很重要，因為如果您將一致性層級設定為全域範圍，可能會對群組效能產生負面影響。因此，您可以透過在不同範圍使用 group_replication_consistency 系統變數來設定群組的一致性層級。
若要在目前工作階段強制執行一致性層級，請使用工作階段範圍
> SET @@SESSION.group_replication_consistency= 'BEFORE';若要在所有工作階段強制執行一致性層級，請使用全域範圍
> SET @@GLOBAL.group_replication_consistency= 'BEFORE';在特定工作階段設定一致性層級的可能性，讓您可以利用以下情境：
情境 6 給定的系統處理多個不需要強一致性層級的指令，但其中一種指令確實需要強一致性：管理文件的存取權限。在此情境中，系統會變更存取權限，並想要確保所有用戶端都看到正確的權限。您只需要在這些指令上
SET @@SESSION.group_replication_consistency= ‘AFTER’，並讓其他指令在全域範圍設定為EVENTUAL的情況下執行。情境 7 在情境 6 中描述的相同系統上，每天都有一個指令需要執行一些分析處理，因此需要始終讀取最新的資料。若要達成此目的，您只需要在該特定指令上
SET @@SESSION.group_replication_consistency= ‘BEFORE’。
總而言之，您不需要以特定的一致性層級執行所有交易，尤其是在只有部分交易實際需要時。
請注意，所有讀寫交易在 Group Replication 中都是完全排序的，因此即使您將目前工作階段的一致性層級設定為 AFTER，此交易也會等待其變更套用於所有成員，這表示等待此交易以及所有可能在次要成員佇列中的先前交易。實際上，一致性層級 AFTER 會等待直到並包括此交易的所有交易。
另一種分類一致性層級的方法是根據對群組的影響，也就是一致性層級對其他成員造成的影響。
BEFORE 一致性層級除了在交易串流中排序外，只會影響本機成員。也就是說，它不需要與其他成員協調，也不會對其交易產生影響。換句話說，BEFORE 只會影響其所使用的交易。
AFTER 和 BEFORE_AND_AFTER 一致性層級確實會對其他成員上執行的並行交易產生副作用。如果 EVENTUAL 一致性層級的交易在執行 AFTER 或 BEFORE_AND_AFTER 的交易時開始，則這些一致性層級會使其他成員的交易等待。其他成員會等待直到 AFTER 交易在該成員上提交，即使其他成員的交易具有 EVENTUAL 一致性層級。換句話說，AFTER 和 BEFORE_AND_AFTER 會影響所有 ONLINE 群組成員。
若要進一步說明，請想像一個包含 3 個成員的群組，分別為 M1、M2 和 M3。在成員 M1 上，用戶端會發出：
> SET @@SESSION.group_replication_consistency= AFTER;
> BEGIN;
> INSERT INTO t1 VALUES (1);
> COMMIT;然後，當上述交易正在套用時，在成員 M2 上，用戶端會發出：
> SET SESSION group_replication_consistency= EVENTUAL;在此情況下，即使第二個交易的一致性層級為 EVENTUAL，由於它是在第一個交易已在 M2 上進入提交階段時開始執行，因此第二個交易必須等待第一個交易完成提交，然後才能執行。
您只能在 ONLINE 成員上使用一致性層級 BEFORE、AFTER 和 BEFORE_AND_AFTER，嘗試在其他狀態的成員上使用它們會導致工作階段錯誤。
一致性層級不是 EVENTUAL 的交易會將執行擱置到達到逾時，此逾時是由 wait_timeout 值設定，預設值為 8 小時。如果達到逾時，則會擲回 ER_GR_HOLD_WAIT_TIMEOUT 錯誤。
本節說明群組的一致性層級如何影響已選出新主要成員的單一主要成員群組。這類群組會自動偵測失敗，並調整使用中成員的檢視，也就是成員資格設定。此外，如果群組是以單一主要成員模式部署，則每當群組的成員資格變更時，都會執行檢查以偵測群組中是否仍有主要成員。如果沒有，則會從次要成員清單中選取一個新的主要成員。通常，這稱為次要成員升級。
鑑於系統會偵測失敗並自動重新設定本身，使用者也可能預期一旦發生升級，新的主要成員在資料方面會與舊的主要成員處於完全相同的狀態。換句話說，使用者可能會預期一旦其應用程式容錯移轉至新的主要成員，則即使是暫時的，也不會有讀取舊資料或寫入舊資料記錄的機會。實際上，使用者可能會預期一旦其應用程式容錯移轉至新的主要成員，就不會有讀取到舊資料或寫入舊資料記錄的任何機會，即使是暫時性的。
當流程控制在群組上啟動並正確調整時，在升級後立即從新選出的主要成員暫時讀取過時資料的機率很小，因為不應有任何待處理的作業，如果有，也應該很小。此外，您可能有 Proxy 或中介軟體層，可在升級後管理應用程式對主要成員的存取，並在該層級強制執行一致性準則。您可以使用 group_replication_consistency 變數來指定新主要成員在升級後的行為，該變數會控制新選出的主要成員是否會封鎖讀取和寫入，直到待處理的作業完全套用為止。如果 group_replication_consistency 變數在具有待處理作業要套用的新選出的主要成員上設定為 BEFORE_ON_PRIMARY_FAILOVER，且交易在新的主要成員仍在套用待處理作業時針對新的主要成員發出，則傳入的交易會被封鎖，直到待處理的作業完全套用為止。因此，可以避免下列異常情況：
唯讀和讀寫交易沒有過時讀取。這可防止新的主要成員將過時讀取外部化至應用程式。
讀寫交易沒有虛假的復原，因為與仍在等待套用的待處理作業中複製的讀寫交易發生寫入與寫入衝突。
讀寫交易沒有讀取偏差，例如：
> BEGIN; > SELECT x FROM t1; -- x=1 because x=2 is in the backlog; > INSERT x INTO t2; > COMMIT;此查詢不應造成衝突，但會寫入過時的值。
總而言之，當 group_replication_consistency 設定為 BEFORE_ON_PRIMARY_FAILOVER 時，您選擇優先考慮一致性而不是可用性，因為只要選出新的主要成員，就會保留讀取和寫入。這是您在設定群組時必須考量的權衡。也應該記住，如果流程控制運作正常，則待處理作業應該會最小。請注意，較高的一致性層級 BEFORE、AFTER 和 BEFORE_AND_AFTER 也包含 BEFORE_ON_PRIMARY_FAILOVER 提供的一致性保證。
為了確保無論將哪個成員升級為主要成員，群組都能提供相同的一致性層級，群組的所有成員都應該將 BEFORE_ON_PRIMARY_FAILOVER (或更高的一致性層級) 持久儲存到其設定。例如，在每個成員上發出：
> SET PERSIST group_replication_consistency='BEFORE_ON_PRIMARY_FAILOVER';這可確保成員都以相同的方式運作，並且設定會在成員重新啟動後持續存在。
交易無法永遠處於擱置狀態，如果擱置的時間超過 wait_timeout，則會傳回 ER_GR_HOLD_WAIT_TIMEOUT 錯誤。
雖然在使用 BEFORE_ON_PRIMARY_FAILOVER 一致性層級時會暫停所有寫入操作，但並非所有讀取操作都會被封鎖，以確保在升級發生後，您仍然可以檢視伺服器在套用積壓的變更。這對於除錯、監控、可觀察性和疑難排解非常有用。某些不修改資料的查詢是被允許的，例如以下這些：
允許的 SHOW 陳述式包括 SHOW VARIABLES、SHOW PROCESSLIST、SHOW STATUS、SHOW ENGINE INNODB LOGS、SHOW ENGINE INNODB STATUS、SHOW ENGINE INNODB MUTEX、SHOW BINARY LOG STATUS、SHOW REPLICA STATUS、SHOW CHARACTER SET、SHOW COLLATION、SHOW BINARY LOGS、SHOW OPEN TABLES、SHOW REPLICAS、SHOW BINLOG EVENTS、SHOW WARNINGS、SHOW ERRORS、SHOW ENGINES、SHOW PRIVILEGES、SHOW PROCEDURE STATUS、SHOW FUNCTION STATUS、SHOW PLUGINS、SHOW EVENTS、SHOW PROFILE、SHOW PROFILES 和 SHOW RELAYLOG EVENTS。