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

Логическа репликация или Pglogical е механизъм за репликация на ниво таблица, базиран на WAL, който репликира данните от конкретни таблици между два екземпляра на PostgreSQL. Изглежда има объркване между „pglogical“ и „Logical Replication“. И двете предоставят един и същ вид механизъм за репликация с някои разлики в характеристиките и възможностите. Логическата репликация е въведена в PostgreSQL-10 като вградена функция за разлика от pglogical, която е разширение. „Pglogical“ с продължаващо непрекъснато развитие остава като единствената опция за внедряване на логическа репликация за тези среди, използващи PostgreSQL версии преди 10. В крайна сметка всички функции, част от pglogical, ще бъдат част от логическата репликация. С други думи, pglogical (разширение) се превърна в логическа репликация (вградена функция). Основното предимство на логическата репликация е, че не се нуждае от инсталиране/създаване на разширения, което от своя страна е от полза за онези среди, където инсталирането на разширения е ограничено.

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

Логическата репликация е репликация, базирана на WAL, която е първата по рода си. Като DBA, това би било много по-надежден и ефективен механизъм за репликация в сравнение с други решения за репликация, базирани на тригери. Промените, направени в таблиците, част от pglogical репликация, се репликират в реално време чрез WAL записи, което я прави високоефективна и несложна. Всички други механизми за репликация на пазара са базирани на тригери, което може да създаде предизвикателства при производителността и поддръжката. С навлизането на логическата репликация зависимостта от репликация, базирана на тригери, почти изчезна.

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

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

Оптимизиране на логическата репликация

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

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

Фактори, влияещи върху производителността на логическата репликация

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

• Типът на данните, съхранявани в таблиците, които ще бъдат репликирани
• Колко транзакционно активни са таблиците (част от репликацията)
• Трябва да се предвиди капацитетът на инфраструктурата
• Конфигурирането на параметрите трябва да бъде направено оптимално

Всички горепосочени фактори влияят в по-голяма степен на логическата репликация. Нека ги разгледаме подробно.

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

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

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

При репликиране на много транзакционно активни таблици, репликацията може да изостава в синхронизирането поради проблеми с I/O производителността, блокиране и т.н., което трябва да се вземе предвид. Това може да не направи средата на производствената база данни да изглежда по-здравословна. Ако броят на репликираните таблици е голям и данните се репликират на множество сайтове, тогава може да има голямо използване на процесора и да са необходими повече процесори (или ядра на процесора).

Капацитет на инфраструктурата

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

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

Оптимизиране на параметри за логическа репликация

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

Нека първо да разгледаме параметрите, необходими за конфигурирането му:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Настройване на max_wal_senders

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

Настройка на max_replication_slots

Като цяло, всички промени в данните, настъпващи в таблиците, се записват в WAL файлове в pg_xlog / pg_wal, които се наричат ​​WAL записи. Процесът на изпращача на Wal ще вземе тези WAL записи (принадлежащи на таблиците, които се реплицират) и ще ги изпрати до репликите, а процесът wal_receiver в сайта на репликата ще приложи тези промени към възела на абоната.

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

Настройка на max_worker_processes

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

Настройка на max_logical_worker_processes

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

Настройка на max_sync_workers_per_subscription

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

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

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

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

Заключение

Специфичните за репликация таблици са често срещано изискване, което възниква в големи и сложни системи за бази данни. Това може да бъде за целите на бизнес отчитане или съхранение на данни. Като DBA вярвам, че логическата репликация се грижи в голяма степен за такива цели поради лесното си изпълнение с по-малко сложност. Конфигурирането и настройката на логическата репликация изисква добро количество планиране, архитектура и тестване. Количеството данни, които се реплицират в реално време, трябва да бъде оценено, за да се гарантира, че е налице ефективна и безпроблемна система за репликация. В заключение, бази данни, работещи в PostgreSQL-10, логическата репликация е правилният начин, а за тези бази данни, работещи във версии на PostgreSQL <10, опцията е pglogical.