paulmataruso/zulip
1
0
Fork 0
mirror of https://github.com/zulip/zulip.git synced 2025-11-06 15:03:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs/expensive-migrations: Revise a bit for clarity.

Browse Source 
Borrows some language from the paragraph in the changelog that
points to it.
This commit is contained in:
Greg Price
2017-10-20 14:21:46 -07:00
parent 4418425c10
commit 12f8ec780e
1 changed files with 39 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
docs/expensive-migrations.md
View File

@@ -1,48 +1,52 @@
# Running expensive migrations early # Running expensive migrations early
If you'd like to run the major database migrations included in the Zulip 1.7 contains some significant database migrations that can take
Zulip 1.7 release early, before you start the upgrade process, you can several minutes to run.
do the following:
* Log into your zulip server as the `zulip` user (or as `root` and The upgrade process automatically minimizes disruption by running
these first, before beginning the user-facing downtime. However, if
you'd like to watch the downtime phase of the upgrade closely, you
can run them manually before starting the upgrade:
1. Log into your Zulip server as the `zulip` user (or as `root` and
then run `su zulip` to drop privileges), and `cd then run `su zulip` to drop privileges), and `cd
/home/zulip/deployments/current` /home/zulip/deployments/current`
* Run `./manage.py dbshell`. This will open a shell connected to the 2. Run `./manage.py dbshell`. This will open a shell connected to the
Postgres database. Postgres database.
* In the postgres shell, run the following commands: 3. In the postgres shell, run the following commands:
``` CREATE INDEX CONCURRENTLY
CREATE INDEX CONCURRENTLY zerver_usermessage_mentioned_message_id
zerver_usermessage_mentioned_message_id ON zerver_usermessage (user_profile_id, message_id)
ON zerver_usermessage (user_profile_id, message_id) WHERE (flags & 8) != 0;
WHERE (flags & 8) != 0;
CREATE INDEX CONCURRENTLY CREATE INDEX CONCURRENTLY
zerver_usermessage_starred_message_id zerver_usermessage_starred_message_id
ON zerver_usermessage (user_profile_id, message_id) ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 2) != 0; WHERE (flags & 2) != 0;
CREATE INDEX CONCURRENTLY CREATE INDEX CONCURRENTLY
zerver_usermessage_has_alert_word_message_id zerver_usermessage_has_alert_word_message_id
ON zerver_usermessage (user_profile_id, message_id) ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 512) != 0; WHERE (flags & 512) != 0;
CREATE INDEX CONCURRENTLY CREATE INDEX CONCURRENTLY
zerver_usermessage_wildcard_mentioned_message_id zerver_usermessage_wildcard_mentioned_message_id
ON zerver_usermessage (user_profile_id, message_id) ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 8) != 0 OR (FLAGS & 16) != 0; WHERE (flags & 8) != 0 OR (flags & 16) != 0;
CREATE INDEX CONCURRENTLY CREATE INDEX CONCURRENTLY
zerver_usermessage_unread_message_id zerver_usermessage_unread_message_id
ON zerver_usermessage (user_profile_id, message_id) ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 1) = 0; WHERE (flags & 1) = 0;
```
Once these have finished, you can proceed with installing zulip 1.7. 4. These will take some time to run, during which the server will
continue to serve user traffic as usual with no disruption. Once
To help you estimate how long these will take on your server, creating they finish, you can proceed with installing Zulip 1.7.
the first 4 indexes took about 1 minute each with chat.zulip.org's 75M
UserMessage rows (from `select COUNT(*) from zerver_usermessage;` in
the `manage.py dbshell`), with no user-facing service disruption. The
final, "unread_message" index took more like 10 minutes.
To help you estimate how long these will take on your server: count
the number of UserMessage rows, with `select COUNT(*) from zerver_usermessage;`
at the `./manage.py dbshell` prompt. At the time these migrations
were run on chat.zulip.org, it had 75M UserMessage rows; the first 4
indexes took about 1 minute each to create, and the final,
"unread_message" index took more like 10 minutes.