關於唯讀備用資源

Memorystore for Redis 標準級可讓您使用唯讀備用資源,擴充應用程式的讀取查詢。本頁面假設您熟悉不同的 Memorystore Redis 層級功能

您可以透過查詢唯讀備用資源,來擴充讀取工作負載。我們提供讀取端點,方便應用程式在各個副本之間分散查詢。詳情請參閱「使用讀取端點調整讀取作業」。

如需管理含有唯讀備用資源的 Redis 執行個體操作說明,請參閱「管理唯讀備用資源」。

唯讀備用資源的用途

如要使用工作階段儲存庫、排行榜、推薦引擎和其他用途,就必須確保執行個體具有高可用性。在這些用途中,讀取次數遠多於寫入次數,而且這些用途通常可以容許部分過時的讀取作業。在這種情況下,建議您利用唯讀備用資源來提高執行個體的可用性和可擴充性。

唯讀備用資源的行為

  • 根據預設,系統不會在標準級執行個體上啟用唯讀備用資源。
  • 在執行個體上啟用唯讀備用資源後,就無法再為該執行個體停用唯讀備用資源。
  • 標準級執行個體可擁有 1 到 5 個唯讀備用資源。
  • 讀取端點提供單一端點,可在備用節點之間分散查詢。
  • 唯讀備用資源會使用 Redis 非同步複製功能進行維護。

注意事項和限制

  • 唯讀備用資源僅支援節點大小大於或等於 5 GB 的執行個體。
  • 唯讀備用資源只能在使用 Redis 5.0 以上版本的執行個體上啟用。
  • 如果您為建構節點指定可用區和備用可用區,Memorystore 會將這些可用區用於執行個體的第一和第二個節點。接著,Memorystore 會為為執行個體佈建的所有剩餘節點選取區域。
  • 您必須為執行個體提供 CIDR IP 位址範圍,範圍必須為 /28 或更大。較大的範圍大小 (例如 /27/26) 是有效的。這項功能不支援較小的範圍,例如 /29

架構

啟用讀取備用資源時,請指定您在執行個體中所需的備用資源數量。Memorystore 會自動將主要節點和讀取備用資源節點,分散至區域內的可用區。

每個執行個體都有主要端點和讀取端點。主要端點一律會將流量導向主要節點,而讀取端點會自動在可用的備用資源之間平衡讀取查詢。

Memorystore for Redis 健康監控服務會監控執行個體,負責偵測主要節點的任何故障,並選取副本做為新的主機,並啟動自動容錯移轉至新主機。

含有唯讀備用資源的執行個體備援

主要備援主機發生故障時,Memorystore 健康狀態監控服務會啟動容錯功能,並讓新的主備援主機可供讀取和寫入。容錯移轉通常會在 30 秒內完成。

發生容錯移轉時,主要端點會自動將流量重新導向至新的主要端點,但在容錯移轉期間,所有連線至主要端點的用戶端都會中斷連線。當新的主要執行個體上線後,含有連線重試邏輯的應用程式會自動重新連線。部分連線至讀取端點的用戶端也會與在容錯期間升級為主要執行個體的唯讀備用資源中斷連線。在容錯移轉期間,系統會繼續提供連線至剩餘副本的服務。重試時,連線會重新導向至新的複本。

發生容錯移轉時,由於複製作業具有非同步特性,備份資源的複製延遲可能會有所不同。不過,備援程序會盡可能將備援主機切換至延遲最少的備援主機。這有助於在容錯期間盡量減少資料遺失量,並減少讀取吞吐量。新升級的主機可以與舊主機位於相同或不同的區域。如果備用資源與先前的主機位於相同區域,且延遲時間最短,就會選為新的主機。如果沒有,來自不同區域的備用資源可能會成為新的主備用資源。

由於複製作業是非同步的,因此在容錯期間讀取過時資料的可能性始終存在。此外,在升級新的主要執行個體時,可能會遺失對該執行個體的部分寫入作業。應用程式應能處理這項行為。

Redis 會盡力避免在容錯期間,其他備援機制需要進行完整同步處理,但在少數情況下,仍有可能發生這種情況。完整同步作業可能需要數分鐘到數小時,視寫入率和要複製的資料集大小而定。在此期間,正在進行完整同步作業的備用資源無法供讀取。完成同步處理後,您就可以存取備份資料進行讀取。

