當我們從 Cloudformation 配置中刪除 SnapshotIdentifier 時會發生什麼

當我們啟動 Cloudformation 堆棧時，我們從快照中恢復了 DBCluster。我們現在正在更新我們的堆棧。

如果我們從配置中刪除 SnapshotIdentifier 鍵，Cloudformation 將如何處理我們的 DBCluster？讓我們在這裡假設我們沒有使用堆棧策略。

文件顯示更新該參數會導致替換。然而，這不是我們想要的，我們也不確定要做什麼來防止這種情況發生。

謝謝！

這種更改屬性 DBSnapshotIdentifier 確實會導致 AWS::RDS::DBInstance 被替換。

在幕後，CloudFormation (CFN) 儲存所有資源的目前配置。當您更新資源時，CFN 會對這些資源進行描述呼叫，並將其與儲存的值進行比較。

只有當值實際發生變化時，才會更新資源。也就是說，只要您不更新 DBSnapshotIdentifier 屬性，就不應替換數據庫。

對於 RDS，CFN 的這種行為可能會導致煩人的問題，尤其是在 RDS 端點發生變化時。

這是我們目前認為的良好做法：

1. 建立自己的 RDS 堆棧，與其他堆棧分開。將 RDS 端點導出為“RDSEndpoint-$Version”。將版本設置為參數。
2. 將您的應用程序指向正確的 RDS 端點。使用前一個堆棧的導出或為此使用 Route53 條目將是最簡單的。
3. 如果您需要對導致替換的 RDS 實例進行更改，請在新的 RDS 堆棧上進行更改，將 $Version 更改為其他內容。
4. 一旦一切正常。更改應用程序中的 RDS 端點（或更改 Route53 條目，只要最適合您）。

常見問題有：

• 數據庫之間數據遷移的持續時間 - 如果您的應用程序不支持這一點，您可能會遇到問題。
• RDS 更改操作通常有點慢。通常只執行 mysqldump + mysql（如果是 MySQL）而不是依賴 AWS 實例會更快。
• 切換到新堆棧時失去憑據（您應該記錄憑據，但無論如何都要考慮這一點）。

如果您正在為您的特定問題尋找一次性解決方案，這裡有一個（可能會停機）：

1. 將您的應用程序設置為只讀或維護模式（如果應用程序不支持此模式，這可能會導致停機）。
2. （手動或使用 RDS 快照）創建數據庫的轉儲。
3. 使用新的 CloudFormation 模板更新您的數據庫
4. 從您的轉儲中恢復。
5. 將您的應用程序切換到生產環境。如果端點改變了，也切換它。

引用自：https://serverfault.com/questions/762932