Conversation
|
|
||
| The commands below use example names. Your database runs in a Docker Compose service called `postgres`, and your server runs in a service called `server`. The database is called `my_project`. Replace these names with your own. | ||
|
|
||
| Run the `docker compose` commands on your server, and the `serverpod cloud` commands from your server directory on your machine. |
Contributor
There was a problem hiding this comment.
Suggestion: "your server directory" reads as the VPS, which the sentence just called "your server".
Suggested change
| Run the `docker compose` commands on your server, and the `serverpod cloud` commands from your server directory on your machine. | |
| Run the `docker compose` commands on your server, and the `serverpod cloud` commands from your project's `<project>_server` folder on your own machine. |
| serverpod cloud db user create migrator | ||
| ``` | ||
|
|
||
| The `migrator` user can read and write rows. It can't change the schema, disable triggers, or turn off foreign key checks. That's why the dump contains data only. See [Access the database directly](/cloud/concepts/database#access-the-database-directly) for more about database users. |
Contributor
There was a problem hiding this comment.
Suggestion: "can't change the schema" is broader than the restore needs. The two things that matter here are triggers and foreign key checks.
Suggested change
| The `migrator` user can read and write rows. It can't change the schema, disable triggers, or turn off foreign key checks. That's why the dump contains data only. See [Access the database directly](/cloud/concepts/database#access-the-database-directly) for more about database users. | |
| The `migrator` user can read and write rows, but it can't disable triggers or turn off foreign key checks. That's why the dump contains data only. See [Access the database directly](/cloud/concepts/database#access-the-database-directly) for more about database users. |
| -c "SELECT module, version FROM serverpod_migrations ORDER BY module;" | ||
| ``` | ||
|
|
||
| Replace `<host>` and `<database>` with the values from `serverpod cloud db connection`. |
Contributor
There was a problem hiding this comment.
Suggestion: serverpod cloud db connection prints a port too, and includes it in the connection string it prints.
Suggested change
| Replace `<host>` and `<database>` with the values from `serverpod cloud db connection`. | |
| Replace `<host>` and `<database>` with the values from `serverpod cloud db connection`. If it prints a port, add it after the host as `<host>:<port>`. |
| - **Keep the `*` at the end of each pattern.** It also leaves out each table's ID sequence. Without it, the dump carries your server's sequence values, and the restore resets Cloud's counters for those tables. | ||
| - **Everything else is included.** That covers your own tables, users, sessions, future calls, and files stored in the database. | ||
|
|
||
| `pg_dump` warns about circular foreign keys between `serverpod_auth_core_profile` and `serverpod_auth_core_profile_image`, with a hint to use a full dump. Ignore the hint. The warning only matters if some of your users have profile images. Count them: |
Contributor
There was a problem hiding this comment.
Nit: don't open a sentence with a code span, it reads as a symbol rather than a sentence. Lines 115 and 176 too.
Suggested change
| `pg_dump` warns about circular foreign keys between `serverpod_auth_core_profile` and `serverpod_auth_core_profile_image`, with a hint to use a full dump. Ignore the hint. The warning only matters if some of your users have profile images. Count them: | |
| The `pg_dump` command warns about circular foreign keys between `serverpod_auth_core_profile` and `serverpod_auth_core_profile_image`, with a hint to use a full dump. Ignore the hint. The warning only matters if some of your users have profile images. Count them: |
| --- | ||
| sidebar_position: 5 | ||
| sidebar_label: Migrate a self-hosted database | ||
| description: Database migration from a self-hosted Serverpod server to Serverpod Cloud. Copy your data, users, and auth secrets with pg_dump and pg_restore. |
Contributor
There was a problem hiding this comment.
Suggestion: "Database migration" is what Serverpod calls schema migrations, and the page checks "migration versions" a few lines later. Same for "the migration user" on line 204, which is the migrator user. Your call on the title.
Suggested change
| description: Database migration from a self-hosted Serverpod server to Serverpod Cloud. Copy your data, users, and auth secrets with pg_dump and pg_restore. | |
| description: Moving a self-hosted database into Serverpod Cloud with pg_dump and pg_restore, so your data, users, and sessions come across intact. |
|
|
||
| Three details in this command matter: | ||
|
|
||
| - **Dump with `--data-only`.** A data-only dump orders tables by their foreign keys, so users are restored before their profiles. A full dump doesn't, so restoring it can fail on foreign key errors. |
Contributor
There was a problem hiding this comment.
Nit: reads as if any restore of a full dump fails. It's a full dump restored with --data-only that does, as the PR description says.
Suggested change
| - **Dump with `--data-only`.** A data-only dump orders tables by their foreign keys, so users are restored before their profiles. A full dump doesn't, so restoring it can fail on foreign key errors. | |
| - **Dump with `--data-only`.** A data-only dump orders tables by their foreign keys, so users are restored before their profiles. A full dump doesn't, so restoring it with `--data-only` can fail on foreign key errors. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a guide for moving a self-hosted database (Serverpod and PostgreSQL in Docker, for example on a VPS) into a Cloud project. Nothing covers this today, and the obvious
pg_dumpandpg_restore --data-onlyroute fails on the tables Cloud writes itself.--data-onlyat the source, which orders tables by foreign key. A full dump restored with--data-onlyfails onserverpod_auth_core_profile.--exclude-table-datacovers the data Cloud writes on each deploy, each pattern keeping a trailing*so the table's ID sequence is left out too.emailSecretHashPepperand the JWT keys are copied before any user rows land, otherwise sign-in fails withinvalidCredentialsand the first refresh deletes the session.serverpod_auth_core_profileandserverpod_auth_core_profile_imagereference each other and the Cloud database user cannot disable triggers.Every step run against a Cloud project on the starter plan, with a Docker Compose source on PostgreSQL 16, at Serverpod 4.0.0 and Cloud CLI 1.0.0.