Существует три основных способа обновления PostgreSQL с разных основных версий (например, с 9.1 до 9.3).
Обновление с помощью pg_dump
Первый, и рекомендуется, если это возможно, сделать дамп старой (9.1) версии, используя двоичный файл более новой (9.3) версии, и восстановить его на новом кластере, созданном из более новой версии.
Этот подход, как правило, более медленный, но также и наиболее осуществимый. Один совет, чтобы сделать это более быстрым, использует параллелизм. Чтобы создать дамп с параллельными заданиями, вы можете сделать:
$ pg_dump --format=directory --jobs=4 --no-synchronized-snapshots --file=/path/to/mydump mydatabase
Вы должны будете сделать это для каждой имеющейся у вас базы данных, настроить --jobs=4
значение на любое значение (протестируйте некоторые значения от 2 до количества ядер и посмотрите, какая из них дает лучшую скорость). Кроме того, на этом этапе никто не должен подключаться к базе данных, любая модификация приведет к поврежденному дампу (из-за небезопасной опции --no-synchronized-snapshots
).
После этого вы можете восстановить свой дамп в новый экземпляр, используя pg_restore
:
$ createdb <options> -T template0 mydatabase
$ pg_restore --exit-on-error --jobs=4 --dbname=mydatabase /path/to/mydump
После этого рекомендуется запустить ANALYZE
вашу базу данных:
$ vacuumdb --analyze-only mydatabase
(если вы можете позволить себе время, работать только --analyze
также VACUUM
базы данных и обновления карты видимости)
Обновление с помощью pg_upgrade
Другой вариант, это использовать contribpg_upgrade
. Используя этот --link
метод, он обеспечивает действительно быстрый способ обновления PostgreSQL.
Перед использованием вы должны сделать резервную копию всего каталога данных, потому что в --link
режиме, если что-то пойдет не так, вы можете потерять как данные (новые и старые). Также прочтите всю документацию и особенно примечания внизу (есть некоторые ограничения для pg_upgrade).
ОБНОВЛЕНИЕ: Пожалуйста, используйте --check
опцию перед запуском окончательной команды. Также для больших баз данных рекомендуется запускать эту команду в сеансе экрана.
Обновление с использованием инструмента репликации на основе триггера
Другой вариант обновления версии - использование инструмента репликации на основе триггера. Как Слони, Bucardo и Londiste.
Этот вариант требует минимального времени простоя, но над ним труднее всего работать.
Для этого вам нужно построить master-slave, где master - это ваша текущая версия (9.1), а slave - новая версия (9.3). Затем вы ждете первую синхронизацию (с системой, которая еще работает), после чего вы закрываете всех, кто подключен к базе данных (здесь начинается время простоя), ждете, когда ведомое устройство догонит, продвинет его (подчиненное устройство) к управлению и перенаправить всех клиентов / приложений на эту новую версию. И вы сделали.
Документация по Slony предоставляет пошаговое обновление PostgreSQL с использованием Slony .
Какой выбрать
Ну как всегда зависит, возобновим
- Дамп + восстановление является наиболее надежным, но в целом самым медленным (хотя параллелизм может дать довольно хорошие результаты)
- Pg_upgrade является одним из лучших вариантов для небольшого простоя (если вы можете использовать, посмотрите ограничения), он часто занимает всего несколько минут, даже для больших баз данных
- Репликация триггера, без сомнения, дает наименьшее возможное время простоя (около нуля), но это действительно трудно достичь, и я рекомендую это только опытным людям (как на PostgreSQL, так и на инструменте репликации).
Я надеюсь, что смогу помочь. Удачи.