В основному є три способи оновлення 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
опцію перед запуском остаточної команди. Також для великих баз даних рекомендується запустити цю команду на екрані сеансу.
Оновлення за допомогою інструмента реплікації на основі тригера
Інший варіант оновлення версії - використання інструменту реплікації на основі тригера. Як Слоні, Букардо та Лондісте.
Це варіант, який вимагає найменшого можливого простою, але це найскладніший варіант роботи.
Для цього вам потрібно створити ведучий підлеглий, де ведучим є ваша поточна версія (9.1), а підлеглий - нова версія (9.3). Потім зачекайте першої синхронізації (із системою, яка все ще знаходиться у виробництві), після чого ви закриєте всіх, підключених до бази даних (час простою починається тут), дочекаєтеся, коли підлеглий досягне, просуває його (підлеглий) для освоєння та перенаправити всіх клієнтів / програм на цю нову версію. І ви закінчили.
Документація Slony забезпечує покрокове оновлення PostgreSQL за допомогою Slony .
Який вибрати
Ну, як завжди залежить, відновлення:
- Дамп + відновлення є найнадійнішим, але, як правило, найбільш повільним (паралелізм може дати досить хороші результати)
- Pg_upgrade - це один з найкращих варіантів для невеликих простоїв (якщо ви можете використовувати, дивіться обмеження), це часто займає лише кілька хвилин, навіть для великих баз даних
- Реплікація тригера, без сумніву, є тим, що дає найменший можливий час простою (біля нуля), але це дійсно важко досягти, і я рекомендую лише досвідченим людям (як на PostgreSQL, так і на інструменті реплікації).
Сподіваюся, я міг допомогти. Удачі.