Faça uso (temporário) de Armazenamento em Rede para Restaurações, Atualização do PSQL,

Estamos executando uma instalação maior do Discourse em uma configuração de VPS que basicamente funciona muito bem para nós. Em termos de desempenho de CPU/Mem, temos folga. Espaço em disco, no entanto, é um problema - não no dia a dia, mas quando se trata de atualizar o Postgres, por exemplo (a atualização 13->15 está pendente por causa disso), não temos espaço e não podemos expandir facilmente.

Eu sei que existem outras opções para a atualização do postgres, mas considere isso mais como uma pergunta geral.

Estamos rodando na Hetzner, onde o armazenamento de rede está facilmente disponível para uso temporário.

No nosso servidor de teste, estou brincando com a possibilidade de fazê-lo funcionar temporariamente - primeiro para restaurar um backup do site ativo e, posteriormente, para testar a atualização do Postgres. Até agora, não obtive sucesso.

Eu já tentei usar symlinking, mas percebi que não funcionou e também li em algum lugar que não é a maneira recomendada. Também tentei mover o compartilhamento /shared de /var/discourse/shared/standalone para /mnt/ext-storage/standalone e movi os arquivos para lá - infelizmente, não sem problemas. Nem consigo terminar a construção.

Existe alguma maneira que funcione para esses tipos de casos? Estou ciente de que o desempenho da unidade é muito pior do que a unidade local, mas não estou planejando executar o fórum nela. Eu realmente gostaria de ter uma maneira confortável de usá-la para certos cenários.

Se o seu objetivo é fazer a atualização, a coisa mais fácil é iniciar uma nova VM e migrar para ela. Você pula a necessidade de atualizar o banco de dados e obtém um novo SO em sua VM, o que você provavelmente precisará fazer de qualquer maneira.

