Postgres 升级:空间极其有限

The documented procedure on the forums lists two methods of upgrading Postgres.

  1. Just let Discourse handle it. This requires 3 times the disk space. So if your DB is 100GB, you would need an additional 200GB free to do the upgrade. Obviously a huge problem for people with large installs.
  2. Follow their “manual update” procedure. This requires 2 times the disk space, so if your DB is 100GB you would need an additional 100GB free. This is also a big problem for some.

In this post, @Falco suggested using the --link option to do the upgrade in-place using hard links. The docker container they suggest using supports that argument, but Discourse devs don’t suggest using it in the post.

So my question is this, should option 3 be:

  1. Run the command below, which will require a very small amount of additional disk space. So if your DB is 100GB, it might require, say, an additional 10GB? And if so, is this a recommended procedure by the Discourse devs, and has anyone actually done it before and lived to tell the tale?

New command to upgrade in-place:

docker run --rm \
	-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
	tianon/postgres-upgrade:12-to-13 \
	--link

 

Compared to the old command to upgrade into a new directory (requiring double the space):

docker run --rm \
	-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/12/data \
	-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/13/data \
	tianon/postgres-upgrade:12-to-13

P.S.: I would have just replied to that PG13 upgrade thread, but it deletes posts after 7 days. Why do you have it configured that way? I know there was a lot of discussion when this first came up that would have been useful for reference.

1 个赞

If they have, they didn’t mention it here. Mostly instrucions here try to be as foolproof as possible and require as little system adminstration knowledge as possible. Most people here woud rather do something the safest, most tested way possible than some way designed to save a very few dollars.

If it works for you, you can update PostgreSQL 13 update accordingly, but before you do, do you feel comfortable recommending to someone who doesn’t know what bash is that they do it that way? You’re sure that it won’t hose their database and their site will be ruined forever?

The idea is that if some other good information is presented that it be added to the OP rather than asking people to read through year’s worth of posts that are likely to be unhelpful or wrong.

1 个赞

No I’m not sure, I don’t have much experience with postgres and was hoping one of the discourse devs could provide some assurances it would work.

Even if it does work I also wouldn’t recommend it as the default upgrade procedure as the old way keeps a separate copy of the DB for rollback. If it works it would be a great option for space-constrained environments though.

Another easy way is to spin up a new server, migrate the data, and turn off the old one. If you must use the old one, do the upgrade on a temporary server, so a fresh install on the original server (which probably needs an OS upgrade) and move it back.

That’s safe, easy, and well documented. Hundreds of people have done that.

Yes, but that would take a day or two. During that time we could either a) tell users their posts during this period will be lost or b) set the forum read-only. Neither is a great solution.

1 个赞

I don’t think that the server would be down a whole lot longer than during the rebuild. And if you move to the new server and stay there, you can leave the old server in read only mode while you make the move. If downtime is your concern then moving to a new server will be much, much better.

1 个赞

We have a pretty big forum, but I’ve never tried restoring a backup so I don’t know how long it would take. We would indeed stay on the new host if we did it. I would like to avoid that due to the extra work/annoyance if possible.

1 个赞

Yup, as I originally suggested here Discourse on postgres 12 breaks upgrades - #8 by merefield

I’d just bite the bullet?

1 个赞

All my posts here have been in an ongoing attempt to avoid doing that.

@Wingtip,你升级过这个吗?

1 个赞

解决空间有限的升级问题的另一种方法是进行备份,删除(rm - r)postgres目录,重新构建,然后恢复备份。我上周在一个站点上这样操作过。

2 个赞

备份占用的空间几乎和复制数据目录一样多(甚至更多,因为它还需要压缩)?

1 个赞

不,从未成功升级。删除数据库并恢复备份听起来风险很大。我们基本上需要就地升级才能奏效。

我们目前运行的是 Ubuntu 18.04,它将在 2023 年停止支持,所以我想届时我们别无选择,只能迁移到新主机,并计划在那时下定决心,构建一台运行 22.04 LTS 的新主机,并从备份恢复。

嗯。可能是白费力气。我认为使用备份模型,其中一个副本被压缩了,这可能会产生影响?我进行操作的网站在 S3 上有备份。而且它是一个测试网站,所以如果出现问题,风险很低。

除了备份的使用频率比就地升级高得多,使用场景也多得多。我认为它安全得多。

1 个赞

也许可以,但我对 PostgreSQL 的专业知识不多,做起来不放心。不过,从备份中恢复整个站点到一个完全不同的虚拟机,我倒是很在行,但这会意味着丢失几个小时的帖子,直到恢复完成,所以我对此也不是特别热衷。但由于 18.04 即将被停止支持,明年我将别无选择。

1 个赞

除非你的数据库有几十GB,否则不会花费数小时。而且你在备份和恢复之前会把论坛设为只读模式,所以你不会丢失任何帖子。这并不难做到,几乎没有停机时间,只有只读时间。

root@forum-app:/shared/postgres_data# du -sh
97G     .

我不会将其设为只读,而是会发布一个横幅,告知人们他们今天的帖子是短暂的。在我看来,最好让他们就此聊天,即使那些帖子会丢失。

1 个赞

届时,您还将可以使用内置的 Discourse 聊天功能,该功能将在 2.9 版本中发布(可能默认关闭,但处于测试阶段并支持使用)。

3 个赞