Миналата седмица бях на Nordic PGDay 2018 и имах доста разговори за инструмента, който написах, а именно pglupgrade , за автоматизиране на надстройките на основната версия на PostgreSQL в настройка на клъстер за репликация. Бях доста щастлив, че беше чуто и някои други хора в различни общности, изнасящи лекции на срещи и други конференции за надстройки с почти нулев престой, използвайки логическа репликация. Като се има предвид, че има лекция, която изнесох на PGDAY'17 Русия, PGConf.EU 2017 във Варшава и накрая на FOSDEM PGDay 2018 в Брюксел, реших, че е по-добре да създам публикация в блог, за да поддържам тази презентация достъпна за хората, които могат да не стигнем до нито една от гореспоменатите конференции. Ако искате да преминете директно към разговора и да пропуснете четенето на тази публикация в блога, ето вашата връзка:Автоматизирани надстройки на PostgreSQL клъстери в облака с почти нулев престой
Основната мотивация зад разработването на този инструмент беше да се предложи решение за минимизиране на престоя по време на големи надстройки на версията, което за съжаление засяга почти всеки, който използва PostgreSQL. Понастоящем нямаме инструмент, който позволява на потребителите на PostgreSQL да надграждат своите бази данни без прекъсване и това очевидно е болезнена точка за много потребители, особено за бизнеса. И ако искаме да решим проблема с надстройката, трябва да помислим за повече от един сървър (отсега нататък ще се нарича клъстер), просто защото вече не много хора използват само един сървър на база данни. Най-често срещаният сценарий е настройка на репликация на физическо поточно предаване или за целите на висока наличност, или за мащабиране на заявките за четене.
Надстройки на базата данни
Преди да се потопим в решението, нека обсъдим малко как работят надстройките на базата данни като цяло. Има четири основни възможни подхода за надстройки на база данни:
- Първият подход би бил базите данни да запазят формата си за съхранение един и същ или поне съвместим между версиите. Това обаче е трудно да се гарантира дългосрочно, тъй като новите функции може да изискват промени в начина на съхраняване на данните или добавяне на повече информация за метаданни, за да работят правилно. Също така производителността често се подобрява чрез оптимизиране на структурите от данни.
- Вторият подход е да направите логическо копие (думп) на стария сървър и да го заредите в новия сървър. Това е най-традиционният подход, който изисква старият сървър да не получава никакви актуализации по време на процеса и води до продължителни прекъсвания часове или дори дни в големи бази данни.
- Третата опция е да конвертирате данни от стар формат в нов. Това може да бъде направено в движение, докато новата система работи, но води до намаляване на производителността, което е трудно да се предвиди, тъй като зависи от моделите на достъп до данни, или може да се направи офлайн, докато сървърите не работят, което отново води до продължително време престойи (макар и често по-кратък от втория метод).
- Четвъртият метод е да използвате логически дъмп за запазване и възстановяване на базата данни като същевременно улавяте промените, случващи се междувременно и логическото им репликиране в новата база данни, след като първоначалното възстановяване приключи. Този метод изисква оркестрация на няколко компонента, но също така намалява времето, през което базата данни не може да отговори на заявки.
Методи за надстройка в PostgreSQL
Надстройките на PostgreSQL могат да бъдат съпоставени с четирите метода, изброени по-горе. Например, второстепенните издания на PostgreSQL, които не съдържат нови функции, а само поправки, не променят съществуващия формат на данни и отговарят на първия подход. За втория подход PostgreSQL предоставя инструменти, наречени pg_dump и pg_restore, които правят логическото архивиране и възстановяване. Има и инструмент pg_upgrade (той беше модул за принос и преместен в основното дърво в PostgreSQL 9.5), който прави офлайн (сървърите не работят) преобразуване на старата директория с данни в новата, което може да се побере в третата опция. За четвъртия подход има базирани на тригери решения на трети страни като Slony за надграждане, но те имат някои предупреждения, които ще разгледаме по-късно.
Традиционните методи за надгражданесамо надстройте основния сървър, докато сървърите реплики трябва да бъдат възстановени след това (офлайн преобразуване) . Това води до допълнителни проблеми както с наличността, така и с капацитета на клъстера, като по този начин ефективно увеличава възприеманото време за престой на базата данни от гледна точка както на приложенията, така и на потребителите. Логическата репликацияпозволява репликиране докато системата е вработана и усилията за тестване могат да бъдат обработени междувременно (онлайн конвертиране) .
Има различни методи за надграждане, приложими за различни среди. Например pg_dump позволява надстройка от много стари версии (т.е. 7.0) до последните версии, така че ако използвате антична версия на PostgreSQL, най-добрият метод е да използвате pg_dump/restore (и по-добре да го направите сега!). Ако вашата PostgreSQL версия е 8.4 и по-нова можете да използвате pg_upgrade . Ако случайно използвате PostgreSQL 9.4 и по-нова версия това означава, че имате вградено „логическо декодиране“ и можете да използвате pglogical разширение като средство за надграждане. И накрая, ако използвате PostgreSQL 10 , ще имате възможност да надстроите вашата база данни до PostgreSQL 11 и по-нова версия (след като са налични) чрез използване на „Логична репликация“ в ядрото (да!).
Логическа репликация за надстройки
Къде е идеята за надграждане на PostgreSQL чрез логическа репликация идва от? Ясно, pglogical не претендира открито за целта на надстройката като pg_upgrade прави (това беше един от аргументите срещу pglogical на партито на конференцията ), но това не означава, че не можем да използваме инструмента за надстройки. Всъщност, когато pglogical беше проектиран, надстройките с почти нулев престой се считаха за един от очакваните случаи на употреба от разработчиците на разширението.
За разлика от физическата репликация, която улавя промени в необработените данни на диска, логическата репликация улавя логическите промени в отделните записи в базата данни и ги репликира. Логическите записи работятв основните издания , следователно логическата репликация може да се използва за надграждане от едно издание до друго. Идеята за използване на логическа репликация като средство за надграждане на версията далеч не е нова, базираните на задействане инструменти за репликация правят надстройки по логичен начин, като улавят и изпращат промените чрез тригери (защото тригерите също могат да работят независимо от версиите на базата данни! ).
Ако можете да използвате базирани на тригери решения за репликация за минимални надстройки при престой, защо да предпочетете вместо това логическа репликация? При механизъм, базиран на тригери, всички промени се улавят чрез използване на тригери и се записват в таблици на опашката. Тази процедура удвоява операциите по запис, удвоява регистрационните файлове и забавя системата, тъй като всички промени трябва да бъдат записани два пъти; което води до повече дисков вход/изход и натоварване на изходния сървър. За разлика от тях, логическата репликация в ядрото (същото важи и за pglogical разширение) е изградена върху логическото декодиране. Логическото декодиране е механизъм, който извлича информация от WAL файлове в логически промени (INSERT/UPDATE/DELETE). Тъй като данните от механизма WAL се използват за декодиране на регистрационните файлове на транзакциите, няма усилване на запис както в случая на решения за репликация, базирани на тригери, следователно този метод работи по-добре . В резултат на това решенията, базирани на логическо декодиране, просто имат по-слабо въздействие върху системата, отколкото решенията, базирани на тригери.
Заключение
В тази въвеждаща публикация исках да дам идея защо трябва да обмислим използването на логическа репликация за постигане на минимално време на престой по време на големи надстройки на версията. Ще продължим с подробностите за архитектурата и внедряването на инструмента в предстоящата публикация.
