PostgreSQL 9.6 току-що беше пуснат и повечето потребители на postgres ще започнат да се питат как да надстроят до новата основна версия. Тази публикация има за цел да покаже различни процедури за надграждане на вашия PostgreSQL сървър.
Надстройката до нова основна версия е задача, която има високо съотношение на подготовка към общото време за изпълнение. По-специално, когато пропуснете версия в средата, например, когато прескачате от версия 9.3 към версия 9.5.
Освобождаване на точки
От друга страна, надстройките за освобождаване на точки не се нуждаят от толкова много подготовка. По принцип единственото изискване е услугата postgres да бъде рестартирана. Няма промени в основната структура на данните, така че няма нужда от изхвърляне и възстановяване. В най-лошия случай може да се наложи да пресъздадете някои от вашите индекси, след като приключите с надграждането на версията на точката.
Много е разумно винаги да оставате на последната версия на точката, за да не се натъкнете на известна (и вероятно коригирана) грешка. Това означава, че след като най-новата версия излезе, насрочете време за надстройка възможно най-скоро.
Основна надстройка на версията
Когато изпълнявате сложни задачи като тази, е добре да обмислите всички възможни варианти за постигане на крайния резултат.
За големи надстройки на версията има три възможни пътя, по които можете да поемете:
- Възстановяване на надстройка от логическо сметище
- Физическо надграждане
- Онлайн надстройка
Нека обясня всеки от тях подробно:
1) Възстановяване на надстройка от логическо сметище
Това е най-простият от всички възможни начини за надграждане на структурата на данните на вашия клъстер.
За да бъде кратък, процесът тук изисква логическо изхвърляне, като се използва pg_dump от старата версия и pg_restore в чист клъстер, създаден с новоинсталираната версия.
Ключови точки в полза на използването на този път са:
- Това е най-тестваното
- Съвместимостта се връща към версии 7.0, така че евентуално да можете да надстроите от 7.x до една от последните версии
Причини, поради които трябва да избягвате използването на тази опция:
- Общото време на прекъсване на големи бази данни може да бъде проблем, тъй като трябва да спрете връзките за запис, преди да започнете да изпълнявате pg_dump;
- Ако има много големи обекти в базата данни, pg_dump ще бъде бавен. Дори когато го правите паралелно. Възстановяването ще бъде дори по-бавно от pg_dump, когато в базата данни се съхраняват много големи обекти;
- Изисква двойно дисково пространство или премахване на стария клъстер преди възстановяване;
На сървъри с няколко ядра на процесора е възможно да стартирате pg_dump паралелно, като използвате формата на директорията. След като приключи, възстановете и паралелно, като използвате превключвателя -j както в pg_dump, така и в pg_restore. Но не можете да започнете процеса на възстановяване, докато не приключи целият дъмп.
2) Физическо надграждане
Този вид надстройки са налични от версия 9.0 за извършване на надстройки на място от версии до 8.3. Те се наричат „на място“, защото се извършват на същия сървър и за предпочитане в една и съща директория с данни.
Предимства на този вид надстройки:
- Не ви е необходимо място за друго копие на клъстера.
- Престой е много по-малък в сравнение с използването на pg_dump.
Има доста недостатъци:
- След като стартирате новата версия на PostgreSQL, няма връщане към старата версия (клъстерът ще работи само с новата версия от там нататък).
- Статистиките се нулират след надстройката, така че веднага след стартиране на новата версия на PostgreSQL трябва да се изпълни анализ за целия клъстер.
- През последните години бяха открити много грешки по отношение на pg_upgrade, което кара някои администратори на бази данни да не желаят да използват този метод за надграждане.
- Някои хора са имали проблеми при пропускане на основна версия, например преминаване от версия 9.2 към версия 9.4.
- С големите каталози ще работи лошо (клъстери с много бази данни или бази данни с много хиляди обекти).
Можете също да стартирате pg_upgrade без опцията –link (в този случай pg_upgrade ще генерира второ копие на диска на вашия клъстер), за да можете да се върнете към старата версия. Но ще загубите и двете предимства, изброени по-горе.
3) Надстройка онлайн
Процедурата, която трябва да се следва за този метод, би била следната:
- Инсталирайте и двете версии, за да можете да ги накарате да работят паралелно. Това може да стане на един и същ сървър или с два физически сървъра.
- Създайте първоначално копие и репликирайте промените от момента, в който сте стартирали копието на изходния възел (това би било подобно на първоначален pg_dump).
- Продължете да възпроизвеждате логически промените, докато изоставането е близко до нула.
- Насочете отново информацията за връзката от сървъра на приложения, за да се свържете с новия сървър.
Този тип надстройка е налична откакто съществуваха първите решения за репликация, базирани на тригери. С други думи, откакто Slony-I беше наоколо.
Решенията за репликация, базирани на тригери, не се интересуват коя версия имате от едната или от другата страна, тъй като копира промените, използвайки поддържани SQL команди.
Препоръчаните инструменти за репликация, базирани на тригери, в реда, в който се появяват, са:
- skytools:PgQ + londiste
- Slony-I
Това трябва да е предпочитаният начин за надграждане. Нека видим предимствата на използването на този метод:
- Нулев престой!
- Чудесно и за надграждане до по-нов хардуер.
- Онлайн тестване на клъстера с новата версия (заявки само за четене или може да се стигне до конфликти).
- Намалява драстично всички таблици и индекси.
Има някои недостатъци:
- Има нужда от двойно място за съхранение, тъй като трябва да съхранява второ копие на вашите данни.
- Тъй като се основава на тригери, системата трябва да записва всяка промяна два пъти, което означава, че ще има повече дисков вход/изход на изходния сървър (стара версия на клъстера).
- Всички таблици трябва да имат първичен ключ, така че инструментът за репликация може да индивидуализира кортежите, които се актуализират или изтриват.
- Не копира каталожни таблици, така че няма да репликира големи обекти.
- Основната употреба не обхваща промените в схемата. Може да се направи, но не прозрачно.
Нова граница с pglogical
От PostgreSQL 9.4 имаме логическо декодиране на регистрационните файлове на транзакциите. Това означава, че сега можем да декодираме транзакциите от WAL и да манипулираме изхода.
В областта на репликацията се появи цял нов свят от възможности. Вече не са необходими тригери за осъществяване на логическа репликация!
Това основно означава, че вече не е необходимо да запазвате отделно копие на всички вмъквания, актуализации и изтривания с помощта на тригери. Можете просто да получите тези операции за манипулиране на данни от регистрационните файлове на транзакциите, като ги декодирате. След това инструментът, който използвате, трябва да манипулира изхода и да го изпрати до абонирания възел надолу по веригата. В този случай този инструмент е pglogical.
И така, какво означава всичко това?
Е, ако сте с версия 9.4 или 9.5 на PostgreSQL и искате да надстроите до 9.6, можете да извършите онлайн надстройка като тази, описана по-горе, но като използвате pglogical вместо едно от решенията за репликация, базирани на тригери.
Няма да навлизам в подробности, тъй като има други блогове по тази конкретна тема, като този, написан от Петр Йелинек:PGLogical 1.1 пакети за PostgreSQL 9.6beta1
Заключения
В зависимост от схемата на вашата база данни, размера на данните, възможния прозорец за прекъсване, версията на текущата инсталация на PostgreSQL, можете да изберете една опция пред друга или каквото е най-подходящо.
- Ако вашата база данни е малка и има подходящ прозорец за поддръжка, който можете да използвате, можете да изберете да стартирате pg_dump и pg_restore. В зависимост от размера на набора от данни има момент, в който опцията вече не е осъществима.
- Ако имате голяма база данни (няколко стотици GB или дори TB данни), ще трябва да потърсите други опции, като надстройка на място с pg_upgrade или онлайн надстройка.
- Ако надстройвате от версия 8.3 или по-нова до която и да е версия 9.x, можете да използвате pg_upgrade.
- За версии, по-стари от 8.3, ще трябва да изберете едно от логическите решения за репликация, като londiste или slony.
- Ако на база данни 9.4 или 9.5 е по-добре да използвате pglogical.
Винаги помнете, че за логическа репликация таблиците трябва да имат първичен ключ.
С pglogical това правило не е толкова строго:можете да копирате таблици само за вмъкване. Но за актуализиране и изтриване все още е задължително да имате първичен ключ или РЕПЛИКА ИДЕНТИЧНОСТ на масата.
Ако имате нужда от помощ за надграждане на вашата PostgreSQL база данни, можете да проверите
услугите за надстройка на 2ndQuadrant.
