Поточно предаване на PostgreSQL срещу логическа репликация – Сравнение

Репликирането на информацията, съхранявана във вашата база данни, е от съществено значение за разпространението на данни и за гарантиране, че имате резервно копие, което може да се използва за възстановяване след бедствие, в случай че нещо се обърка.

Репликацията на PostgreSQL се предлага в две форми и и двете имат своите нишови употреби. Разбирането как да приложите един или и двата от тези метода за репликация на данни може да рационализира процесите ви за разпространение на данни. Последното нещо, което искате, е да загубите важна работа, която сте свършили върху база данни.

Нека да разгледаме плюсовете, минусите и случаите на използване на поточно репликация и логика в PostgreSQL.

Дефиниране на репликация на данни в PostgreSQL

Ако вече сте запознати с това какво е репликация на данни, тогава можете да продължите и да превъртите надолу до следващия раздел. Но в случай, че сте нов в инженерството на бази данни, искаме да поставим основата наистина бързо.

Както подсказва името, репликацията е процес на често копиране на данни от една база данни в компютърен сървър в друга база данни на различен сървър, така че всички потребители имат достъп до едно и също ниво на информация. В изчисленията репликацията се използва за отстраняване на грешки в цифрова система.

Репликацията елиминира силозите за данни, защитава ценната информация и рационализира развитието.

В PostgreSQL има две опции за репликация:логическа и поточно репликация. Тези методи са чудесни за различни случаи на употреба и като разработчик може да се окажете по-склонни да използвате един пред друг. Но е добре да разберете как да използвате и двете, за да можете да решите кой да приложите в различни сценарии.

Логическа репликация в PostgreSQL

Поточно репликацията беше въведена за използване с PostgreSQL v10.0. Логическата репликация работи чрез копиране/репликация на обекти с данни и техните промени въз основа на тяхната идентичност на репликация.

В много случаи самоличността на данните е основен ключ. В PostgreSQL той дава на потребителите фино зърнест контрол върху реплицираните данни и информационната сигурност.

Терминът логически се използва, за да се разграничи от физическата репликация, която използва репликация байт по байт и точни адреси на блокове. Прочетете повече в официалната документация на PostgreSQL тук.

Чрез модел за публикуване и абониране той работи, като позволява на един или повече абонати да се абонират за една или повече публикации на възел на издател. Абонатите могат да изтеглят информация от публикациите и да публикуват повторно данните за каскадна репликация или по-сложна конфигурация.

Логическата репликация на данни може също да приеме формата на репликация на транзакции. Ако инженерът иска да копира таблица, той може да използва този метод на репликация, за да направи моментна снимка на данните от страна на издателя и да ги изпрати в базата данни на абоната.

Тъй като абонатите правят промени в оригиналните данни, базата данни на издателите получава актуализации в реално време. За да осигури последователност на транзакциите в публикации с един абонамент, абонатът трябва да приложи данните в същия ред като издателя.

Предимства на логическата репликация в PostgreSQL

Логическата репликация позволява на потребителите да използват целеви сървър за запис и позволява на разработчиците да имат различни индекси и дефиниции за сигурност. Това осигурява подобрена гъвкавост за прехвърляне на данни между издатели и абонати.

Поддръжка на различни версии

Освен това, той идва с поддръжка на кръстосани версии и може да се задава между различни версии на PostgreSQL. Той също така осигурява филтриране, базирано на събития. Публикациите могат да имат няколко абонамента, което улеснява споделянето на данни в широка мрежа.

Минимално натоварване на сървъра

В сравнение с решенията, базирани на тригери, той има минимално натоварване на сървъра, като същевременно осигурява гъвкавост за съхранение чрез репликиране на по-малки комплекти. Както бе споменато по-горе, логическата репликация на данни може дори да копира данни, съдържащи се в основни разделени таблици.

Също така е важно да се спомене, че логическото репликация на данни позволява трансформиране на данни дори когато се настройва и позволява паралелно поточно предаване между издатели.

Недостатъци на логическата репликация в PostgreSQL

Логическата репликация няма да копира последователности, големи обекти, материализирани изгледи, основни таблици на дялове и чужди таблици.

