hey guys, huge thanks for all the help so far 🙌 Now I’m trying to restore my serverless aurora cluster from a snapshot as a pre-launch exercise to make sure we can recover from a disaster I see that CDK has a construct for this in 1.147.0 First Question: SST does not support 1.147.0 yet right? I think I was able to workaround this with an escape hatch, but my deployment is complaining that the cluster can’t be updated because it is in use. Second Question: Anyone familiar with this and know how to restore a cluster?

uat-polls-api-Database failed: Export uat-polls-api-Database:ExportsOutputRefDatabaseB269D8BB88F4B1C4 cannot be updated as it is in use by uat-polls-api-Api, uat-polls-api-Auth and uat-polls-api-Migrate

FYI under the hood restoring actually creates a new serverless cluster from the snapshot

Hey @Jeff Hanna SST is using CDK 2.7.0.

DatabaseClusterFromSnapshot

is supported.

Holy shit I didn't know about

DatabaseClusterFromSnapshot

- I was about to do a giant migration tonight and use pg_dump/pg_restore. Is this okay to use long-term? Like it'll restore from snapshot the first time and then run like normal from then on?

@Mischa Spiegelmock once you restore from snapshot, you need to continue to use that CDK construct and provide the same snapshot identifier for each deployment afterwards

cool I'm going to give this a try in a few hours! thanks!

@Frank oh that’s great to know, maybe it will solve my problem my project was started on

0.51.1

, I tried to figure to upgrade and maybe I was mistaken but I thought even the latest sst was using CDK 1.126.0 so I just reverted back to 0.51.1 is there a guide on how to upgrade to new sst? I think I would just want to upgrade to CDK 1.147.0 to minimize the changes right before my launch also I see that my package.json includes cdk stuff like

@aws-cdk/aws-cognito

, do i need to upgrade all of those to match the CDK version in SST? or should I remove those because SST includes them?

there is a guide yeah, and some handy script to fix imports somewhere

lol that’s the error that my original message at the top of this thread is about

argh

@Mischa Spiegelmock if you find any solution please let me know, I will do the same

okay

ya the cross-reference is the reason it’s complaining, but that’s just ridiculous on AWS side, they should recognize that we’re doing a tear down, deploy new cluster, and map the API to the new cluster in one go, the same way we are able to make other updates to stacks that cross-reference

hm

ok, so now that I think about it, seems like can be done easily in 2 ways (forget the suggestion from AWS haha) cc @Frank maybe could be helpful to turn this into a doc on restoring clusters! Option 1 1. Deploy 1 a. Keep your code that creates your current cluster b. Setup your code to create a second cluster, using a new id, and this one should use the snapshot c. Update your cross-referencing to point to your new cluster i. if you are not on sst 0.60.8 or later then to remove a cross-reference you first need to add an explicit export of the reference 2. Deploy 2 a. Remove your original cluster Option 2 1. Deploy 1 a. Remove your cross-reference, if you are not on sst 0.60.8 or later then to remove a cross-reference you first need to add an explicit export of the reference 2. Deploy 2 a. Restore from snapshot and remove explicit export 3. Deploy 3 a. Recreate your cross-references to your new db cluster

@Jeff Hanna Thanks for sharing! I haven’t tried restoring from snapshot, do u know if there’s an easy way to restore from snapshot and catch up to the existing cluster? (ie. like a master-slave setup where slave is catching up to the master)

I did import from snapshot and set some env vars, worked pretty well

not sure about catching up @Frank, would be amazing