This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Support for database schema version ranges #9933
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
e425a1f
Introduce an `attrs` to contain db schema state
richvdh a7da9df
Support for ranges of database schemas
richvdh ddb7676
changelog
richvdh 65e546c
Merge remote-tracking branch 'origin/develop' into rav/database_migra…
richvdh 1aac02f
update version numbers
richvdh f15dc2a
move `compat_version` definition into the Python
richvdh 4eae684
Move new docs into the docs hierarchy
richvdh 3ad9e10
Apply suggestions from code review
richvdh File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Update the database schema versioning to support gradual migration away from legacy tables. |
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,95 @@ | ||
# Synapse database schema files | ||
|
||
Synapse's database schema is stored in the `synapse.storage.schema` module. | ||
|
||
## Logical databases | ||
|
||
Synapse supports splitting its datastore across multiple physical databases (which can | ||
be useful for large installations), and the schema files are therefore split according | ||
to the logical database they apply to. | ||
|
||
At the time of writing, the following "logical" databases are supported: | ||
|
||
* `state` - used to store Matrix room state (more specifically, `state_groups`, | ||
their relationships and contents). | ||
* `main` - stores everything else. | ||
|
||
Additionally, the `common` directory contains schema files for tables which must be | ||
present on *all* physical databases. | ||
|
||
## Synapse schema versions | ||
|
||
Synapse manages its database schema via "schema versions". These are mainly used to | ||
help avoid confusion if the Synapse codebase is rolled back after the database is | ||
updated. They work as follows: | ||
|
||
* The Synapse codebase defines a constant `synapse.storage.schema.SCHEMA_VERSION` | ||
which represents the expectations made about the database by that version. For | ||
example, as of Synapse v1.36, this is `59`. | ||
|
||
* The database stores a "compatibility version" in | ||
`schema_compat_version.compat_version` which defines the `SCHEMA_VERSION` of the | ||
oldest version of Synapse which will work with the database. On startup, if | ||
`compat_version` is found to be newer than `SCHEMA_VERSION`, Synapse will refuse to | ||
start. | ||
|
||
Synapse automatically updates this field from | ||
`synapse.storage.schema.SCHEMA_COMPAT_VERSION`. | ||
|
||
* Whenever a backwards-incompatible change is made to the database format (normally | ||
via a `delta` file), `synapse.storage.schema.SCHEMA_COMPAT_VERSION` is also updated | ||
so that administrators can not accidentally roll back to a too-old version of Synapse. | ||
|
||
Generally, the goal is to maintain compatibility with at least one or two previous | ||
releases of Synapse, so any substantial change tends to require multiple releases and a | ||
bit of forward-planning to get right. | ||
|
||
As a worked example: we want to remove the `room_stats_historical` table. Here is how it | ||
might pan out. | ||
|
||
1. Replace any code that *reads* from `room_stats_historical` with alternative | ||
implementations, but keep writing to it in case of rollback to an earlier version. | ||
Also, increase `synapse.storage.schema.SCHEMA_VERSION`. In this | ||
instance, there is no existing code which reads from `room_stats_historical`, so | ||
our starting point is: | ||
|
||
v1.36.0: `SCHEMA_VERSION=59`, `SCHEMA_COMPAT_VERSION=59` | ||
|
||
2. Next (say in Synapse v1.37.0): remove the code that *writes* to | ||
`room_stats_historical`, but don’t yet remove the table in case of rollback to | ||
v1.36.0. Again, we increase `synapse.storage.schema.SCHEMA_VERSION`, but | ||
because we have not broken compatibility with v1.36, we do not yet update | ||
`SCHEMA_COMPAT_VERSION`. We now have: | ||
|
||
v1.37.0: `SCHEMA_VERSION=60`, `SCHEMA_COMPAT_VERSION=59`. | ||
|
||
3. Later (say in Synapse v1.38.0): we can remove the table altogether. This will | ||
break compatibility with v1.36.0, so we must update `SCHEMA_COMPAT_VERSION` accordingly. | ||
There is no need to update `synapse.storage.schema.SCHEMA_VERSION`, since there is no | ||
change to the Synapse codebase here. So we end up with: | ||
|
||
v1.38.0: `SCHEMA_VERSION=60`, `SCHEMA_COMPAT_VERSION=60`. | ||
|
||
If in doubt about whether to update `SCHEMA_VERSION` or not, it is generally best to | ||
lean towards doing so. | ||
|
||
## Full schema dumps | ||
|
||
In the `full_schemas` directories, only the most recently-numbered snapshot is used | ||
(`54` at the time of writing). Older snapshots (eg, `16`) are present for historical | ||
reference only. | ||
|
||
### Building full schema dumps | ||
|
||
If you want to recreate these schemas, they need to be made from a database that | ||
has had all background updates run. | ||
|
||
To do so, use `scripts-dev/make_full_schema.sh`. This will produce new | ||
`full.sql.postgres` and `full.sql.sqlite` files. | ||
|
||
Ensure postgres is installed, then run: | ||
|
||
./scripts-dev/make_full_schema.sh -p postgres_username -o output_dir/ | ||
|
||
NB at the time of writing, this script predates the split into separate `state`/`main` | ||
databases so will require updates to handle that correctly. |
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,37 +1,4 @@ | ||
# Synapse Database Schemas | ||
|
||
This directory contains the schema files used to build Synapse databases. | ||
|
||
Synapse supports splitting its datastore across multiple physical databases (which can | ||
be useful for large installations), and the schema files are therefore split according | ||
to the logical database they are apply to. | ||
|
||
At the time of writing, the following "logical" databases are supported: | ||
|
||
* `state` - used to store Matrix room state (more specifically, `state_groups`, | ||
their relationships and contents.) | ||
* `main` - stores everything else. | ||
|
||
Addionally, the `common` directory contains schema files for tables which must be | ||
present on *all* physical databases. | ||
|
||
## Full schema dumps | ||
|
||
In the `full_schemas` directories, only the most recently-numbered snapshot is useful | ||
(`54` at the time of writing). Older snapshots (eg, `16`) are present for historical | ||
reference only. | ||
|
||
## Building full schema dumps | ||
|
||
If you want to recreate these schemas, they need to be made from a database that | ||
has had all background updates run. | ||
|
||
To do so, use `scripts-dev/make_full_schema.sh`. This will produce new | ||
`full.sql.postgres` and `full.sql.sqlite` files. | ||
|
||
Ensure postgres is installed, then run: | ||
|
||
./scripts-dev/make_full_schema.sh -p postgres_username -o output_dir/ | ||
|
||
NB at the time of writing, this script predates the split into separate `state`/`main` | ||
databases so will require updates to handle that correctly. | ||
This directory contains the schema files used to build Synapse databases. For more | ||
information, see /docs/development/database_schema.md. |
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Fwiw you could remove all the
attr.ib()
here and useauto_attribs=True
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think I didn't know about
auto_attribs
when I first wrote this code...