Re: Clarification on using pg_upgrade

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: Clarification on using pg_upgrade
Дата
Msg-id 20160304225811.GE865@telsasoft.com
обсуждение исходный текст
Ответ на Clarification on using pg_upgrade  (Tory M Blue <tmblue@gmail.com>)
Ответы Re: Clarification on using pg_upgrade
Список pgsql-performance
On Fri, Mar 04, 2016 at 02:27:59PM -0800, Tory M Blue wrote:
> If my data is located in /data
>
> and I link to a new dir in /data1,  what actually happens. do I end up with
> 2 file systems and links and thus am not able to delete or cleanup any old
> data, or how does this work?
>
> Also will the reindex creation still happen with this type of in-place
> upgrade, as if so, then it may not save too much time vs a dump/import.

Since you have the space, you can do a test upgrade; make a dump of the
essential tables (or the entire thing) and restore it to another instance,
perhaps even something run from your /home.

pg_upgrade --link makes hardlinks for tables and indices (same as cp -l), so
uses very little additional space.  Note, that means that both must be within
the filesystem (/data).  You should understand about hardinks and inodes
otherwise this will lead to confusion and mistakes.

Indexes don't need to be rebuilt afterwards.  I've upgraded ~35 customers to
9.5 already, some as big as 5TB.  So far the disruption has been at most 30min
(not counting ANALYZE afterwards).

When I use pg_upgrade, after stopping the old instance, I rename the data dir
(under centos, /var/lib/pgsql/9.4~).  Then pg_upgrade makes links in 9.5/.
Renaming has the advantage that the old instances can't be accidentally
started; and, makes it much easier to believe that it's safe to remove the 9.4~
afterwards.

Justin


В списке pgsql-performance по дате отправления:

Предыдущее
От: Tory M Blue
Дата:
Сообщение: Clarification on using pg_upgrade
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Odd behavior with indices