През последните няколко месеца работих по онлайн надстройка за много големи бази данни като част от проекта AXLE и бих искал да споделя своите мисли по темата и какъв напредък постигнахме напоследък.
Преди да се присъединя към 2ndQuadrant работех в Skype, където бизнесът не позволяваше прозорец за поддръжка за нашите бази данни. Това означаваше, че не се разрешава престой за внедряване, надстройки и т.н. Този вид правило ви кара да промените начина, по който правите нещата. Повечето промени са малки, не правите никакви тежки ключалки, имате реплики, които позволяват бързо преминаване при отказ. Но докато можете да направите своите издания малки и неблокиращи, какво се случва, когато трябва да направите основна надстройка на версията на базата данни PostgreSQL?
Може да сте в различна ситуация, тъй като повечето компании имат прозорец за надстройка и така може да си позволите малко престой по време на надстройката. Това обаче носи два проблема. От една страна, никоя компания всъщност не харесва прекъсванията, дори ако са разрешени. И което е по-важно, след като вашата база данни нарасне повече от гигабайти в размер от терабайти или стотици терабайти, престоят може да отнеме дни или дори седмици и никой не може да си позволи да спре операциите си за толкова дълго. Резултатът е, че много компании често пропускат важни надстройки, което прави следващата всъщност още по-болезнена. И на разработчиците липсват нови функции, подобрения в производителността. Те (компаниите) понякога дори рискуват да стартират версия на PostgreSQL, която вече не се поддържа и има известни проблеми с повреда на данните или сигурността. В следващите параграфи ще говоря малко за работата си по това да направя надстройките по-малко отнемащи време и в резултат на това по-малко болезнени и да се надяваме по-чести.
Нека първо започна с малко история. Преди PostgreSQL 9.0 единственият начин да направите основна надстройка на версията беше да стартирате pg_dump и да възстановите дъмпа в екземпляр, работещ с по-нова версия на PostgreSQL. Този метод изисква структурата и всички данни да бъдат прочетени от базата данни и записани във файл. След това прочетете от файла и го вмъкнете в нова база данни, индексите трябва да се изградят отново и т.н.
Както можете да си представите, този процес може да отнеме доста време. Подобрения в производителността бяха направени в 8.4 за pg_restore с добавена опция -j, където можете да посочите колко паралелни задачи да се изпълняват. Това прави възможно паралелното възстановяване на няколко таблици (индекси и т.н.), което прави процеса на възстановяване по-бърз за дъмпи на персонализиран формат. Версията 9.3 добави подобна опция към pg_dump, подобрявайки още повече производителността. Но като се има предвид колко бързо нарастват обемите на данни, самото успоредяване не е достатъчно, за да постигне сериозна печалба във времето, необходимо за надграждане.
Тогава в PostgreSQL 9.0 пристигна помощна програма, наречена pg_upgrade. Pg_upgrade изхвърля само структурите и ги възстановява в новия клъстер. Но той копира файловете с данни, така както са на диск, което е много по-бързо, отколкото да ги изхвърля в логически формат и след това да ги вмъкне отново. Това е достатъчно добре за малки бази данни, тъй като означава престой в диапазон от минути или часове, време, приемливо за много сценарии. Има и режим на връзка, който просто създава твърди връзки (точки на свързване в Windows), което прави този процес още по-бърз. Но от моя лична гледна точка е твърде опасно да се изпълнява такава настройка на производствен главен сървър. Ще обясня накратко защо. Ако нещо се обърка, след като стартирате новия си сървър, който е надстроен с помощта на режима на връзка, вие изведнъж оставате без производствена база данни и трябва да преминете при отказ или по-лошо, трябва да възстановите от архивиране. Това означава, че не само не сте успели да надстроите, но просто сте причинили допълнителен престой! Успех с одобрението следващия път.
Сега много хора, които не могат да си позволят дълги престои за надстройки, използват решенията за репликация, базирани на тригери, като Slony или Londiste, за да направят надстройката. Това е добро решение, защото можете да репликирате данните си, докато оригиналният сървър работи и след това да превключвате с минимално време на престой. На практика обаче има няколко проблема. Едно от тях е, че базираните на тригера решения често са тромави за настройка, особено ако го правите само веднъж на няколко години и само за надграждане. Също така е лесно да пропуснете таблица или да добавите таблици в грешен ред и по този начин да не получите пълното копие. Свидетел съм на това на практика и хората, които извършваха надстройката, работеха с репликация, базирана на тригера, ежедневно . Друг проблем е, че базираните на тригери решения добавят значително натоварване към изходната база данни, което понякога прави надстройката невъзможна поради претоварването на сървъра на базата данни след активиране на репликацията. И накрая, но често не на последно място, може да отнеме много време, докато базираната на тригера репликация действително премести данните на новия сървър. При последния път, когато участвах в проект за надграждане, базираното на тригер решение отне около месец, за да копира базата данни и да навакса промените. Да, един месец.
С PostgreSQL 9.4 пристига функцията за логическо декодиране, която предлага нов старт за проектиране на ново и по-добро решение на проблема с онлайн надстройката. Това, което направихме, като част от проекта AXLE, е да създадем инструмент, който комбинира логическото декодиране с техниките, описани по-горе. Решението решава повечето от проблемите на предишните подходи. Разширението PostgreSQL за еднопосочна репликация (накратко UDR) извършва логическа репликация, използвайки логическо декодиране на дневника за предварителна запис (WAL). Благодарение на това въздействието върху главния сървър е почти наравно с физическото стрийминг репликация, така че допълнителното натоварване, причинено от текущата надстройка, е минимално за работещата система. Освен това предоставя инструменти за инициализиране на нови възли, както с помощта на физическо, така и логическо архивиране. Можете дори да превърнете съществуващия физически режим на готовност в режим на готовност UDR. И тъй като това е система за логическа репликация, е възможно да се проектира по начин, който поддържа репликация между версии.
Всичко това означава, че вече можем да използваме UDR в комбинация с pg_upgrade, за да направим онлайн надстройка на основната версия на PostgreSQL с минимално време на престой, за кратко абсолютно време и с минимално въздействие върху работещата система.
Пример как може да изглежда това на практика:
- Направете pg_basebackup на съществуващ екземпляр.
- Настройте UDR репликацията между оригиналния екземпляр и този, създаден от basebackup.
- Pg_upgrade новия екземпляр.
- Оставете UDR да възпроизведе промените, настъпили междувременно.
- Превключете трафика към новия екземпляр.
За как да с по-подробни инструкции вижте ръководството за онлайн надстройка на UDR в PostgreSQL wiki. Източниците на UDR са налични в хранилището 2ndquadrant_bdr на PostgreSQL git сървър (bdr-plugin/следващ клон).
И накрая, тъй като UDR не е просто инструмент за онлайн надстройка, но и решение за репликация, той може да се използва за вашите нормални нужди за репликация, вместо за физическа стрийминг репликация. Освен това той предоставя няколко предимства като възможност за създаване на временни таблици, репликиране от множество OLTP бази данни в една база данни за голям склад на данни или репликиране само на част от базата данни.
Надявам се, че това усилие ще означава, че съображенията за престой вече не са проблем, когато става въпрос за надграждане от PostgreSQL 9.4 и по-нова до нова основна версия.
Изследванията, довели до тези резултати, са получили финансиране от Седмата рамкова програма на Европейския съюз (FP7/2007-2013) съгласно споразумение за отпускане на безвъзмездни средства № 318633.