В PostgreSQL репликацията на логическата информация се поддържа само от DML операции. Разработчиците не могат да използват DDL или съкращават, а схемата трябва да бъде дефинирана предварително. Освен това, той не поддържа взаимно (двупосочно) репликация.

Ако потребителите изпаднат в конфликти с ограничения за репликирани данни в таблица, репликацията ще спре. Единственият начин за възобновяване на репликацията е, ако причината за конфликта бъде разрешена.

Непреднамерен конфликт може да спре инерцията на вашия екип, така че трябва да разберете как бързо да разрешавате всички проблеми.

Ако конфликтът не бъде разрешен бързо, слотът за репликация ще замръзне в текущото си състояние, възелът на издателя ще започне да натрупва регистрационни файлове с предварителна запис (WALs) и възелът в крайна сметка ще свърши без дисково пространство.

Случаи на използване за логическа репликация в PostgreSQL

Много инженери ще използват логическа репликация за:

• Разпространение на промените в рамките на една база данни или подмножество от база данни до абонатите в реално време
• Сливане на множество бази данни в една централна база данни (често за използване на анализи)
• Създаване на репликации в различни версии на PostgreSQL
• Разгръщане на репликации между екземпляри на PostgreSQL в различни платформи, като Linux към Windows
• Споделяне на репликирани данни с други потребители или групи
• Разпределение на подмножество от база данни между множество бази данни

Поточно репликация в PostgreSQL

Поточно репликацията беше въведена за използване с PostgreSQL 9.0. Процесът изпраща и прилага файлове за записване с предварителна запис (WAL) от главен или първичен сървър на база данни към реплика или приемаща база данни. WAL се използват за репликация и за гарантиране на целостта на данните.

Как работи поточно репликацията

Репликацията на поточно предаване работи за преодоляване на пропастта между трансферите на данни, присъщи на базираното на файлове транспортиране на дневници, което изчаква, докато WAL достигне максимален капацитет за изпращане на данни.

Чрез поточно предаване на WAL записи, сървърите на бази данни предават поточно WAL записи на парчета, за да синхронизират данните. Сървърът в режим на готовност се свързва с репликата и получава WAL парчетата, когато се изпращат.

При поточно репликация потребителят трябва да реши дали да настрои асинхронна или синхронна репликация. Когато поточно репликацията е първоначално разгърната, тя по подразбиране ще бъде асинхронна репликация.

Това показва, че има забавяне между първоначалната промяна на първичния и отразяването на тази промяна върху репликата. Асинхронизацията отваря вратата за потенциална загуба на данни, ако главната програма се срине, преди промените да бъдат копирани, или ако репликата е толкова несинхронизирана с оригинала, че вече е изхвърлила съответните данни, за да направи промени.

Синхронната репликация е много по-безопасна опция, тъй като прави промени в реално време. Прехвърлянето от главния към репликата се счита за непълно, докато и двата сървъра не проверят информацията. След като промените в данните бъдат потвърдени, прехвърлянето се записва на WAL на двата сървъра.

Независимо дали използвате асинхронна или синхронна репликация, репликите трябва да бъдат свързани към главната чрез мрежова връзка. Освен това е важно потребителите да настроят привилегии за достъп за WAL потоците на репликата, така че информацията да не бъде компрометирана.

Предимства на поточно репликацията в PostgreSQL

Едно от най-значимите предимства при използването на стрийминг репликация е, че единственият начин да загубите данни е ако и основният, и получаващият сървър се сринат едновременно. Ако предавате важна информация, поточно репликацията гарантира, че копие от работата ви ще бъде запазено.

Потребителите могат да свържат повече от един резервен сървър към основния и регистрационните файлове ще се предават поточно от основния към всеки от свързаните резерви. Ако една от репликите се забави или бъде прекъсната, стриймингът ще продължи към другите реплики.

Настройването на доставка на регистрационни файлове чрез стрийминг репликация няма да попречи на нищо, което потребителят в момента изпълнява в основната база данни. Ако основният сървър за данни трябва да бъде изключен, той ще изчака, докато актуализираните записи бъдат изпратени до репликата, преди да изключи захранването.

Недостатъци на поточно репликацията в PostgreSQL

