2021-08-10 07:55:12 +02:00
|
|
|
```{eval-rst}
|
2018-01-23 20:36:07 +01:00
|
|
|
:orphan:
|
|
|
|
```
|
|
|
|
|
2017-08-16 22:27:00 +02:00
|
|
|
# Running expensive migrations early
|
|
|
|
|
2018-06-24 16:49:18 +02:00
|
|
|
Zulip 1.7 and 1.9 each contain some significant database migrations
|
|
|
|
that can take several minutes to run.
|
2017-08-16 22:27:00 +02:00
|
|
|
|
2017-10-20 23:21:46 +02:00
|
|
|
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:
|
|
|
|
|
docs: Add missing space to compound verbs “log in”, “set up”, etc.
Noun: backup, checkout, cleanup, login, logout, setup, shutdown, signup,
timeout.
Verb: back up, check out, clean up, log in, log out, set up, shut
down, sign up, time out.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-04-25 23:05:38 +02:00
|
|
|
1. Log in to your Zulip server as the `zulip` user (or as `root` and
|
2021-09-08 00:23:24 +02:00
|
|
|
then run `su zulip` to drop privileges), and
|
|
|
|
`cd /home/zulip/deployments/current`
|
2017-10-20 23:21:46 +02:00
|
|
|
2. Run `./manage.py dbshell`. This will open a shell connected to the
|
2020-10-26 22:27:53 +01:00
|
|
|
PostgreSQL database.
|
|
|
|
3. In the PostgreSQL shell, run the following commands:
|
2017-10-20 23:21:46 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```postgresql
|
|
|
|
CREATE INDEX CONCURRENTLY
|
|
|
|
zerver_usermessage_is_private_message_id
|
|
|
|
ON zerver_usermessage (user_profile_id, message_id)
|
|
|
|
WHERE (flags & 2048) != 0;
|
2018-06-24 16:49:18 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
CREATE INDEX CONCURRENTLY
|
|
|
|
zerver_usermessage_active_mobile_push_notification_id
|
|
|
|
ON zerver_usermessage (user_profile_id, message_id)
|
|
|
|
WHERE (flags & 4096) != 0;
|
|
|
|
```
|
2018-08-02 01:06:14 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
(These first migrations are the only new ones in Zulip 1.9).
|
2018-06-24 16:49:18 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
```postgresql
|
|
|
|
CREATE INDEX CONCURRENTLY
|
|
|
|
zerver_usermessage_mentioned_message_id
|
|
|
|
ON zerver_usermessage (user_profile_id, message_id)
|
|
|
|
WHERE (flags & 8) != 0;
|
2017-10-20 23:21:46 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
CREATE INDEX CONCURRENTLY
|
|
|
|
zerver_usermessage_starred_message_id
|
|
|
|
ON zerver_usermessage (user_profile_id, message_id)
|
|
|
|
WHERE (flags & 2) != 0;
|
2017-10-20 23:21:46 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
CREATE INDEX CONCURRENTLY
|
|
|
|
zerver_usermessage_has_alert_word_message_id
|
|
|
|
ON zerver_usermessage (user_profile_id, message_id)
|
|
|
|
WHERE (flags & 512) != 0;
|
2017-10-20 23:21:46 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
CREATE INDEX CONCURRENTLY
|
|
|
|
zerver_usermessage_wildcard_mentioned_message_id
|
|
|
|
ON zerver_usermessage (user_profile_id, message_id)
|
|
|
|
WHERE (flags & 8) != 0 OR (flags & 16) != 0;
|
2017-10-20 23:21:46 +02:00
|
|
|
|
2021-08-20 07:09:04 +02:00
|
|
|
CREATE INDEX CONCURRENTLY
|
|
|
|
zerver_usermessage_unread_message_id
|
|
|
|
ON zerver_usermessage (user_profile_id, message_id)
|
|
|
|
WHERE (flags & 1) = 0;
|
|
|
|
```
|
2017-10-20 23:21:46 +02:00
|
|
|
|
2018-06-24 16:49:18 +02:00
|
|
|
These will take some time to run, during which the server will
|
|
|
|
continue to serve user traffic as usual with no disruption. Once they
|
|
|
|
finish, you can proceed with installing Zulip 1.7.
|
2017-10-20 23:21:46 +02:00
|
|
|
|
|
|
|
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
|
2018-06-24 16:49:18 +02:00
|
|
|
were run on chat.zulip.org, it had 75M UserMessage rows; the first 5
|
2017-10-20 23:21:46 +02:00
|
|
|
indexes took about 1 minute each to create, and the final,
|
|
|
|
"unread_message" index took more like 10 minutes.
|