sharding: Add basic sharding configuration for Tornado.

This allows straight-forward configuration of realm-based Tornado
sharding through simply editing /etc/zulip/zulip.conf to configure
shards and running scripts/refresh-sharding-and-restart.

Co-Author-By: Mateusz Mandera <mateusz.mandera@zulip.com>
This commit is contained in:
Tim Abbott
2018-11-06 17:13:37 -08:00
committed by Tim Abbott
parent cdd3b7efbc
commit 220620e7cf
9 changed files with 126 additions and 4 deletions

View File

@@ -0,0 +1,29 @@
#!/usr/bin/env bash
set -e
"$(dirname "$0")/zulip-puppet-apply" -f
# The step above should have generated the config files, now we need to move them into place:
chown root:root /etc/zulip/nginx_sharding.conf.tmp
chmod 640 /etc/zulip/nginx_sharding.conf.tmp
chown zulip:zulip /etc/zulip/sharding.json.tmp
chmod 640 /etc/zulip/sharding.json.tmp
mv /etc/zulip/nginx_sharding.conf.tmp /etc/zulip/nginx_sharding.conf
mv /etc/zulip/sharding.json.tmp /etc/zulip/sharding.json
# In the ordering of operations below, the crucial detail is that
# zulip-django and zulip-workers:* need to be restarted before
# reloading nginx. Django has an in-memory map of which realm belongs
# to which shard. Reloading nginx will cause users' tornado requests
# to be routed according to the new sharding scheme. If that happens
# before Django is restarted, updating its realm->shard map, users on
# realms, whose shard has changed, will have their tornado requests
# handled by the new tornado process, while Django will still use the
# old process for its internal communication with tornado when
# servicing the user's requests. That's a bad state that leads to
# clients getting into reload loops ending in crashing on 500 response
# while Django is restarting. For this reason it's important to
# reload nginx only after Django.
supervisorctl restart zulip-django
supervisorctl restart zulip-workers:*
service nginx reload