Разлика между поточна репликация и логическа репликация

TL;DR :Логическата репликация изпраща промени ред по ред, физическата репликация изпраща промени на дисковия блок. Логическата репликация е по-добра за някои задачи, физическата репликация за други.

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

Поточно репликиране може да бъде логическа репликация. Всичко е малко сложно.

WAL-доставка срещу стрийминг

Има два основни начина за изпращане на данни от главния към репликата в PostgreSQL:

Доставка WAL или непрекъснато архивиране , където индивидуалните регистрационни файлове за предварителен запис се копират от pg_xlog чрез archive_command работи на капитана на друго място. restore_command конфигуриран в recovery.conf на репликата изпълнява на репликата, за да извлече архивите, така че репликата да може да възпроизвежда WAL.

Това е, което се използва за репликация в даден момент (PITR), който се използва като метод за непрекъснато архивиране.

Не е необходима директна мрежова връзка към главния сървър. Репликацията може да има дълги забавяния, особено без archive_timeout комплект. WAL доставката не може да се използва за синхронна репликация.
поточно репликиране , където всяка промяна се изпраща до един или повече реплики на сървъри директно през TCP/IP връзка, както се случва. Репликите трябва да имат директна мрежова връзка, конфигурирана от главния в техния recovery.conf primary_conninfo на 's опция.

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

Следователно двата метода имат различни цели.

Асинхронно срещу синхронно поточно предаване

На всичкото отгоре има синхронен и асинхронен поточно репликиране:

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

Ако асинхронната реплика изостава твърде много от главната, главната може да изхвърли информацията, от която се нуждае репликата, ако max_wal_size (по-рано се наричаше wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's на капитана pg_wal(was pg_xlog) може да се запълни и да спре главния да работи, докато не се освободи дисково пространство, ако max_wal_size е твърде високо или се използва слот.
В синхронна репликация главният не завършва ангажирането, докато реплика не потвърди, че е получила транзакцията. Никога не губите данни, ако главният се срине и трябва да преминете към реплика. Главният никога няма да изхвърли данните, от които репликата се нуждае, или да запълни своя xlog и да остане без дисково пространство поради закъснения на репликата. В замяна това може да доведе до забавяне или дори спиране на работата на главния, ако репликите имат проблеми, и винаги има известно въздействие върху производителността на главния поради забавяне на мрежата.

Когато има множество реплики, само една е синхронна в даден момент. Вижте synchronous_standby_names .

Не можете да имате синхронно изпращане на журнали.

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

Логически срещу физически

Освен това това имаме логично срещу физически поточно репликиране, както е въведено в PostgreSQL 9.4:

Във репликация на физическо поточно предаване промените се изпращат почти на ниво дисков блок, като "при отместване 14 на дискова страница 18 на релация 12311, записа кортеж с шестнадесетична стойност 0x2342beef1222....".

Физическата репликация изпраща всичко :съдържанието на всяка база данни в инсталацията на PostgreSQL, всички таблици във всяка база данни. Изпраща индексни записи, изпраща цялата нова таблица с данни, когато VACUUM FULL , изпраща данни за транзакции, които са върнати назад и т.н. Така че генерира много „шум“ и изпраща много излишни данни. Също така изисква репликата да бъде напълно идентична, така че не можете да правите нищо, което изисква транзакция, като създаване на временни или нерегистрирани таблици. Запитването на репликата забавя репликацията, така че дългите заявки на репликата трябва да бъдат отменени.

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

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

логическа поточна репликация , нов в 9.4, изпраща промените на по-високо ниво и много по-селективно.

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

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

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

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

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

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

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

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

Твърде много опции, кажете ми какво да направя

уф. Сложно, а? И дори не навлязох в подробности за отложената репликация, слотовете, max_wal_size , графики, как работи промоцията, Postgres-XL, BDR и multimaster и др.

И така, какво трябва да направите ?

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

За архивиране и възстановяване след бедствие използвайте pgbarman за създаване на базови резервни копия и запазване на WAL за вас, осигурявайки лесно за управление непрекъснато архивиране. Все още трябва периодично да правите pg_dump резервни копия като допълнителна застраховка.

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

За висока достъпност с нисък риск от загуба на данни и по-добра производителност трябва да използвате асинхронна поточна репликация. Или имайте активирано WAL архивиране за резервен вариант, или използвайте слот за репликация. Наблюдавайте колко далеч е репликата зад главния, като използвате външни инструменти като Icinga.

Разлика между поточна репликация и логическа репликация

WAL-доставка срещу стрийминг

Асинхронно срещу синхронно поточно предаване

Логически срещу физически

Твърде много опции, кажете ми какво да направя

Препратки