19.6. Оновлення кластера Postgres Pro
У цьому розділі розповідається, як оновити ваш кластер бази даних з однієї версії Postgres Pro на іншу.
Основні версії Postgres Pro представляються першими двома групами цифр в повній версії, наприклад, 8.4. Коригувальні випуски Postgres Pro представляються третьою групою цифр, наприклад, 8.4.2 - другий коригувальний випуск версії 8.4. В коригувальних випусках ніколи не змінюється внутрішній формат зберігання і вони завжди сумісні з попередніми і наступними випусками тієї ж основної версії, наприклад випуск 8.4.2 сумісний з 8.4, 8.4.1 та 8.4.6. Для оновлення версії на сумісну досить просто замінити виконувані файли при вимкненому сервері і потім запустити сервер. Каталог даних при цьому не зачіпається, так що оновити коригувальну версію досить просто.
При оновленні основних версій Postgres Pro внутрішній формат даних може змінюватися, що ускладнює процедуру оновлення. Традиційний спосіб перенесення даних в нову основну версію - вивантажити дані зі старої версії, а потім завантажити їх в нову (це не найшвидший варіант). Виконати оновлення швидше дозволяє pg_upgrade. Також для оновлення можна використовувати реплікацію, як описано нижче.
Зміни основною версією зазвичай приносять будь-які видимі користувачеві несумісності, які можуть вимагати доопрацювання додатків. Всі подібні зміни описуються в зауваженнях до випуску (Додаток E); звертайте особливу увагу на розділ «Migration» (Міграція). Якщо при оновленні ви пропускаєте кілька основних версій, обов'язково прочитайте примітки до випуску, в тому числі і для кожної пропускається версії.
Обережні користувачі зазвичай тестують свої клієнтські програми з новою версією, перш ніж переходити на неї повністю; тому часто має сенс встановити поруч стару і нову версії. При тестуванні поновлення основною версією Postgres Pro вивчіть наступні області можливих змін:
Засоби і функції, що надаються адміністраторам для спостереження і керування сервером, часто змінюються і удосконалюються в кожній новій версії. SQL
У цій області частіше спостерігається поява нових можливостей команд SQL, ніж зміна поведінки існуючих, якщо тільки про це ані слова в зауваженнях до випуску. API бібліотек
Зазвичай бібліотеки типу libpq тільки розширюють свою функціональність, якщо про зворотне так само не йдеться в зауваженнях до випуску. Системні каталоги
Зміни в системних каталогах зазвичай впливають тільки на кошти управління базами даних. API сервера для коду на C
Сюди відносяться зміни в API серверних функцій, які написані на мові програмування C. Такі зміни зачіпають код, який звертається до службових функцій глибоко всередині сервера.
19.6.1. Ефективно використовувати час із застосуванням pg_dumpall
У наступних вказівках передбачається, що сервер встановлений в каталозі / usr / local / pgsql. а дані знаходяться в / usr / local / pgsql / data. Вам потрібно підставити свої шляхи.
При запуску резервного копіювання переконайтеся в тому, що в базі даних не виробляються зміни. Зміни не вплинуть на цілісність отриманої копії, але змінені дані, само собою, в неї не потраплять. Якщо буде потрібно, змініть дозволу в файлі /usr/local/pgsql/data/pg_hba.conf (або подібному), щоб підключитися до сервера могли тільки ви. Щоб отримати додаткові відомості про управління доступом зверніться до Глави 21.
Щоб отримати копію всіх ваших даних, введіть:
Для створення резервної копії ви можете скористатися програмою pg_dumpall від поточної версії сервера; за подробицями зверніться до Підрозділу 26.1.2. Однак для кращого результату варто спробувати pg_dumpall з Postgres Pro 9.6.5.1, так як в цю версію увійшли виправлення помилок і удосконалення, в порівнянні з попередніми версіями. Хоча ця рада може здатися абсурдним, адже нова версія ще не встановлена, йому варто піти, якщо ви плануєте встановити нову версію поруч зі старою. В цьому випадку ви зможете виконати установку як зазвичай, а перенести дані пізніше. Це також скоротить час оновлення.Зупиніть старий сервер:
В системах, де Postgres Pro запускається при завантаженні, повинен бути скрипт запуску, з яким можна зробити те ж саме. Наприклад, в Red Hat Linux може спрацювати такий варіант:
Детальніше запуск і зупинка сервера описані в Главі 19.При відновленні з резервної копії видаліть або перейменуйте старий каталог, де був встановлений сервер, якщо його ім'я не прив'язане до версії. Розумніше буде перейменувати каталог, а не видаляти його, щоб його можна було відновити в разі проблем. Однак врахуйте, що цей каталог може займати багато місця на диску. Перейменувати каталог можна, наприклад так:
(Цей каталог потрібно перейменовувати (переміщати) як єдине ціле, щоб відносні шляхи в ньому не змінилися.)Нарешті, відновіть дані з резервної копії, виконавши:
(При цьому буде використовуватися новий psql.)
Мінімізувати час відключення сервера можна, встановивши новий сервер в інший каталог і запустивши паралельно обидва сервера, старий і новий, з різними портами. Потім можна буде перенести дані приблизно так:
19.6.2. Ефективно використовувати час із застосуванням pg_upgrade
Модуль pg_upgrade дозволяє оновити інсталяцію Postgres Pro з однієї основної версії на іншу безпосередньо на місці. Таке оновлення може виконуватися за лічені хвилини, особливо в режимі --link. Для нього потрібні приблизно ті ж підготовчі дії, що і для варіанту з pg_dumpall. запустити / зупинити сервер, виконати initdb. Всі ці дії описані в документації pg_upgrade.
19.6.3. Ефективно використовувати час із застосуванням реплікації
Також можна використовувати деякі методи реплікації, наприклад Slony. для створення резервного сервера з оновленою версією Postgres Pro. Це можливо завдяки тому, що Slony підтримує реплікацію між різними основними версіями Postgres Pro. Резервний сервер може розташовуватися як на одному комп'ютері, так і на іншому. Як тільки синхронізація з головним сервером (де працює стара версія Postgres Pro) буде завершена, можна зробити головним новий сервер, а старий екземпляр бази даних просто відключити. При такому перемиканні оновлення можна здійснити, перервавши роботу сервера всього на кілька секунд.