Експертно ръководство за Slony репликация за PostgreSQL

Какво е Slony?

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

Slony работи, като инсталира тригери на всяка таблица, която трябва да се репликира, както на главен, така и на подчинен, и всеки път, когато таблицата получи INSERT, UPDATE или DELETE, записва кой запис се променя и каква е промяната. Външните процеси, наречени „демони на slon“, се свързват с базите данни като всеки друг клиент и извличат промените от главния, след което ги възпроизвеждат на всички подчинени възли, абонирани за главния. При добре работеща настройка за репликация, това асинхронно може да се очаква репликацията да изостава от 1 до 20 секунди от главния.

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

Талисманът на PostgreSQL е слон, известен като „Слоник“, което на руски означава „малък слон“. Тъй като този проект за репликация се отнася до много бази данни на PostgreSQL, които се реплицират една с друга, се използва руската дума за слонове (множествено число):Slony.

Концепции

• Клъстер:екземпляр на Slony репликация.
• Възел:Специфична PostgreSQL база данни като възел за репликация Slony, който работи като главен или подчинен за набор от репликация.
• Набор за репликация:Група от таблици и/или последователности, които трябва да бъдат репликирани.
• Абонати:Абонатът е възел, който е абониран за набор от репликация и получава събития за репликация за всички таблици и последователности в този набор от главния възел.
• Slony Daemons:Основните работници, които изпълняват репликация, демон Slony се стартира за всеки възел в набора за репликация и установява различни връзки към възела, който управлява, както и към главния възел.

Как се използва

Slony се инсталира или от източник, или чрез PGDG (PostgreSQL Global Development Group) хранилища, които са достъпни за Linux дистрибуции, базирани на Red Hat и Debian. Тези двоични файлове трябва да бъдат инсталирани на всички хостове, които ще съдържат или главен, или подчинен възел в системата за репликация.

След инсталирането се настройва клъстер за репликация на Slony чрез издаване на няколко команди с помощта на двоичния файл „slonik“. 'slonik' е команда с прост, но уникален собствен синтаксис за инициализиране и поддържане на slony клъстер. Това е основният интерфейс за издаване на команди към работещия клъстер Slony, който отговаря за репликацията.

Взаимодействието със Slony може да се извърши или чрез писане на персонализирани команди slonik, или чрез компилиране на slony с флага --with-perltools, който предоставя скриптовете „altperl“, които помагат за генерирането на тези необходими slonik скриптове.

Създаване на клъстер Slony Replication

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

• Желаното име на клъстера Slony
• Информацията за връзката за всяка част на възела от репликацията, всяка с неизменяем номер на възел.
• Изброяване на всички таблици и последователности, които ще бъдат репликирани като част от „репликационен набор“.

Примерен скрипт може да се намери в официалната документация на Slony.

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

Умни конфигурации

Докато Slony първоначално е система за репликация от Master-to-Multiple-Slave и се използва главно по този начин, има няколко други функции и умни употреби, които правят Slony по-полезен от простото решение за репликация. Силно адаптивната природа на Slony го поддържа подходящ за различни ситуации за администратори, които могат да мислят извън кутията.

Каскадна репликация

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

Обработка на данни на подчинен възел

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

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

Минимални надстройки на престой

Надстройката на основните версии на PostgreSQL може да отнеме изключително много време. В зависимост от размера на данните и броя на таблицата, надстройката, включваща процеса на „анализ“ след надстройката, може да отнеме дори няколко дни. Тъй като Slony може да репликира данни между PostgreSQL клъстери от различни версии, той може да се използва за настройка на репликация между по-стара версия като главна и по-нова версия като подчинена. Когато ъпгрейдът трябва да се случи, просто извършете „превключване“, правейки подчинения нов главен, а старият господар става подчинен. Когато надстройката бъде отбелязана успешно, изведете от експлоатация клъстера за репликация Slony и изключете старата база данни.

Висока наличност с честа поддръжка на сървъра

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

Изпращане на дневници

Въпреки че е малко вероятно да бъде популярно решение, Slony slave може да бъде настроен като възел за „доставяне на дневници“, където всички данни, които получава чрез репликация, могат да бъдат записани в SQL файлове и изпратени. Това може да се използва по различни причини, като например запис на външно устройство и транспортиране до подчинена база данни ръчно, а не по мрежа, компресиран и съхраняван в архив за бъдещи архиви или дори външна програма да анализира SQL файловете и променете съдържанието.

Споделяне на данни от множество бази данни

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

Отложена репликация

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

Неща, които трябва да знаете:

• Всички DDL промени в таблици, които са част от репликация, трябва да се изпълнят с помощта на командата slonik execute.
• Всяка таблица, която трябва да бъде репликирана, трябва да има или първичен ключ, или УНИКАЛЕН индекс без колони с нула.
• Данните, които се реплицират от главния възел, се реплицират, след като всички данни може да са били генерирани функционално. Това означава, че ако данните са генерирани с помощта на нещо като „random()“, полученото число се съхранява и репликира на подчинените, вместо „random()“ да се изпълнява отново на подчинения, връщайки различен резултат.
• Добавянето на Slony репликация ще увеличи леко натоварването на сървъра. Макар и ефективно написана, всяка таблица ще има тригер, който регистрира всяко INSERT, UPDATE и DELETE в таблица Slony, очаквайте около 2-10% увеличение на натоварването на сървъра, в зависимост от размера на базата данни и работното натоварване.

Съвети и трикове:

• Slony демоните могат да работят на всеки хост, който има достъп до всички други хостове, но най-високопроизводителната конфигурация е демоните да се изпълняват на възлите, които управляват. Например главният демон, работещ на главния възел, подчинения демон, работещ на подчинения възел.
• Ако се настрои клъстер за репликация с много голямо количество данни, първоначалното копие може да отнеме доста време, което означава, че всички промени, които се случват от началото до приключване на копието, могат да означават още повече време за наваксване и синхронизиране . Това може да бъде решено или чрез добавяне на няколко таблици наведнъж към репликация (отнема много време), или чрез създаване на копие на директория с данни на главната база данни към подчинения, след което се прави „набор за абонамент“ с опцията OMIT COPY, зададена на вярно. С тази опция Slony ще приеме, че подчинената таблица е 100% идентична с главната и няма да я изчисти и ще копира данните.
• Най-добрият сценарий за това е да създадете Hot Standby с помощта на вградените инструменти за PostgreSQL и по време на прозорец за поддръжка с нулеви връзки, модифициращи данни, пренесете режима на готовност онлайн като главен, валидирайте съвпаденията на данните между двете, инициирайте slony репликационен клъстер с ПРОПУСКАНЕ НА COPY =true и накрая повторно активиране на клиентски връзки. Това може да отнеме време, за да се извърши настройката за Hot Standby, но процесът няма да причини огромно отрицателно въздействие върху клиентите.

Общност и документация

Общността за Slony може да бъде намерена в пощенските списъци, намиращи се на адрес http://lists.slony.info/mailman/listinfo/slony1-general, която включва и архиви.

Документацията е достъпна на официалния уебсайт, http://slony.info/documentation/, и предоставя помощ за анализ на регистрационни файлове и спецификация на синтаксиса за взаимодействие със slony.