本頁提供 Memorystore for Redis 的 RDB 快照總覽。本頁面假設您已瞭解開放原始碼 Redis RDB 快照，以及 Memorystore 匯入/匯出功能。
如要瞭解如何啟用、停用及監控 RDB 快照，請參閱「管理 RDB 快照」。
Memorystore for Redis 主要用做為記憶體內快取。使用 Memorystore 做為快取時，應用程式可以容許快取資料遺失，也可以從永久儲存空間輕鬆重新填入快取。不過，在某些情況下，Memorystore 執行個體停機或執行個體資料完全遺失，可能會導致應用程式長時間停機。
建議使用標準層做為高可用性 (HA) 的主要機制。標準級提供具備多個副本的高可用性執行個體，並在主要執行個體發生故障時，透過自動容錯移轉功能快速復原。此外，在標準級執行個體上啟用 RDB 快照，可提供額外保護，防範節點故障。
在某些情況下，您可能也想確保可以從快照備份還原資料。在這些情況下，備份和從 RDB 快照還原資料的功能，可提供額外的資料遺失防護。
如果您啟用 RDB 快照，且需要復原資料，Memorystore for Redis 可以從最新的快照執行這項操作。這些快照僅供內部系統復原，您無法存取。您也可以使用快照，自動備份及還原基本級執行個體。
RDB 快照總覽
RDB 快照功能的行為如下：
按照使用者指定的時間間隔，將完整的時間點快照儲存在永久儲存空間。
您可以選擇例行快照的頻率和時間。快照間隔最短為
1h，最長為24h。根據預設，標準級執行個體會從副本 (而非快照) 復原資料。不過，如果沒有備用執行個體，且主要和備用執行個體都重新啟動，標準層執行個體就會從快照還原資料。
不會增加執行個體帳單的額外費用。
其他行為
快照用於執行個體復原，無法手動還原。在任何時間點，系統只會提供上次成功建立的快照以供復原。除了 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 執行個體會容錯移轉至副本，做為主要復原機制，而不是從快照載入。從副本還原失敗時，系統會從快照還原 Standard 層級執行個體。
復原時的資料一致性
啟用 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 執行個體匯出資料的指南操作。