本頁面提供 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 執行個體匯出資料」指南操作。