Migrating a Live Ceramic Mainnet Node Between Hosts (AWS Accounts)

Hello,

I am trying to migrate an actively hosted Ceramic mainnet node built from the terraform repository between AWS accounts. It is critical that no data is lost, however, it would also be preferable to have little/ no downtime.

One route could be to manually migrate the underlying storage S3 for IPFS and Ceramic. A more elegant solution might be to spin up a second node in the destination AWS account and then sync the data between them. One consideration is that the node is in production, so there may be a small but unavoidable downtime window so that the state does not fluctuate during sync.

Suggestions are greatly appreciated!

Hi @jp4g, thanks for posting here and apologies for the delay.

There are a few things to consider here.

One option would be to use cross-account access for AWS S3. This would mean keeping the data in the old account, but systematically allowing accessing to it from the new one.

Alternatively, you could setup cross-account replication, which might work better if you plan to fully switch over to the new account. You could replicate all the S3 contents between accounts, point your app to the Ceramic node using the new (replicated) bucket in the new account where it could just get going like nothing changed, then shut down the old node and turn off replication once you’re sure all contents are synced.

This hopefully takes care of the Ceramic state store and IPFS block store.

The IPFS pin store is still on an EFS volume, but could work with a similar strategy.

The first option would be to cross-account EFS mounting to access your pin store from the new account while still being stored in the old account.

Alternatively, you could setup cross-account data sync to replicate EFS data across accounts, setup your new IPFS node to use that volume, point your app to the new Ceramic/IPFS nodes once all data (state store, block store, pin store) is synced, then shut down the old nodes and turn off replication once you’re sure all data has been synced.

If done this way, and if I’m understanding things correctly, you might not have any downtime or data loss at all (though all this will be a bit of work to setup).

1 Like

Definitely seems like a big undertaking to accomplish. I am thinking I will instead just use this AWS account explicitly for the Ceramic node and move everything else I had previously used the account for out since that is far easier and safer for production data safety.

The one thing then becomes replacing the ACM SSL key. Should this be as easy as making a new key, pointing to the key in the vars.tfvars file, and redeploying the stack?

Also, while I do not intend to go down this route, I do want to ask: is there any way to tell one Ceramic RPC to sync the other RPC?

Should this be as easy as making a new key, pointing to the key in the vars.tfvars file, and redeploying the stack?

Yes, that’s correct.

Also, while I do not intend to go down this route, I do want to ask: is there any way to tell one Ceramic RPC to sync the other RPC?

There isn’t, unfortunately :frowning: