Време е.
Преди около година публикувахме PostgreSQL 10 с поддръжка за собствена логическа репликация. Едно от употребите на логическата репликация е да позволи надграждане с малко или без прекъсване между основните версии на PostgreSQL. Досега PostgreSQL 10 беше единствената версия на PostgreSQL с естествена логическа репликация, така че нямаше много възможности за надграждане по този начин. (Логическата репликация може да се използва и за преместване на данни между екземпляри на различни операционни системи или архитектури на процесора или с различни конфигурационни настройки на ниско ниво, като размер на блока или локал – странично градиране, ако желаете.) Сега, когато PostgreSQL 11 е близо, ще има повече причини да използвате тази функционалност.
Нека първо сравним трите основни начина за надграждане на инсталация на PostgreSQL:
- pg_dump и възстановяване
- pg_upgrade
- логическа репликация
Можем да сравним тези методи по отношение на устойчивост, скорост, необходимо време на престой и ограничения (и повече, но трябва да спрем някъде за тази статия).
pg_dump and restore е може би най-стабилният метод, тъй като е най-тестваният и се използва от десетилетия. Освен това има много малко ограничения по отношение на това, с което може да се справи. Възможно е да се конструират бази данни, които не могат да бъдат изхвърлени и възстановени, предимно включващи конкретни отношения на зависимост на обекти, но те са редки и обикновено включват обезкуражени практики.
Проблемът с метода за изхвърляне и възстановяване, разбира се, е, че той ефективно изисква престой през цялото време, докато се изпълняват операциите за изхвърляне и възстановяване. Докато изходната база данни все още може да се чете и записва, докато процесът се изпълнява, всички актуализации на изходната база данни след началото на изхвърлянето ще бъдат загубени.
pg_upgrade подобрява процеса pg_dump, като премества директно файловете с данни, без да се налага да ги изхвърля в логическа текстова форма. Обърнете внимание, че pg_upgrade все още използва pg_dump вътрешно за копиране на схемата, но не и на данните. Когато pg_upgrade беше нов, неговата стабилност беше поставена под въпрос и той наистина надстрои някои бази данни неправилно. Но pg_upgrade вече е доста зрял и добре тестван, така че вече не е нужно да се колебаете да го използвате по тази причина. Докато pg_upgrade работи, системата на базата данни не работи. Но човек може да направи избор за това колко дълго ще работи pg_upgrade. В режима на копиране по подразбиране, общото време за изпълнение се състои от времето за изхвърляне и възстановяване на схемата (което обикновено е много бързо, освен ако няма хиляди таблици или други обекти) плюс времето за копиране на файловете с данни, което зависи от колко голяма е базата данни (и входно/изходната система, файловата система и т.н.).
В опционалния режим на свързване, файловете с данни са твърдо свързани с новата директория с данни, така че времето е просто времето за извършване на кратка операция на ядрото на файл, вместо да се копира всеки байт. Недостатъкът е, че ако нещо се обърка с надстройката или трябва да се върнете към старата инсталация, тази операция ще унищожи старата ви база данни. (Работя върху най-доброто от двата свята решение за PostgreSQL 12, използвайки препратки или операции за клониране на файлове в поддържани файлови системи.)
Логическата репликация е най-новата от групата тук, така че вероятно ще отнеме известно време, за да се отстранят пречупванията. Ако нямате време да проучвате и разследвате, това може да не е правилният начин в момента. (Разбира се, хората използват други неосновни логически решения за репликация като Slony, Londiste и pglogical за надграждане на PostgreSQL от много години, така че има много опит с принципите, ако не и с подробностите.)
Предимството на използването на логическа репликация за надграждане е, че приложението може да продължи да работи срещу стария екземпляр, докато се извършва синхронизирането на данните. Трябва само да има малък прекъсване, докато клиентските връзки са превключени. Така че, докато надстройката, използваща логическа репликация, вероятно е по-бавна от началото до края, отколкото използването на pg_upgrade в режим на копиране (и определено по-бавно от използването на режим на твърда връзка), няма голямо значение, тъй като действителният престой може да бъде много по-кратък.
Имайте предвид, че логическата репликация в момента не репликира промените в схемата. В тази предложена процедура за надграждане, схемата все още се копира чрез pg_dump, но последващите промени в схемата не се пренасят. Надстройката с логическа репликация има и няколко други ограничения. Някои операции не се улавят от логическа репликация:големи обекти, TRUNCATE, промени в последователността. Ще обсъдим решенията за тези проблеми по-късно.
Ако имате някакви физически режими на готовност (и ако не, защо нямате?), има и някои разлики, които трябва да имате предвид между методите. И с двата метода трябва да изградите нови физически резерви за надградения екземпляр. С изхвърляне и възстановяване, както и с логическа репликация, те могат да бъдат въведени преди началото на надстройката, така че режимът на готовност да бъде почти готов, след като първоначалното синхронизиране на възстановяването или логическата репликация завърши, при условие на забавяне на репликацията.
С pg_upgrade новите режими на готовност трябва да бъдат създадени след завършване на надстройката на основния. (Документацията на pg_upgrade описва това по-подробно.) Ако разчитате на физически режими на готовност за висока наличност, тези трябва да са на място, преди да преминете към новия екземпляр, така че настройката на режима на готовност може да повлияе на общите ви изчисления на времето.
Но да се върнем към логическата репликация. Ето как може да се извърши надстройка с логическа репликация:
0. Старият екземпляр трябва да бъде подготвен за логическа репликация. Това изисква някои настройки за конфигурация, както е описано в http://www.postgresql.org/docs/10/static/logical-replication-config.html (главно wal_level = logical . Ако се окаже, че трябва да направите тези промени, те ще изискват рестартиране на сървъра. Така че проверете това предварително. Също така проверете, че pg_hba.conf на стария екземпляр е настроен да приема връзки от новия екземпляр. (Промяната на това изисква само презареждане.)
1. Инсталирайте новата версия на PostgreSQL. Нуждаете се поне от сървърния пакет и клиентския пакет, който съдържа pg_dump. Много опаковки вече позволяват инсталиране на няколко версии една до друга. Ако използвате виртуални машини или облачни екземпляри, струва си да обмислите инсталирането на новия екземпляр на нов хост.
2. Настройте нов екземпляр, тоест стартирайте initdb. Новият екземпляр може да има различни настройки от стария, например локал, размер на сегмента на WAL или контролна сума. (Защо не използвате тази възможност, за да включите контролните суми за данни?)
3. Преди да стартирате новия екземпляр, може да се наложи да промените някои конфигурационни настройки. Ако екземплярът работи на същия хост като стария екземпляр, трябва да зададете различен номер на порт. Също така, прехвърлете всички персонализирани промени, които сте направили в postgresql.conf на стария ви екземпляр, като настройки на паметта, max_connections и т.н. По същия начин направете pg_hba.conf настройки, подходящи за вашата среда. Обикновено можете да започнете, като копирате през pg_hba.conf файл от стария екземпляр. Ако искате да използвате SSL, настройте го сега.
4. Стартирайте новия (празен) екземпляр и проверете дали работи за ваше удовлетворение. Ако настроите новия екземпляр на нов хост, проверете в този момент дали можете да осъществите връзка с база данни (с помощта на psql) от новия хост към стария екземпляр на базата данни. Това ще ни трябва в следващите стъпки.
5. Копирайте дефинициите на схемата с pg_dumpall. (Или можете да го направите с pg_dump за всяка база данни поотделно, но след това не забравяйте глобалните обекти като роли.)
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
Всички промени в схемата след тази точка няма да бъдат мигрирани. Ще трябва да ги управлявате сами. В много случаи можете просто да приложите променящия се DDL и на двата хоста, но изпълнението на команди, които променят структурата на таблицата по време на надстройка, вероятно е твърде голямо предизвикателство.
6. Във всяка база данни в изходния екземпляр създайте публикация, която улавя всички таблици:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
Логическата репликация работи отделно във всяка база данни, така че това трябва да се повтори във всяка база данни. От друга страна, не е нужно да надграждате всички бази данни наведнъж, така че можете да правите тази база данни по една или дори да не надстройвате някои бази данни.
7. Във всяка база данни в целевия екземпляр създайте абонамент, който се абонира за току-що създадената публикация. Уверете се, че отговаряте правилно на изходната и целевата база данни.
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
Задайте съответните параметри на връзката.
8. Сега чакате, докато абонаментите копират първоначалните данни и напълно настигнат издателя. Можете да проверите първоначалното състояние на синхронизиране на всяка таблица в абонамента в системния каталог pg_subscription_rel (потърсете r =готов в колона srsubstate ). Цялостното състояние на репликацията може да се провери в pg_stat_replication от изпращащата страна и pg_stat_subscription от приемащата страна.
9. Както бе споменато по-горе, промените в последователността не се репликират. Едно възможно решение за това е да копирате стойностите на последователността с помощта на pg_dump. Можете да получите дъмп на текущите стойности на последователността, като използвате нещо подобно:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(Това предполага, че всички имена на последователностите съвпадат с *_seq и няма таблици, отговарящи на това име. В по-сложни случаи можете също да преминете по пътя на създаване на пълен дъмп и извличане на данните за последователността от съдържанието на дъмпа.)
Тъй като последователностите може да се развиват, докато правите това, може би махнете seq-data.sql файл, за да добавите малко хлабина към числата.
След това възстановете този файл в новата база данни с помощта на psql.
10. Showtime:Превключете приложенията към новите екземпляри. Това изисква известно мислене преди време. В най-простия сценарий спирате приложните си програми, променяте настройките на връзката, рестартирате. Ако използвате прокси за връзка, можете да превключите връзката там. Можете също да превключвате клиентски приложения едно по едно, може би за да тествате малко нещата или да облекчите натоварването на новата система. Това ще работи, стига приложенията, които все още сочат към стария сървър, и тези, които сочат към новия сървър, не правят конфликтни записи. (В този случай ще работите с мултиглавна система, поне за кратко време, а това е друг ред на сложност.)
11. Когато надстройката приключи, можете да развалите настройката за репликация. Във всяка база данни на новия екземпляр стартирайте
DROP SUBSCRIPTION s_upgrade;
Ако вече сте изключили стария екземпляр, това ще се провали, защото няма да може да достигне до отдалечения сървър, за да изпусне слота за репликация. Вижте ръководството за ОТПУСКАНЕ НА АБОНАМЕНТА за това как да процедирате в тази ситуация.
Можете също да махнете публикациите в изходния екземпляр, но това не е необходимо, тъй като публикацията не запазва никакви ресурси.
12. Накрая премахнете старите екземпляри, ако вече не се нуждаете от тях.
Някои допълнителни коментари за решения за неща, които логическата репликация не поддържа. Ако използвате големи обекти, можете да ги преместите с помощта на pg_dump, разбира се стига да не се променят по време на процеса на надстройка. Това е значително ограничение, така че ако сте силен потребител на големи обекти, тогава този метод може да не е за вас. Ако приложението ви издаде TRUNCATE по време на процеса на надстройка, тези действия няма да бъдат репликирани. Може би можете да настроите приложението си, за да му попречите да прави това по време на надстройката, или вместо това можете да замените DELETE. PostgreSQL 11 ще поддържа репликация на TRUNCATE, но това ще работи само ако и източникът, и целевият екземпляр са PostgreSQL 11 или по-нова версия.
Някои заключителни коментари, които наистина се отнасят за всички начинания за надграждане:
- Приложенията и всички клиентски програми за база данни трябва да бъдат тествани спрямо нова основна версия на PostgreSQL, преди да бъдат пуснати в производство.
- За тази цел трябва също да тествате процедурата за надстройка, преди да я изпълните в производствената среда.
- Запишете нещата или по-добър скрипт и автоматизирайте колкото е възможно повече.
- Уверете се, че настройките ви за архивиране, системите за наблюдение и всички инструменти и скриптове за поддръжка са коригирани по подходящ начин по време на процедурата за надграждане. В идеалния случай те трябва да бъдат поставени и проверени, преди да се извърши превключването.
Имайки това предвид, успех и моля, споделете своя опит.