唯讀備用資源的故障模式

含有唯讀副本的執行個體可能會發生各種失敗和不健康的情況,進而影響應用程式。行為會因執行個體是否有一個或多個備用資源而異。本節將概略說明一些常見的失敗模式,以及執行個體在這些情況下的行為。

備用資源無法使用

  • 當備援機發生任何錯誤時,備援機就會標示為無法使用,且所有與備援機的連線都會在特定逾時後終止。備援資料已復原後,系統會將新的連線轉送至已還原的備援資料。復原副本的時間會因故障模式而異。

  • 如果發生 Compute Engine 缺貨或區域故障的情況,複本會在問題解決後才會復原。

區域故障

  • 如果主要可用區發生故障,主要可用區會自動容錯移轉至其他可用區的備用資源。如果執行個體只有一個備用資源,則在可用區停機期間,讀取端點將無法使用。如果執行個體有多個備用資源,則可在受影響區域以外的備用資源上進行讀取

  • 如果一或多個副本所在的可用區發生故障,這些副本在可用區故障期間將無法使用。如果有兩個區域發生故障,且有兩個以上的備援機制,則會將剩餘區域中延遲時間最短的備援機制升級為主要機制。在未受影響的可用區中,所有剩餘的備用資源皆可供讀取。

網路分區

網路區隔是指節點仍在執行,但無法連上所有用戶端、區域或同級節點的情況。Memorystore 採用以法定數字為基礎的系統,避免孤立的節點提供寫入服務。如果是網路分割區,則少數分割區中的任何主要分割區都會降級。如果多數分割區 (如果有) 尚未選出新的主分割區,則會選出新的主分割區。隔離的備用資源會繼續提供讀取服務。不過,如果無法從主要資料夾同步處理,這些資料夾可能會變得過時。

如要判斷連結是否中斷,請監控 master_link_down_since_secondsoffset_diff 指標,找出孤立的節點。

缺貨

有時某個區域中沒有 Memorystore 所需的 Compute Engine 資源,導致缺貨。如果您嘗試在缺貨的區域中配置執行個體,則建立執行個體的作業會失敗。

完整同步處理

當備用資源落後主要執行個體太多時,系統會觸發完整同步作業,將主要執行個體的整個快照複製到備用資源。這項作業可能需要數分鐘,最糟的情況下則需要一小時。完整同步作業不會導致執行個體失敗,但在此期間,進行完整同步的備援資料副本無法用於讀取,而主要資料副本的 CPU 和記憶體使用率會提高。

主要端點傳回 READONLY

當您透過備用資源寫入 Memorystore for Redis 執行個體的主要端點時,可能會意外收到 -READONLY You can't write against a read only replica. 錯誤。建議您關閉並重新建立與執行個體的連線。在大多數情況下,重新啟動用戶端應用程式即可緩解問題。如果這些方法都不可行,或問題仍未解決,請與支援團隊聯絡 Google Cloud

使用讀取端點調整讀取作業

唯讀備用資源可讓應用程式透過讀取備用資源來擴充讀取作業。應用程式可以透過讀取端點連線至唯讀備用資源。

讀取端點

讀取端點是應用程式連線的 IP 位址。會在執行個體的備用資源之間平均分配連線。連線至唯讀備用資料庫的連線可以傳送讀取查詢,但無法傳送寫入查詢。每個已啟用唯讀備用資源的標準級執行個體都有讀取端點。如需查看執行個體讀取端點的操作說明,請參閱「查看執行個體的讀取副本資訊」。

讀取端點的行為

  • 讀取端點會自動將連線分散至所有可用的複本。連線不會導向主要項目。
  • 只要副本能夠提供用戶端流量,就會被視為可用。但不含備份與主要執行個體進行完整同步的時間。
  • 複製延遲時間較長的備用資源會繼續提供流量。寫入量高的應用程式可從提供大量寫入作業的備用資源讀取舊資料。
  • 如果備用節點成為主要節點,系統會終止該節點的連線,並將新連線重新導向至新的備用節點。
  • 連線到讀取端點的個別連線會在連線的整個生命週期中指定相同的複本。同一個用戶端主機的不同連線不保證會指定相同的複本節點。

讀取一致性

