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

Смятам се за малко изследовател. В определени неща е така. Обикновено винаги поръчвам една и съща храна от познат ресторант, тъй като страхът от разочарование надделява над опасенията ми да опитам нещо ново.

И разбира се, гладният човек е склонен да яде правилно?

И все пак, когато става въпрос за технологии, по-специално SQL (PostgreSQL), съм склонен да се спъвам с пълна скорост (моята дефиниция за изследване) в често непознати области с надеждата да се науча. Какъв по-добър начин за учене от опит?

И така, какво общо има това бъркотене с логическата и поточно репликация в PostgreSQL?

Аз съм пълен новак в тези области с нулеви познания. Да, имам почти толкова разбиране в тази област на Postgres, колкото и в астрофизика.

Споменах ли, че нямам никакви познания?

Ето защо в тази публикация в блога ще се опитам да усвоя разликите в тези видове репликация. Без практически опит в реалния свят, не мога да ви обещая „Бъдете всички край всички ' ръкопис за репликация.

Вероятно други по-малко запознати в тази конкретна област (като мен) ще се възползват от тази публикация в блога.

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

Двойка основни дефиниции

В широкия смисъл на думата какво означава репликация?

Репликацията, както е дефинирана в Уикиречник, казва това:

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

И все пак, 5-ият изброен елемент е по-приложим към тази публикация в блога и смятам, че трябва да го разгледаме също:

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

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

И така, като добавим това, което знаем от тази дефиниция, какви са дефинициите за поточно репликация и логическа репликация?

Нека да видим какво може да предложи PostgreSQL Wiki:

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

И документацията на PostgreSQL има тази дефиниция за логическа репликация:

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

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

По-долу ще се опитам да предам разликите в термините на лаиците. (Не забравяйте, че ако се спъна, аз съм новак.) Това е преглед на изключително „високо ниво“.

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

База данни "източник" създава ПУБЛИКАЦИЯ с помощта на командата CREATE PUBLICATION. (Мисля за това с прости думи като „изпращач“.)

Документацията го определя като издател.

Тази база данни на издател има данните, които искаме да репликираме. И все пак трябва да имаме какво да копираме и тук идват партньорите на издателите. „Абонатът“. Забележете, че добавих алтернативна форма за множествено число, защото от това, което намерих чрез онлайн търсенията, е практична настройка да имаш множество абонати.

„Абонат“ (може също да се разглежда като база данни с реплика) създава АБОНАМЕНТ за база данни „източник“ (издател), дефинираща информация за връзката и всички публикации, за които се абонира.

Възможно е абонат да бъде и издател, създавайки своя собствена ПУБЛИКАЦИЯ, за която други абонати могат да се абонират.

Какво се случва сега?

Всички промени в данните, които се случват на издателя, се изпращат на абоната. Което от кутията е всичко, но може да бъде конфигурирано или ограничено до определени операции (т.е. INSERT, UPDATE или DELETE).

Пример за високо ниво:

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

Ето няколко неща, които трябва да запомните, които почувствах достойни да спомена:

• Конфигурацията на базата данни на издателя wal_level трябва да бъде настроена на логическа.
• Логическата репликация няма DDL (език за дефиниране на данни) команди.
• От страницата „Конфликти“ в документацията:„Логическата репликация се държи подобно на нормалните DML операции, тъй като данните ще бъдат актуализирани, дори ако са били променени локално на абонатния възел. Ако входящите данни нарушават някакви ограничения, репликацията ще спре. Това се нарича конфликт. При репликиране на операции UPDATE или DELETE липсващите данни няма да доведат до конфликт и такива операции просто ще бъдат пропуснати."
• Таблиците на издателя трябва да имат начин да се идентифицират (наречен „идентичност на реплики“), за да репликират правилно DML операции (АКТУАЛИЗИРАНЕ и ИЗТРИВАНЕ) във всяка реплика(и) за тези засегнати редове. Ако таблицата има първичен ключ, това е по подразбиране (на мен ми се струва звуков избор), но при липса на първичен ключ са налични други опции за конфигурация. Целият ред може да се използва, ако не съществува друг кандидат ключ (наречен "пълен"), въпреки че в документацията се споменава, че това обикновено не е ефективно решение. (Вижте раздела REPLICA IDENTITY в документите за описание на по-ниско ниво как да го настроите)

Ограничения

Документацията в раздел 31.4. Restrictions има някои ключови напомняния за ограниченията, които ще премълча. Уверете се и прегледайте свързаната страница по-горе за точно многословие.

• Схемата на базата данни и всички DDL команди не се поддържат в репликацията. Предполага се, че може би pg_dump може да се използва първоначално, но все пак ще трябва да актуализирате всички по-нататъшни промени и напредък в схемата до всички реплики сами.
• Данните в колоните на последователността ще бъдат репликирани. Но самата последователност би отразявала само началната стойност. За четене е добре. Но ако това е вашият начин за преодоляване на срив, ще трябва сами да АКТУАЛИЗИРАТЕ до текущата стойност. Документите предлагат pg_dump тук.
• Отрязването все още не се поддържа.
• Репликацията на голям обект не се поддържа.
• Изгледи, материализирани изгледи, основни таблици на дялове или чужди таблици не се поддържат нито от издателя, нито от абоната.

Докладвани често срещани случаи на употреба

• Вие се интересувате само от определени данни и промени в данните, които действително репликирате, спрямо просто репликиране на цялата база данни.
• Когато имате нужда от реплика(и) за операции само за четене, като сценарий за анализ.
• Разрешаване на потребители или различни подгрупи потребители с ограничен или наблюдаван достъп до данни.
• Разпространение на данни.
• Съвместимост с други версии на PostgreSQL.

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

От проучване, четене и изучаване на поточно репликация, едно нещо, което разбирам отпред, е да избера да настроя или асинхронна (по подразбиране), или синхронна репликация.

А, още непознати термини, а?

Ето моята дефиниция на „високо ниво“ и за двете:

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

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

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

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

Ето официалното обяснение от раздел 26.2.8. Синхронна репликация в официалната документация:

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

Друг пасаж от документацията има хубаво резюме на това, което трябва да бъде (според мен), огромна полза:„Единствената възможност данните могат да бъдат загубени е ако и основният, и резервният претърпяват сривове едновременно.“

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

Добре, знаем, че трябва да изберем една от тези конфигурации за настройка, но каква е цялостната същност?

Накратко, Streaming Replication изпраща и прилага WAL (Write Ahead Log) файлове от един сървър на база данни (главен или основен) към „реплика“ (получаваща база данни).

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

Точки за поточно репликация

• По подразбиране репликацията на поточно предаване е асинхронна, което означава, че има закъснение (може би малко) между ангажиментите транзакции на главния и тяхната видимост в репликата.
• Реплика(и) се свързват с главната чрез мрежова връзка.
• Внимавайте за удостоверяването. Вижте тук от документацията:„Много е важно правата за достъп за репликация да бъдат настроени така, че само доверени потребители да могат да четат WAL потока, защото е лесно да се извлече привилегирована информация от него“

Кога да се използва поточно репликация

• Честа употреба (особено в анализа) предоставя реплика „само за четене“ за премахване на натоварването от основния сървър.
• Имате нужда от среда с висока наличност.
• Полезна настройка за преминаване при отказ към сървър в горещ режим на готовност, ако основният изпадне.