Как да репликирате PostgreSQL данни на отдалечени сайтове

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

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

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

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

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

Защо да използвате репликация на ниво таблица?

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

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

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

Различни фактори, влияещи върху репликацията на ниво таблица – какво да търсите

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

Структура на таблицата

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

Размер на данни

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

Инфраструктурни ресурси

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

CPU

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

Мрежа

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

Памет

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

Актуализации на изходната таблица

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

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

Как да внедрите репликация на таблица

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

Нека да разгледаме някои от тези инструменти, техните характеристики и възможности...

Слони

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

Нека разгледаме някои възможности на Slony...

Предимства от използването на Slony

• Поддържа методология за репликация от главен към подчинен или множество подчинени устройства, което спомага за подобряване на хоризонталната мащабируемост на четене. С други думи, робите не могат да се записват
• Конфигурирането на множество подчинени устройства към един главен е възможно и също така поддържа методология за каскадна репликация
• Поддържа механизми за превключване и отказ
• Голям брой таблици могат да бъдат репликирани в групи, паралелно
• Можем да репликираме между различни основни версии на екземпляри на PostgreSQL, което прави Slony чудесен вариант за надстройки на база данни
• Лесен за инсталиране

Недостатъци от използването на Slony

• Не поддържа DDL репликация
• Някои промени в схемата могат да нарушат репликацията
• Събитията на репликация се регистрират в базата данни в специфични за Slony регистрационни таблици, които могат да представляват допълнителни разходи за поддръжка.
• Ако огромен брой таблици с големи набори от данни трябва да бъдат репликирани, тогава производителността и поддръжката могат да представляват сериозни предизвикателства
• Тъй като репликация, базирана на тригери, производителността може да бъде засегната

Букардо

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

Нека разгледаме различните типове механизми за репликация, които bucardo помага да приложи...

• Многоглавна репликация:Таблиците могат да бъдат репликирани в двете посоки между два или повече екземпляра на PostgreSQL и транзакционните данни ще се синхронизират двупосочно
• Master-slave:Данните от таблиците в master ще бъдат репликирани на подчинен асинхронно и подчинен е достъпен за операции за четене.
• Режим на пълно копиране (главен-подчинен):Bucardo -/репликиране на всички данни от главния към подчинения възел чрез изтриване на всички данни от подчинения

Предимства от използването на Bucardo

• Лесен за инсталиране
• Поддържа режими на мулти-главен, главен-подчинен и пълно копиране
• Може да се използва за надграждане на бази данни
• Репликацията може да се извърши между различни версии на PostgreSQL

Недостатъци от използването на Bucardo

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

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

Логическата репликация е революционна вградена функция на PostgreSQL, която помага за репликиране на отделни таблици чрез WAL записи. Като WAL базирана репликация (подобно на поточно репликация), pg logical се откроява в сравнение с други инструменти за репликация на таблици. Репликирането на данни чрез WAL записи винаги е най-надеждният и ефективен начин за репликиране на данни в мрежата. Почти всички инструменти на пазара осигуряват репликация, базирана на тригери, с изключение на логическата репликация.

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

• Най-добрият вариант, когато искате да репликирате една таблица или набор от таблици
• Това е добър вариант, ако изискването е да се мигрират конкретни таблици от различни бази данни в една единствена база данни (като съхранение на данни или бази данни за отчети) за отчетни или аналитични цели
• Без проблеми със задействания

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

• Неправилното управление на WAL файлове / WAL архивни файлове може да създаде предизвикателства пред логическата репликация
• Не можем да репликираме таблици без първични или уникални ключове
• DDL и TRUNCATE не се репликират
• Закъснението при репликация може да се увеличи, ако WAL се премахнат. Това означава, че репликацията и управлението на WAL трябва да се допълват взаимно, за да се гарантира, че репликацията няма да се счупи
• Големи обекти не могат да бъдат репликирани

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

Обвивки на чужди данни

Въпреки че обвивките на чужди данни всъщност не репликират данните, исках да подчертая тази функция на PostgreSQL, защото може да помогне на DBA да постигнат нещо подобно на репликацията, без реално да репликират данните. Това означава, че данните не се репликират от източник на цел и данните могат да бъдат достъпни от приложения от целевата база данни. Целевата база данни има само структура на таблица с връзка, съдържаща подробности за хост и база данни за изходната таблица и когато приложението запитва целевата таблица, тогава данните се изтеглят от изходната база данни към целевата база данни, подобно на връзките към базата данни. Ако FDW могат да помогнат, тогава можете напълно да избегнете излишните разходи за репликиране на данните по мрежата. Много пъти попадаме в ситуация, при която отчетите могат да се изпълняват в отдалечена целева база данни, без да е необходимо данните да присъстват физически.

FDW са чудесен вариант в следните ситуации -

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

Предимства от използването на обвивки на чужди данни

• Репликирането на данни може да бъде напълно избегнато, което може да спести време и ресурси
• Лесен за прилагане
• Изтеглените данни винаги са най-новите
• Без поддръжка

Недостатъци от използването на външни обвивки на данни

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

Заключение

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