Siga Mover um site Discourse para outro VPS com rsync e não copie o banco de dados (mas sim uploads, let’s encrypt e certificados.

Se seus backups estiverem no s3, é muito simples congelar o antigo, fazer um backup e restaurar o backup na nova máquina.

Se o hetzner tiver algum tipo de IP permanente que possa ser atribuído a servidores diferentes, você nem precisará alterar o DNS.

Você vai querer saber que pode construir um novo servidor para que, se algum dia precisar por algum motivo, você consiga. Esta é uma chance perfeita para praticar.

Na verdade, esta não é uma opção. De qualquer forma, não está ficando sem espaço para as necessidades do dia a dia. Além disso, estamos em um espaço de disco de 600 GB no momento e usando ~50%. Não há uma opção maior - pelo menos não na Hetzner.

É por isso que eu estava explicitamente pedindo o disco externo.

Você executou um ./launcher cleanup app por curiosidade? Isso não liberou espaço suficiente para realizar a atualização no local?

1 curtida

Isso deveria importar para uma reconstrução? Para uma simples reinicialização eu entenderia, mas para uma reconstrução?

Eu não estava sugerindo mudar para um disco maior, apenas obter um novo servidor exatamente como aquele. Instale o Discourse, restaure seu banco de dados.

Essa é uma pergunta muito boa.

Sim. Cada reconstrução cria um novo contêiner e cada um deles ocupa espaço. Se você nunca fez isso, poderia liberar dezenas de GB.

1 curtida

Para a atualização do banco de dados, você precisa de todo o espaço que puder obter. Então, sim. Eu diria que é importante.

Nosso guia de atualização inclui um guia para o seu caso de uso exato.

Adicionamos essa opção para pessoas que estão na mesma situação que você. Apenas certifique-se de armazenar um backup fora do local antes de tentar isso!

2 curtidas

Se você estiver em uma VM, é muito, muito mais fácil simplesmente mudar para uma nova, e há muitos benefícios. Aqui estão alguns:

  • risco zero - se algo der errado, você ainda tem seu servidor antigo
  • zero tempo de inatividade (apenas leitura no servidor antigo)
  • você obtém a atualização do sistema operacional que provavelmente precisa de qualquer maneira
  • você pode verificar se sabe como iniciar um novo servidor caso a calamidade ocorra
  • você não precisa reindexar e fazer vácuo
1 curtida

Agradeço o conselho, pessoal.

Obrigado, essa é a outra opção que eu disse que estava ciente. Obrigado de qualquer forma por apontá-la.

Não duvido disso - ainda adoraria explorar a opção de adicionar armazenamento adicional para tarefas de manutenção, se necessário.

2 curtidas

Pode ser útil manter seus uploads, ou, digamos, /var/discourse/shared/web_only em armazenamento de rede. Você precisa editar o arquivo yml para apontar para ele em vez de usar um link simbólico (o link simbólico não funciona porque o contêiner não consegue acessar o local para o qual seu link simbólico aponta).

Então, se você mudar para uma nova VM, poderá apenas remontar esse armazenamento de rede em vez de copiá-lo.

Não recomendo armazenamento de rede para o banco de dados, pois é mais lento.

1 curtida

Acho que vale a pena detalhar o que está sendo usado. O tamanho real do seu banco de dados pode não ser tão grande, se a maior parte do seu uso for de uploads, e é apenas a parte do banco de dados que exige talvez 3x o espaço durante a atualização.

Uma coisa que você pode verificar é o tamanho relativo de um backup com downloads em comparação com um backup sem downloads.

Ou, use a linha de comando. Aqui está uma saída do meu fórum, bastante pequeno:

root@rc-debian-hel:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            3813        1631         267         492        1915        1504
Swap:           4095         730        3365
root@rc-debian-hel:~# swapon
NAME                       TYPE  SIZE   USED PRIO
/var/local/swap/swapfile.1 file 1024M 730.2M   -2
/var/local/swap/swapfile.3 file 1024M 136K   -3
/var/local/swap/swapfile.0 file 1024M     0B   -4
/var/local/swap/swapfile.2 file 1024M     0B   -5
root@rc-debian-hel:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           382M  1.2M  381M   1% /run
/dev/sda1        38G   22G   14G  62% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      253M  6.3M  246M   3% /boot/efi
overlay          38G   22G   14G  62% /var/lib/docker/overlay2/68abab42f48040e0dfc03d3c9fc893dfa3e7fb01ba1b2215731668339bbc3766/merged
tmpfs           382M     0  382M   0% /run/user/0

Olhando mais de perto:

root@rc-debian-hel:~# du -kx / | sort -n | tail -33
767000	/var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse/.local/share/pnpm
767004	/var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse/.local/share
767020	/var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse/.local
795804	/var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse
795808	/var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home
833836	/var/discourse/shared/standalone/postgres_data
884648	/var/discourse/shared/standalone/uploads/default/original
978000	/usr/lib/modules
991644	/var/lib/docker/overlay2/68abab42f48040e0dfc03d3c9fc893dfa3e7fb01ba1b2215731668339bbc3766/diff
991664	/var/lib/docker/overlay2/68abab42f48040e0dfc03d3c9fc893dfa3e7fb01ba1b2215731668339bbc3766
1025164	/var/discourse/shared/standalone/uploads/default/optimized
1146528	/usr/lib/firmware
1350496	/var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff
1350512	/var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554
1909816	/var/discourse/shared/standalone/uploads/default
1919380	/var/discourse/shared/standalone/uploads
2471968	/usr/lib
2506940	/var/log/journal/82e4cf9bff9748d090b41e6d336353eb
2515140	/var/log/journal
2592200	/var/log
3029428	/usr
3839148	/var/discourse/shared/standalone/backups/default
3839152	/var/discourse/shared/standalone/backups
4194324	/var/local/swap
4194328	/var/local
5171844	/var/lib/docker/overlay2
5217052	/var/lib/docker
5455612	/var/lib
6682972	/var/discourse/shared/standalone
6682976	/var/discourse/shared
6685716	/var/discourse
19041368	/var
23037264	/
root@rc-debian-hel:~# du -kx /var/discourse/shared/ | sort -n | tail -33
42312	/var/discourse/shared/standalone/uploads/default/original/2X/f
42448	/var/discourse/shared/standalone/uploads/default/original/2X/1
42548	/var/discourse/shared/standalone/uploads/default/original/2X/6
43380	/var/discourse/shared/standalone/uploads/default/optimized/2X/2
44148	/var/discourse/shared/standalone/uploads/default/optimized/2X/5
44340	/var/discourse/shared/standalone/uploads/default/optimized/2X/1
45240	/var/discourse/shared/standalone/uploads/default/optimized/2X/e
46648	/var/discourse/shared/standalone/uploads/default/optimized/2X/c
49516	/var/discourse/shared/standalone/uploads/default/optimized/2X/8
49772	/var/discourse/shared/standalone/uploads/default/optimized/2X/9
49932	/var/discourse/shared/standalone/log/var-log/nginx
50788	/var/discourse/shared/standalone/uploads/default/optimized/2X/0
55428	/var/discourse/shared/standalone/uploads/default/optimized/2X/d
55844	/var/discourse/shared/standalone/uploads/default/optimized/2X/f
57548	/var/discourse/shared/standalone/uploads/default/optimized/2X/6
77280	/var/discourse/shared/standalone/log/var-log
81928	/var/discourse/shared/standalone/postgres_data/pg_wal
84064	/var/discourse/shared/standalone/log
294384	/var/discourse/shared/standalone/uploads/default/optimized/1X
325068	/var/discourse/shared/standalone/uploads/default/original/1X
559576	/var/discourse/shared/standalone/uploads/default/original/2X
724684	/var/discourse/shared/standalone/postgres_data/base/16384
730776	/var/discourse/shared/standalone/uploads/default/optimized/2X
749424	/var/discourse/shared/standalone/postgres_data/base
833836	/var/discourse/shared/standalone/postgres_data
884648	/var/discourse/shared/standalone/uploads/default/original
1025164	/var/discourse/shared/standalone/uploads/default/optimized
1909816	/var/discourse/shared/standalone/uploads/default
1919380	/var/discourse/shared/standalone/uploads
3839148	/var/discourse/shared/standalone/backups/default
3839152	/var/discourse/shared/standalone/backups
6682972	/var/discourse/shared/standalone
6682976	/var/discourse/shared/
2 curtidas

Eu deveria ter sido mais preciso inicialmente, mas não esperava receber um feedback tão amplo.

Nossos uploads e backups estão no S3. O tamanho do banco de dados no sistema ativo é de cerca de 230 GB agora. Os backups compactados têm cerca de 25 GB, eu acho.

4 curtidas

Uau, esse é um dos grandes! Nesse tamanho, a operação do banco de dados é geralmente um pouco mais problemática mesmo.

2 curtidas

E aí. Você aspirou o chão ultimamente?

Não, eu tinha a impressão de que o autovacuum deveria cuidar disso? Não?

Eu acho que deveria. Não está claro o que o aciona. Acho que fazer um extra não prejudica e pode economizar algum espaço. É recomendado após a atualização se você a fizer no local. Já vi limpar um espaço considerável algumas vezes.

Se o seu banco de dados tem 230 GB, eu definitivamente o restauraria em um novo servidor. O tempo de inatividade para ler e escrever 230 GB será significativo.

1 curtida