Поточно репликацията няма да копира информация в различна версия или архитектура, да промени информацията на сървърите в режим на готовност и не предлага детайлна репликация.

Особено при репликация на асинхронно поточно предаване на данни, по-старите WAL файлове, които все още не са копирани в репликата, могат да бъдат рециклирани, когато потребителят направи промени в главния. За да гарантира, че жизненоважните файлове няма да бъдат загубени, потребителят може да зададе wal_keep_segments на по-висока стойност.

Без идентификационни данни за потребителско удостоверяване, настроени за сървърите за реплики, може да бъде лесно извличането на чувствителни данни. За да се появят актуализации в реално време между главната и репликата, потребителят трябва да промени метода на репликация от асинхронна репликация по подразбиране към синхронна репликация.

Случаи на използване за поточно репликация в PostgreSQL

Много инженери ще използват стрийминг репликация за:

• Създаване на резервно копие за основната им база данни в случай на повреда на сървъра или загуба на данни
• Насърчаване на решение с висока наличност с възможно най-малко забавяне на репликацията
• Освобождаване на големи заявки за облекчаване на част от напрежението върху първичната система
• Разпределение на работните натоварвания на база данни между няколко машини, особено за формати само за четене

Какво има в магазина за бъдещето?

Групата за глобално развитие на PostgreSQL обяви пускането на PostgreSQL 14 на 30 септември 2021 г. Новата версия беше заредена с надстройки както в стрийминг, така и в логически репликации през платформата.

За стрийминг репликация, версия 14 позволява на потребителите да:

• Задайте параметъра на сървъра log_recovery_conflict_waits за да докладвате автоматично дълго време на изчакване при конфликт при възстановяване
• Поставете на пауза възстановяването на сървър в горещ режим на готовност при промяна на параметрите на основен сървър (вместо незабавно изключване на режима на готовност)
• Използвайте функция pg_get_wal_replay_pause_state() за да докладвате по-подробно състоянието на възстановяване
• Предоставете сървърен параметър само за четене in_hot_standby
• Бързо съкращавайте малки таблици по време на възстановяване на клъстери, които имат голям брой споделени буфери
• Разрешаване на синхронизиране на файловата система в началото на възстановяване при срив чрез Linux
• Използвайте функция pg_xact_commit_timestamp_origin() на определена транзакция, за да върне времевата марка за извършване и произхода на репликацията
• Използвайте функцията pg_last_committed_xact() за да добавите произхода на репликацията към върнатия запис
• Използвайте стандартни контроли за разрешения за функции, за да промените функциите за произход на репликация (по подразбиране все още ограничава достъпа до суперпотребителите)

За логическа репликация, версия 14 позволява на потребителите да:

• Предавайте дълги текущи транзакции към абонатите с API за логическа репликация
• Разрешете множество транзакции по време на репликации на таблица
• Генерирайте незабавни подтранзакции WAL-log и XID асоциации от най-високо ниво
• Използвайте функция pg_create_logical_replication_slot() за подобряване на API за логическо декодиране за двуфазни комити
• Добавете съобщения за невалидиране на кеша към WAL по време на завършване на командата, за да позволите логическо поточно предаване на транзакции в ход
• Контролирайте кои съобщения за логическо декодиране се изпращат към репликационния поток
• Използвайте режим на двоичен трансфер за по-бързи репликации
• Филтриране на декодиране по XID

PostgreSQL вече работи към версия 15, която се очаква да бъде пусната през третото тримесечие на 2022 г. Един от проблемите по отношение на репликацията, който трябва да бъде разгледан в най-новата версия, включва предотвратяване на използването на променливи, наследени от сървърната среда при поточно репликация. Но тъй като повече потребители се адаптират към версия 14, PostgreSQL вероятно ще добави още задачи за подобряване на функциите за репликация.

Бързо сравнение на PostgreSQL репликация:Логическа срещу поточно репликация

Заключение

Надяваме се това ръководство да ви бъде полезно, когато настройвате функциите си за репликация. Ако имате въпроси или има нещо друго, което искате да знаете за това как ScaleGrid може да ви помогне с внедряването на PostgreSQL, свържете се с един от многото ни експерти по бази данни.