mirror of
https://github.com/zulip/zulip.git
synced 2026-06-15 21:01:31 +08:00
bf0f712c81
pg_upgradecluster has two possibilities for `--method`: `dump`, and `upgrade`. The former is the default, and does a `pg_dump` of all of the databases in the old cluster and feeds them into the new cluster. This is a sure-fire way of getting the same information in both databases, but may be extremely slow on large databases, and is guaranteed to fail on servers whose databases take up >50% of their disk. The `--method=upgrade` method, by contrast, uses pg_upgrade to copy the raw database data file over to the new cluster, and then fiddles with their internal structure as needed by the upgrade to let them be correct for the new version[1]. This is slightly faster than the dump/load method, since it skips the serialization step, but still requires that there be enough space on disk for both old and new versions at once. `pg_upgrade` is currently supported for all versions of PostgreSQL from 8.4 to 12. Using `pg_upgrade` incurs slightly more risk, but since the it is widely used by now, using it in the relatively-controlled Zulip server environment is reasonable. The expected worst failure is failure to upgrade, not corruption or data loss. Additionally passing `--link` uses hardlinks to link the data files into both the old and new directories simultaneously. This resolve both the runtime of the operation, as well as the disk space usage. The only potential downside to this is that as soon as writes have occurred on the upgraded cluster, the old cluster can no longer be started. Since this tooling intends to remove the old cluster immediately after the upgrade completes successfully, this is not a significant drawback. Switch to using `--method=upgrade --link`. This technique spits out two shell scripts which are expected to be run after completion of the upgrade; one re-analyzes the statistics, the other does an `rm -rf` of the data where it is still hardlinked in the old cluster. Extract the location of these scripts from parsing the `pg_upgradecluster` output; since the path is not static, we must rely on it being relatively easy to parse. The risk of the path changing is lower, and has more obvious failure modes, than inserting the current contents of these upgrade steps into the overall `upgrade-postgres`. [1] https://www.postgresql.org/docs/12/pgupgrade.html |
||
|---|---|---|
| .. | ||
| lib | ||
| nagios | ||
| setup | ||
| __init__.py | ||
| get-django-setting | ||
| purge-old-deployments | ||
| README.md | ||
| refresh-sharding-and-restart | ||
| restart-server | ||
| upgrade-zulip | ||
| upgrade-zulip-from-git | ||
| zulip-puppet-apply | ||
This directory contains scripts that:
-
Generally do not require access to Django or the database (those are "management commands"), and thus are suitable to run operationally.
-
Are useful for managing a production deployment of Zulip (many are also used in a Zulip development environment, though development-only scripts live in
tools/).
For more details, see https://zulip.readthedocs.io/en/latest/overview/directory-structure.html.