Добре дошли в сайта на PostgreSQL  България.

Какво е Slony (http://slony.info)?

- Репликация:

1. Един мастър сървър.

2. Множество слейв сървъри.

3. Асинронна.

4. Осъществява се чрез тригери.

- Слейв сървъри:

1. Разрешава само четене от репликираната таблица (read-only).

2. Възможност за писане и четене с останалите таблици.

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

Инсталация на Slony:

Ще разгледам инсталацията за CentOS 6 като използвам хранилището на PostgreSQL и примем, че работим с PostgreSQL 9.4(не искам да се впускам в компилиране от сорс, понеже не това е темата на статията)

rpm -Uvh http://yum.postgresql.org/9.4/redhat/rhel-6-x86_64/pgdg-centos94-9.4-1.noarch.rpm

yum -y install slony1-94

като този начин ще инсталираме всички необходими инструменти е /usr/pgsql-9.4/bin/.

След като вече имаме инсталирано Slony ще разгледаме следната ситуация. Имаме 1 мастър и 1 слейв сървър, които се намират на различни физически или виртуални машини.

Управление на PostgreSQL потребителите:

• Slon софтуера трябва да може да се свързва със сървърите.

• Добра идея е да си направим отделен потребител, който да се използва само за тази цел.

• Трябва потребителя да бъде суперпотребител.

• Трябва да има парола и е препоръчително да се свързва с md5 авторизация.

• Примерна команда за създаване на потребителя:

CREATE USER slony WITH PASSWORD 'supersecret';

ALTER ROLE slony WITH SUPERUSER;

Създаване на локален .pgpass файл:

10.0.0.1:5432:b1:slony:supersecret

10.0.0.2:5432:b1:slony:supersecret

Не забравяйте да направите chmod 600 на файла.

Създаване на мастър база данни b1:

# createdb b1

като 10.0.0.1 е мастъра, а 10.0.0.2 е слейв сървъра.

Нека създадем примерна таблица като е задължително да има primary key:

CREATE TABLE t1(

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

CREATE LANGUAGE plpgsql;

За да имат свързаност между двата сървъра, то PostgreSQL съврите трябва да слушат на външния си интефейс, а не само на localhost. Отваряте postgresql.conf файла и променяте следния ред:

listen_addresses = '*'

и следва рестарт и на двата сървъра:

/etc/init.d/postgresql restart

До тук имаме видимост между двата сървъра, но сега е необходимо да разрешим да могат да комуникират помежду си. За целта е необходимо да добавим следните редове в pg_hba.conf файла:

host b1 slony 10.0.0.1/32 md5

host b1 slony 10.0.0.2/32 md5

и след това:

/etc/init.d/postgresql reload

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

На мастър сървъра създаваме скрипт със следните команди:

• Деклариране на клъстъра:

cluster name = 'repli1';

• Деклариране на нодовете:

node 1 admin conninfo='dbname=b1 host=10.0.0.1 user=slony';

node 2 admin conninfo='dbname=b1 host=10.0.0.2 user=slony';

• Казваме на Slony кои нод е мастъра:

init cluster (id=1, comment='Sofia');

• Създаване на сет:

create set (id=1, origin=1,

comment='All tables and sequences from b1');

• Добавяне на таблици към сета:

set add table (set id=1, origin=1, id=1,

fully qualified name = 'public.t1',

comment = 'Accounts table');

• Добавяне на слейв сървъра:

store node (id=2, comment='Plovdiv', event node=1);

• Добавяне на пътища между мастер и слейв сървъра:

store path (server=1, client=2,

conninfo='dbname=b1 host=10.0.0.1 user=slony');

store path (server=2, client=1,

conninfo='dbname=b1 host=10.0.0.2 user=slony');

• Абонираме слейв сървъра (id 2) към сета (1, all tables):

subscribe set (id = 1,

provider = 1,

receiver = 2,

forward = no);

Събираме всички правила в един файл (slon_repl) и ги стартираме с slonik бинарката:

/usr/pgsql-9.4/bin/slonik slon_repl

Ако всичко е наред, то трябва да се случат следните неща:

• Създаване на нова схема (_repli1);

• Множество таблици в по-горе посочената схема;

• Тригери на таблицата, която ще репликираме.

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

Новата схема:

• Името и зависи от това какво име сте сложили на клъстъра в слъчая _repli1.

• Речник таблици - sl_node, sl_path, sl_tables, sl_sequences, ...

• Работни таблици - sl_log_1, sl_log_2, sl_event, ...

Новите тригери:

b1=# \d t1

Table "public.t1"

Column | Type | Modifiers

----------+---------------+-----------

bid | integer | not null

bbalance | integer |

filler | character(88) |

Indexes:

"t1_pkey" PRIMARY KEY, btree (bid)

Triggers:

_repli1_logtrigger

AFTER INSERT OR DELETE OR UPDATE ON t1

FOR EACH ROW

EXECUTE PROCEDURE _repli1.logtrigger('_repli1', '2', 'k')

Disabled triggers:

_repli1_denyaccess

BEFORE INSERT OR DELETE OR UPDATE ON t1

FOR EACH ROW

EXECUTE PROCEDURE _repli1.denyaccess('_repli1')

Конфигуриране и стартиране на демоните на мастър и слейв сървърите:

На мастъра:

/usr/pgsql-9.4/bin/slon repli1 “host=10.0.0.1 user=slony dbname=b1”

На слейва:

/usr/pgsql-9.4/bin/slon repli1 “host=10.0.0.2 user=slony dbname=b1”

като може да се използва §, за да бъдат демонизирани.

И всичко трябва да работи!

• Всеки запис, който се поднови на репликираната таблица на мастър съвръра, ще се запише чрез тригерите в log таблиците локално.

• Slon демона от своя страна ще предаде промените към слейв сървъра;

• Промяна на записа на репликираната таблица на слейв сървъра не е разрешена.

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