Clarification on using pg_upgrade

Поиск
Список
Период
Сортировка
От Tory M Blue
Тема Clarification on using pg_upgrade
Дата
Msg-id CAEaSS0atiPVYLhMSwtzcZB5efeTxYjYDR1s3OZSshpkAY1VsAg@mail.gmail.com
обсуждение исходный текст
Ответы Re: Clarification on using pg_upgrade
Список pgsql-performance
Howdy

Postgres9.2 going to 9.4
CentOS 6.5

So in most of my environments, I use slony and thus use slony replication for my upgrades (Drop/add nodes etc).

But I've got a pretty big DB  just shy of a TB that is on a single node. A dump restore would take over 48 hours because of index creations etc, so thought maybe I would look at doing a upgrade via pg_upgrade.

There are some challenges, since I build my rpm's to a standard directory for binaries and then the data directory. So I will have to move/rename directories, but when that's done, I'm slightly confused on the pg_upgrade using link options.

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.

I'm nervous about using pg_upgrade but it's really tough to recover from the jobs that backup during a dump/restore process (2-3 days), so really trying to wrap my head around pg_upgrade..

Suggestions, opinions on pg_upgrade vs dump/restore, the filesystem/mount below is what I'm working with.

Filesystem                       Size  Used Avail Use% Mounted on

/dev/sda6                        4.0T  1.1T  2.8T  29% /data


Thanks
Tory

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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Odd behavior with indices
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Clarification on using pg_upgrade