Re: database migration

Amit Kumar Gupta

Hey Jeff,

Can you describe the burden you're feeling from the monolithic deployment?

We are actively working on splitting up *cf-release* into multiple smaller,
reusable, composable *releases*, but the *manifest deployment* will stay as
one unit to make it easier to ensure that your pieces are working together,
configurations make sense together, and knowing the state of your full
cluster is easier (if you're upgrading e.g. how do you know you've upgraded
all your smaller deployments if you separate them?)


On Mon, Feb 15, 2016 at 10:46 AM, Jeff Weber <jweber(a)> wrote:

I've got a monolithic CF deployment that has become quite a burden to
upgraded because of it's all releases in one manifest nature. I'm currently
working on a plan to cleanup and disaggregate and the first step is to
migrate my core database into its own separate deployment.

After putting my plan together I wanted to confirm it's as simple as it

1) Deploy new database cluster
2) Stop CF services
3) Perform backup of databases on old cluster
4) Restore backups to new cluster
5) Reconfigure manifest to point to new database cluster
6) Redeploy / Start CF services with new manifest
7) Validate
8) Remove old database instance from the manifest

Is there anything outside of these basic steps to watch out for as gotchas
or should this be a straight forward set of tasks?

Join to automatically receive all group messages.