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

Всяка версия на PostgreSQL идва с няколко основни подобрения на функциите, но това, което е също толкова интересно е, че всяка версия подобрява и предишните си функции.

Тъй като PostgreSQL 13 трябва да бъде пуснат скоро, е време да проверим какви функции и подобрения ни предлага общността. Едно такова безшумно подобрение е „Подобрение на логическата репликация за разделяне.“

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

Терминология

Два термина, които са важни за разбирането на тази функция са:

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

Таблици с дялове

Начин за разделяне на голяма маса на множество физически части за постигане на ползи като:

Подобрена производителност на заявката
По-бързи актуализации
По-бързо групово зареждане и изтриване
Организиране на рядко използвани данни на бавни дискови устройства

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

Таблица е разделена на базата на:

Списък
Хеш
Обхват

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

Както подсказва името, това е метод на репликация, при който данните се репликират постепенно въз основа на тяхната идентичност (напр. ключ). Не е подобно на WAL или методите за физическа репликация, при които данните се изпращат байт по байт.

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

Селективна репликация (само част от базата данни)
Едновременно записва в две копия на база данни, където данните се репликират
Репликация между различни операционни системи (напр. Linux и Windows)
Подробна сигурност при репликация на данни
Задейства изпълнение, когато данните пристигат от страната на получателя

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

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

Следват стъпките за установяване и подчертаване на подобрението, което се прави в PostgreSQL 13 в този контекст.

Настройка

Помислете за настройка с два възела за стартиране на два различни екземпляра, съдържащи разделена таблица:

Стъпките за Instance_1 са както следва след влизане на потребител 192.168.56.101 като postgre :

$ initdb -D ${HOME}/pgdata-1

$ echo "listen_addresses = '192.168.56.101'"  >> ${HOME}/pgdata-1/postgresql.conf

$ echo "wal_level = logical"                  >> ${HOME}/pgdata-1/postgresql.conf

$ echo "host postgres all 192.168.56.102/32 md5" >> ${HOME}/pgdata-1/pg_hba.conf

$ pg_ctl -D ${HOME}/pgdata-1 -l logfile start

Настройката „wal_level“ е зададена специално на „логически“, за да посочи, че логическата репликация ще се използва за репликиране на данни от този екземпляр. Конфигурационният файл „pg_hba.conf“ също е променен, за да позволи връзки от 192.168.56.102.

# CREATE TABLE stock_sales

( sale_date date not null, unit_sold  int, unit_price int )

  PARTITION BY RANGE ( sale_date );

# CREATE TABLE stock_sales_y2017 PARTITION OF stock_sales

  FOR VALUES FROM ('2017-01-01') TO ('2018-01-01'); 

# CREATE TABLE stock_sales_y2018 PARTITION OF stock_sales

  FOR VALUES FROM ('2018-01-01') TO ('2019-01-01');

# CREATE TABLE stock_sales_default

  PARTITION OF stock_sales DEFAULT;

Въпреки че ролята postgres е създадена по подразбиране в базата данни Instance_1, трябва да се създаде и отделен потребител с ограничен достъп – което ограничава обхвата само за дадена таблица.

# CREATE ROLE rep_usr WITH REPLICATION LOGIN PASSWORD 'rep_pwd';

# GRANT CONNECT ON DATABASE postgres TO rep_usr;

# GRANT USAGE ON SCHEMA public TO rep_usr;

# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep_usr;

Изисква се почти подобна настройка на Instance_2

$ initdb -D ${HOME}/pgdata-2

$ echo "listen_addresses = '192.168.56.102'"  >> ${HOME}/pgdata-2/postgresql.conf

$ pg_ctl -D ${HOME}/pgdata-2 -l logfile start

Трябва да се отбележи, че тъй като Instance_2 няма да бъде източник на данни за друг възел, настройките на wal_level, както и файлът pg_hba.conf не се нуждаят от допълнителни настройки. Излишно е да казвам, че pg_hba.conf може да се нуждае от актуализиране според нуждите на производството.

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

Настройка на логическа репликация

Настройката на логическата репликация става много по-лесна с PostgreSQL 13. До PostgreSQL 12 структурата беше както следва:

С PostgreSQL 13 публикуването на дялове става много по-лесно. Вижте диаграмата по-долу и сравнете с предишната диаграма:

С настройки, бушуващи със 100 и 1000 на разделени simp таблици – това е малко променено simp таблици неща до голяма степен.

В PostgreSQL 13 операторите за създаване на такава публикация ще бъдат:

CREATE PUBLICATION rep_part_pub FOR TABLE stock_sales 

WITH (publish_via_partition_root);

Конфигурационният параметър publish_via_partition_root е нов в PostgreSQL 13, което позволява на възела получател да има малко по-различна йерархия на листа. Простото създаване на публикация върху разделени таблици в PostgreSQL 12 ще върне изявления за грешка, както е по-долу:

ERROR:  "stock_sales" is a partitioned table

DETAIL:  Adding partitioned tables to publications is not supported.

HINT:  You can add the table partitions individually.

Пренебрегвайки ограниченията на PostgreSQL 12 и продължавайки да използваме тази функция в PostgreSQL 13, трябва да установим абонат на Instance_2 със следните изявления:

CREATE SUBSCRIPTION rep_part_sub CONNECTION 'host=192.168.56.101 port=5432 user=rep_usr password=rep_pwd dbname=postgres' PUBLICATION rep_part_pub;

Проверка дали наистина работи

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

В Instance_1 вмъкнете няколко реда, като се уверите, че те се появяват в множество дялове:

# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2017-09-20', 12, 151);# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2018-07-01', 22, 176);

# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2016-02-02', 10, 1721);

Проверете данните на Instance_2:

# SELECT * from stock_sales; 

sale_date  | unit_sold | unit_price

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

 2017-09-20 |    12 |    151

 2018-07-01 |    22 |    176

 2016-02-02 |    10 |   1721

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

Добавете друг дял към Instance_1 и вмъкнете запис:

# CREATE TABLE stock_sales_y2019

      PARTITION OF stock_sales 

     FOR VALUES FROM ('2019-01-01') to ('2020-01-01');

# INSERT INTO stock_sales VALUES(‘2019-06-01’, 73, 174 );

Проверете данните на Instance_2:

# SELECT * from stock_sales;

 sale_date  | unit_sold | unit_price

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

 2017-09-20 |    12 |    151

 2018-07-01 |    22 |    176

 2016-02-02 |    10 |   1721

 2019-06-01 |    73 |   174

Други функции за разделяне в PostgreSQL 13

Има и други подобрения в PostgreSQL 13, които са свързани с разделянето на дялове, а именно:

Подобрения в свързването между разделени таблици
Разделените таблици вече поддържат ПРЕДИ тригери на ниво ред

Заключение

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