本頁面概要說明 Memorystore for Redis 的 RDB 快照。 本頁面假設您已瞭解開放原始碼 Redis RDB 快照和 Memorystore 匯入/匯出功能。
如要瞭解如何啟用、停用及監控 RDB 快照，請參閱「管理 RDB 快照」。
Memorystore for Redis 主要用做記憶體內快取。將 Memorystore 做為快取時，應用程式可以容許快取資料遺失，也可以從永久儲存空間輕鬆重新填入快取。不過，在某些情況下，Memorystore 執行個體停機或執行個體資料完全遺失，可能會導致應用程式長時間停機。
建議使用標準層做為高可用性的主要機制。此外，在標準層級執行個體上啟用 RDB 快照，可額外防範可能導致快取清除的故障。標準級提供高可用性執行個體，內含多個副本，如果主要執行個體發生故障，可透過自動容錯移轉功能快速復原。
在某些情況下，您可能也希望確保在標準層執行個體發生災難性故障時，可以從快照備份還原資料。在這些情況下，自動備份和從 RDB 快照還原資料的功能，可提供額外的資料遺失防護。啟用 RDB 快照後，系統會在必要時透過最新的 RDB 快照進行復原。
RDB 快照適用於可容許復原後資料過時的用途。您也可以使用 RDB 快照，自動備份及復原基本級執行個體。
RDB 快照總覽
RDB 快照功能的運作方式如下：
在永久儲存空間中，按照使用者指定的時間間隔，儲存完整的時間點快照。
您可以選擇例行快照的頻率和時間。快照間隔最短為
1h，最長為24h。如果基本級執行個體因故障而重新啟動、進行資源調度作業，或升級執行個體的 OSS Redis 版本，系統每次都會從最近的快照還原資料。
標準級執行個體預設會從副本 (而非快照) 復原資料。不過，如果備用資源無法使用，且主要和備用資源都重新啟動，標準級執行個體就會從快照復原資料。
不會增加執行個體帳單的額外費用。
其他行為
快照用於執行個體復原，無法手動還原。在任何時間點，只有上次成功建立的快照可用於復原。除了 RDB 快照，您也可以使用「匯出與匯入」手動備份及還原資料。
在標準級執行個體上，系統會在副本上建立快照，盡量減少主要執行個體的記憶體和 CPU 使用量。系統絕不會從主要節點擷取快照。
限制
適用於使用 Redis 5.0 以上版本的 Memorystore for Redis 執行個體。
如果執行個體有許多鍵 (約 2 億個以上)，RDB 快照和復原作業可能會很慢。在這個重要磁碟區，Redis 伺服器本身可能會成為瓶頸，導致快照和復原作業變慢。
排定 RDB 快照時間
在建立執行個體時啟用 RDB 快照功能時，您必須指定快照間隔。你也可以指定開始時間。這些設定會共同定義快照的每日排程。你可以設定的時間間隔包括 1h、6h、12h 和 24h。舉例來說，如果將開始時間設為凌晨 4 點，間隔設為 1 小時，系統會在啟用快照的當天凌晨 4 點開始建立快照，之後每小時都會建立快照。
如果未指定開始時間，系統會盡快拍攝第一張快照，並遵守間隔。舉例來說，如果未指定開始時間，且間隔為 1 小時，快照可能會在上午 6:13 開始，並在上午 7:13、上午 8:13 等時間繼續。
如果指定開始時間，且快照一律成功建立，所需時間不超過指定的備份間隔，系統就會一律按照每日排程執行作業。
不過，系統會盡量根據每日時間表觸發快照。排程可能會因多種原因而與原先確定的排程有所出入：
如果快照失敗或完成時間超過指定的快照間隔，下一個快照會在目前快照完成後立即開始。
- 為避免快照持續執行並造成執行個體過載，建議您設定足夠長的時間間隔，讓快照順利完成。
如果系統在符合每日排程的時間點正在建立快照，該快照會完成，而下一個快照時間點的計算依據，僅為上次成功建立快照的間隔。
調整現有時間表
您可能會遇到需要暫時停止擷取 RDB 快照的情況。這可能是為了確保重要事件期間不會影響效能，或是暫時停用快照功能來排解效能問題。
如要暫時停止建立快照，請將開始時間調整為未來的日期。將開始時間調整為未來的日期後，下一個快照會等到該日期才會開始。這麼做的話，系統會保留最後一個快照至少 7 天，並在復原時使用。
如要進一步瞭解如何調整快照排程，請參閱「調整快照排程」。
復原行為
基本級 Redis 執行個體會在重新啟動時觸發復原程序。觸發重新啟動的常見作業包括調整執行個體大小和升級執行個體版本。在這些會導致重新啟動、計畫性維護和無法預測的系統故障作業期間，RDB 快照會保留基本級執行個體資料。
標準級 Redis 執行個體會容錯移轉至備用資源，做為主要復原機制，而不是從快照載入。從備用資源還原失敗時，系統會從快照還原標準級執行個體。
復原時的資料一致性
啟用 RDB 快照後，系統會盡力確保備份作業按照指定間隔執行，但無法保證一定會成功。快照可能會因多種原因而失敗。如要瞭解如何啟用 RDB 快照時設定及監控執行個體，請參閱最佳做法。
如果快照在多個間隔連續失敗，最後可用的備份可能任意過時。
從快照復原資料時，最糟的情況是資料遺失量等於自上次開始建立良好快照以來經過的時間間隔，加上將下一個快照儲存到儲存空間所需的時間。如果發生復原事件，請使用 last_success_age 指標查看資料遺失的時間範圍。
建議您設定快訊，以便偵測排定時間的快照是否失敗，並採取修正行動。如要進一步瞭解如何設定快訊，請參閱「監控快照」。
恢復時間
執行個體從快照還原時，您將無法使用執行個體。
復原時間取決於快照大小。如要瞭解預測的復原時間，請在 Google Cloud 控制台使用 Cloud Monitoring 檢查 RDB recovery remaining time 指標。
減緩復原速度緩慢的問題
有時從快照復原資料的時間可能會比預期久。您可能需要採取行動，盡快將應用程式重新連線至 Redis。
在這種情況下，您可以建立新的 Redis 執行個體，並將應用程式流量導向該執行個體。原始執行個體復原後，您就可以將還原的資料轉移至新執行個體。
快照失敗和復原失敗
快照失敗
任何失敗的快照都會回報給 Cloud Monitoring，並立即重試。如果快照連續失敗，復原時遺失的資料量就會增加，因為復原的資料會越來越舊。如要瞭解如何偵測及排解快照失敗問題，請參閱「監控快照」。
復原失敗
復原失敗的情況很少見，但仍有可能發生。如果復原失敗，系統會復原執行個體，但不會復原資料。
最佳做法
如要使用 RDB 快照備份執行個體，請遵循下列最佳做法，以獲得最佳成效：
記憶體管理
RDB 快照會使用程序分叉和「寫入時複製」機制，為執行個體建立快照。視寫入執行個體的模式而定，執行個體的已用記憶體會隨著寫入觸及的頁面複製而增加。在最糟的情況下，記憶體用量可能會是執行個體中資料大小的兩倍。
為確保執行個體有足夠的記憶體來完成快照，您應將 maxmemory-gb 設為執行個體容量的 80%，保留 20% 做為額外負擔。詳情請參閱「記憶體管理最佳做法」。除了監控快照，這項記憶體負荷也有助於管理工作負載，確保快照順利建立。
過時的快照
從過時快照還原執行個體時，應用程式會嘗試調解大量過時的鍵，或資料庫的其他變更 (例如結構定義變更)，因此可能會導致應用程式發生效能問題。
如果您認為快照過舊，或執行個體發生其他重要變更，難以與快照進行比對，可以停用再重新啟用 RDB 快照。這會刪除現有快照，避免您從過時的快照還原。
如要監控過時的快照，請在 RDB 快照 last_status 和 RDB 快照 last_success_age 指標上設定快訊。
從快照還原的時間較長
建議您為 redis.googleapis.com/server/uptime 指標設定快訊，在執行個體無法使用時收到通知。
如果執行個體無法使用，且從快照還原所需時間過長，您可以建立新的 Redis 執行個體，並將流量導向該執行個體。原始 Redis 執行個體復原後，您可以轉移還原的資料至新執行個體。
RDB 快照對效能的影響
視工作負載模式而定，RDB 快照可能會影響執行個體效能，並增加應用程式的延遲時間。
視應用程式可容許的潛在資料遺失量而定，您可以排定在執行個體流量較低的時段執行 RDB 快照，盡量減少對效能的影響。
使用開始時間和間隔，排定所需時間的快照。舉例來說，如果凌晨 1 點到 4 點的負載量很低，您可以將開始時間設為凌晨 3 點，間隔設為 24 小時。
如果系統負載量穩定，且需要頻繁建立快照，請仔細評估效能影響，並權衡使用 RDB 快照對工作負載的好處。
監控快照
請務必監控快照，並設定快照失敗快訊。 如果快照建立失敗，表示執行個體可能過度負載，因此難以從快照還原。
如需可用於監控快照的指標清單，請參閱「RDB 快照指標」。如要接收快照失敗通知，請為 RDB 快照 last_status 指標設定快訊。您也可以使用 Google Cloud 控制台檢查是否有任何失敗情況。
監控效能影響
您可以透過 Cloud Monitoring 查看 CPU 使用率和記憶體用量等指標，監控快照對 Memorystore 執行個體造成的效能影響。如果發現效能降低，可以使用 RDB 快照 in_progress 指標，判斷偵測到效能問題時是否正在建立快照。
後續步驟
- 瞭解如何匯入及匯出備份。
- 請按照「從 Redis 執行個體匯出資料」指南操作。