唯讀備用資源會使用原生 OSS Redis 非同步複製功能進行維護。由於非同步複製作業的特性,備用資源可能會落後於主要執行個體。應用程式如果持續寫入,同時也從備用資源讀取,則應能容許不一致的讀取作業。

如果應用程式需要「讀取您的寫入內容」一致性,建議您在寫入和讀取時都使用主要端點。使用主要端點可確保讀取作業一律會導向主要端點。即使在這種情況下,容錯後仍可能會有過時的讀取作業。

在主要執行個體的鍵上設定 TTL,可確保不會從主要執行個體或備用資源讀取已過期的鍵。這是因為 Redis 會確保無法從備用資源讀取已過期的金鑰。

在現有執行個體上啟用唯讀備用資源的行為

  • 在現有 Redis 執行個體上啟用唯讀備用資源是專屬作業,也就是說,您無法在啟用唯讀備用資源的相同作業中執行其他更新作業執行個體修改作業。

  • 無論為 Memorystore for Redis 分配的現有 IP 位址範圍大小為何,在現有 Redis 執行個體上啟用唯讀備用資源時,都必須額外分配大小為 /28 的有效 IP 位址範圍。

    • 為 Redis 執行個體啟用唯讀備用資源時,您必須提供額外的 IP 範圍。您可以選擇特定範圍,也可以讓 Memorystore 自動為您選取範圍。
  • 啟用唯讀備用資源時,執行個體的讀/寫 IP 位址不會變更。讀取端點 IP 位址位於為 Memorystore 執行個體分配的原始範圍,而不是啟用讀取副本時提供的額外範圍。

  • 如要找出新的讀取端點,請在啟用讀取備援作業完成後,查看執行個體的讀取備援資訊

執行個體的資源調度

您可以調整執行個體的讀取備用資源數量,也可以修改節點大小:

建議您在讀取和寫入流量偏低的期間調整執行個體,盡可能降低對應用程式造成的影響。

新增備用資源會導致主要執行個體在備用資源執行完整同步作業時,承受額外負載。新增節點時,現有的連線不會受到影響或轉移。新的備援機制可用後,就會開始接收端點的連線,並提供讀取服務。移除備援機制後,系統會關閉所有導向至該備援機制的有效連線。應將用戶端應用程式設為自動重新連線至讀取端點,以便重新建立與其他備份的連線。

最佳做法

記憶體管理

Redis 不允許用戶端寫入作業超過執行個體的 maxmemory 限制。不過,碎裂、複製緩衝區和 EVAL 等耗用大量資源的指令可能會讓記憶體用量超過此限制。在這種情況下,Memorystore 的寫入作業會失敗,直到記憶體壓力降低為止。詳情請參閱「記憶體管理最佳做法」。

如果 Memorystore 因匯出或完整同步作業而執行 BGSAVE 作業,且發生 OOM 狀況,則會終止子程序。在這種情況下,BGSAVE 作業會失敗,而 Redis 節點伺服器仍可供使用。

為確保在所有情況下都能複製及建立快照,建議您在執行匯出、調整大小等重要作業時,將記憶體使用率維持在 50% 以下。您可以手動觸發匯出備援作業,查看這些作業對效能造成的影響。

CPU 管理

Memorystore 提供指標,說明每個節點的 CPU 用量和連線數量。建議您分配足夠的額外負載,以便在單一可用區無法使用時,系統仍能正常運作。理想的目標可能會因備用資源數量和使用模式而異,但建議您一開始就將備用資源的 CPU 使用率控制在 50% 以下。

如果用戶端使用模式不平衡,或是備援作業導致連線分布不平衡,個別節點可能會出現高使用率。在這種情況下,建議您定期關閉連線,讓 Memorystore 自動重新平衡連線。Memorystore 不會重新平衡已開啟的連線。

連線餘額管理

當節點的連線關閉時,用戶端就必須重新連線,通常是透過啟用所選用戶端程式庫的自動重新連線功能。重新引入節點時,系統不會重新導向現有連線,但會將新連線導向至新節點。用戶端可以定期終止連線,確保連線在可用節點之間平均分配。

複製延遲管理

當寫入率非常高時,副本可能會落後。在這種情況下,副本仍可供讀取。在這種情況下,從備用資源讀取的資料可能會過時,應用程式應能處理這類情況,或者應解決高寫入率問題。

後續步驟