Re: pg_upgrade --jobs

Поиск
Список
Период
Сортировка
От Sherrylyn Branchaw
Тема Re: pg_upgrade --jobs
Дата
Msg-id CAB_myF6HzMT8j9jfvFasj0G0w1PUfoV3ev5KsB1smum3faUxxg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade --jobs  (senor <frio_cervesa@hotmail.com>)
Ответы Re: pg_upgrade --jobs  (senor <frio_cervesa@hotmail.com>)
Список pgsql-general
are there any shortcuts to upgrading that would circumvent exporting the entire schema?

By "shortcuts," do you mean you want to minimize the time and energy you put into the upgrade, or that you want to minimize database downtime? If you mean downtime, I was able to upgrade a customer-facing database with ~350,000 tables from Postgres 9.0 to 9.6 last year with only 86 seconds of downtime, using Slony, but I had to make many custom modifications to Slony and test thoroughly beforehand, and it was not for the faint of heart, the pressed for time, or the inexperienced. There may be better ways (and if so, I would be curious to learn about them), but Slony was the tool with which I was most familiar at the time.

This method does, of course, require exporting the entire schema, but because our only constraint was to minimize customer downtime, and the database was online while the schema was being exported, we didn't care how long it took. Your constraints may be different.

For those reading: we do know that 350,000 tables is Doing It Wrong, and we're getting rid of them, but we decided being on an EOLed version of Postgres was worse and should be fixed first.

Sherrylyn

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

Предыдущее
От: Pavan Teja
Дата:
Сообщение: Re: Logical replication failed recovery
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Logical replication failed recovery