paulmataruso/zulip
1
0
Fork 0
mirror of https://github.com/zulip/zulip.git synced 2025-11-04 05:53:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: Clean up release notes for the Zulip 1.7 release.

Browse Source 
Now that we have the expensive migrations running automatically early
in the process, we can drop them to more of a footnote.
This commit is contained in:
Tim Abbott
2017-08-16 13:27:00 -07:00
parent d43f5ceeec
commit 4ce079b689
2 changed files with 55 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
docs/changelog.md
View File

@@ -35,43 +35,13 @@ Highlights:
Release notes:
* There are some significant database migrations that will be in the
next release that can take a long time to run. Fortunately, these can
be run without downtime before the rest of the upgrade, by using the
following postgres queries (run these inside `manage.py dbshell`):
```
CREATE INDEX CONCURRENTLY
zerver_usermessage_mentioned_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 8) != 0;
CREATE INDEX CONCURRENTLY
zerver_usermessage_starred_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 2) != 0;
CREATE INDEX CONCURRENTLY
zerver_usermessage_has_alert_word_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 512) != 0;
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;
CREATE INDEX CONCURRENTLY
zerver_usermessage_unread_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 1) = 0;
```
For context on the impact of running these migrations, creating the
first few indexes took about 1 minute each with chat.zulip.org's 75M
UserMessage rows (from `select COUNT(*) from zerver_usermessage;`),
with no user-facing service disruption. The unread index took more
like 10 minutes.
next release that can take several minutes to run. These migrations
will be automatically run during the upgrade process, but before
user-facing downtime begins to avoid disruption. However, if you'd
like to watch the downtime part of the upgrade process carefully, we
recommend
[running these migrations manually](expensive-migrations.html) before
starting the upgrade.
Full feature Changelog:

48
docs/expensive-migrations.md Normal file
View File

@@ -0,0 +1,48 @@
# Running expensive migrations early
If you'd like to run the major database migrations included in the
Zulip 1.7 release early, before you start the upgrade process, you can
do the following:
* Log into your zulip server as the `zulip` user (or as `root` and
then run `su zulip` to drop privileges), and `cd
/home/zulip/deployments/current`
* Run `./manage.py dbshell`. This will open a shell connected to the
Postgres database.
* In the postgres shell, run the following commands:
```
CREATE INDEX CONCURRENTLY
zerver_usermessage_mentioned_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 8) != 0;
CREATE INDEX CONCURRENTLY
zerver_usermessage_starred_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 2) != 0;
CREATE INDEX CONCURRENTLY
zerver_usermessage_has_alert_word_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 512) != 0;
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;
CREATE INDEX CONCURRENTLY
zerver_usermessage_unread_message_id
ON zerver_usermessage (user_profile_id, message_id)
WHERE (flags & 1) = 0;
```
Once these have finished, you can proceed with installing zulip 1.7.
To help you estimate how long these will take on your server, creating
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.