Какой тип репликации используется в кластерах postgresql

Кластер Hot Standby PostgreSQL

В дополнение к статье «Кластер PostgreSQL» для катастрофоустойчивости можно использовать отдалённый географически Standby кластер PostgreSQL, который обеспечивает высокий уровень доступности и аварийного восстановления. Standby кластер PostgreSQL содержит только резервные узлы, реплицирующиеся с какого-либо удалённого мастера https://patroni.readthedocs.io/en/latest/replica_bootstrap.html#standby-cluster.

Этот тип кластеров имеет:

• резервный лидер, который ведёт себя почти так же, как обычный лидер кластера, за исключением того, что он реплицируется с удалённого мастера;
• каскадные реплики, которые реплицируются из резервного лидера.

Шаг 1: Настройка PostgreSQL

1. На всех серверах баз данных добавьте в конфигурационный файл pg_hba.conf информацию о всех узлах каждого кластера, чтобы разрешить соединения с разных серверов:

#Patroni
host all all 0.0.0.0/0 md5
#Cluster hosts 1
host replication replicator 192.168.1.1/32 md5
host replication replicator 192.168.1.2/32 md5
host replication replicator 192.168.1.3/32 md5
#Standby сluster hosts 2
host replication replicator 192.168.2.1/32 md5
host replication replicator 192.168.2.2/32 md5
host replication replicator 192.168.2.3/32 md5

1. Перезапустите PostgreSQL на всех узлах:

systemctl restart postgresql

Шаг 2: Настройка Patroni

1. На серверах Standby кластера в конфигурационном файле /etc/patroni/config.yml поменяйте значения scope , name , которые не должны совпадать с основным кластером. Замените адреса всех серверов:

scope: postgres-cluster2 # одинаковое значение на всех узлах Standby кластера
name: postgresql-server4 # разное значение на всех узлах Standby кластера

1. Добавьте раздел standby_cluster в секцию bootstrap, dcs в текущий конфигурационный файл /etc/patroni/config.yml и укажите удалённого мастера, который в данном примере определяется через haproxy:

bootstrap:
dcs:
standby_cluster:
host: haproxy-server.your_domain
port: 5000
create_replica_methods:
— basebackup

1. На основном и Standby кластере добавьте адреса всех серверов, используемых в кластерах в раздел pg_hba в текущий конфигурационный файл /etc/patroni/config.yml :

pg_hba:
— host all all 0.0.0.0/0 md5
— host replication replicator localhost trust
#Cluster hosts 1
— host replication replicator 192.168.1.1/32 md5
— host replication replicator 192.168.1.2/32 md5
— host replication replicator 192.168.1.3/32 md5
#Cluster hosts 2
— host replication replicator 192.168.2.1/32 md5
— host replication replicator 192.168.2.2/32 md5
— host replication replicator 192.168.2.3/32 md5

1. Запустите службу Patroni :

sudo systemctl enable —now patroni.service

Если ранее служба Patroni была запущена на Standby кластере, то на каждом узле Standby кластера остановите службу Patroni. Удалите каталог данных postgresql, очистите информацию о кластере и повторно запустите службу Patroni:

sudo systemctl stop patroni
sudo rm -rf / var /lib/postgresql/10/main
sudo etcdctl rm —recursive /service/postgres-cluster2
sudo systemctl restart patroni

1. Проверьте состояние Standby кластера:

patronictl -c /etc/patroni/config.yml list

Идентификатор кластера должен совпадать с основным кластером, роль у лидера должна быть Standby Leader.

1. В случае недоступности основного кластера для смены режима Standby кластера на основной удалите раздел standby_cluster из текущей конфигурации patroni с помощью команды:

patronictl edit-config —force -s standby_cluster.host=» -s standby_cluster.port=» -s standby_cluster.create_replica_methods=»

Важно не допустить работы двух мастеров, в момент восстановления вышедшего ранее основного кластера он также останется мастером.

1. После восстановления вышедшего ранее основного кластера для смены режима с основного на Standby кластер добавьте раздел standby_cluster в текущую конфигурацию patroni с помощью команды:

patronictl edit-config —force -s standby_cluster.host=haproxy-server.your_domain -s standby_cluster.port=5000 -s standby_cluster.create_replica_methods=’- basebackup’

Шаг 3: Конфигурация HAproxy (блок postgres)

Дополните конфигурацию HAproxy блока postgres указав адреса всех серверов, используемых в кластерах:

listen postgres_master
bind haproxy-server.your_domain:5000
option tcplog
option httpchk OPTIONS /master
http-check expect status 200
default -server inter 3s fastinter 1s fall 3 rise 4 on-marked-down shutdown-sessions
server postgres-server1 postgres-server1.your_domain:5432 check port 8008
server postgres-server2 postgres-server2.your_domain:5432 check port 8008
server postgres-server3 postgres-server3.your_domain:5432 check port 8008
server postgres-server4 postgres-server4.your_domain:5432 check port 8008
server postgres-server5 postgres-server5.your_domain:5432 check port 8008
server postgres-server6 postgres-server6.your_domain:5432 check port 8008

listen postgres_replicas
bind haproxy-server.your_domain:5001
option tcplog
option httpchk OPTIONS /replica
balance roundrobin
http-check expect status 200
default -server inter 3s fastinter 1s fall 3 rise 2 on-marked-down shutdown-sessions
server postgres-server1 postgres-server1.your_domain:5432 check port 8008
server postgres-server2 postgres-server2.your_domain:5432 check port 8008
server postgres-server3 postgres-server3.your_domain:5432 check port 8008
server postgres-server4 postgres-server4.your_domain:5432 check port 8008
server postgres-server5 postgres-server5.your_domain:5432 check port 8008
server postgres-server6 postgres-server6.your_domain:5432 check port 8008

Как настроить репликацию в PostgreSQL

Настраиваем репликацию данных в PostgreSQL на двух виртуальных серверах.

Эта инструкция — часть курса «PostgreSQL для новичков».

Смотреть весь курс

Введение

В статье мы расскажем, что такое репликация и где она применяется. Также на примере двух виртуальных серверов настроим репликацию данных в PostgreSQL и проверим, что она работает.

Что такое репликация

Репликация — это дублирование данных, когда данные с одного сервера полностью повторяются на других. Приложения пишут данные в одну базу данных PostgreSQL, а изменения автоматически синхронизируются на другие базы.
Репликация используется для достижения двух целей:

• Повышение отказоустойчивости. Если один из серверов выйдет из строя, то остальные продолжат работу.
• Повышение производительности. Распределение данных по серверам в разных частях страны или мира повышает скорость доступа к данным для местных пользователей.

Виды репликации в PostgreSQL

Существует несколько видов репликаций, у каждого из них свои особенности. Но прежде чем рассказывать о видах, нужно хотя бы поверхностно познакомиться с WAL — журналом предзаписи транзакций.

Когда PostgreSQL получает команду на изменение данных, она не сразу изменяет их на диске. Сначала она записывает изменения в WAL. Этот журнал нужен для того, чтобы в случае сбоя сервера можно было восстановить незафиксированные данные. Также WAL используется и для репликации данных.

Итак, в PostgreSQL есть несколько видов репликации:

Потоковая репликация (Streaming Replication). Это репликация, при которой от основного сервера PostgreSQL на реплики передается WAL. И каждая реплика затем по этому журналу изменяет свои данные. Для настройки такой репликации все серверы должны быть одной версии, работать на одной ОС и архитектуре. Потоковая репликация в Postgres бывает двух видов — асинхронная и синхронная.

• Асинхронная репликация. В этом случае PostgreSQL сначала применит изменения на основном узле и только потом отправит записи из WAL на реплики. Преимущество такого способа — быстрое подтверждение транзакции, т.к. не нужно ждать пока все реплики применят изменения. Недостаток в том, что при падении основного сервера часть данных на репликах может потеряться, так как изменения не успели продублироваться.
• Синхронная репликация. В этом случае изменения сначала записываются в WAL хотя бы одной реплики и только после этого фиксируются на основном сервере. Преимущество — более надежный способ, при котором сложнее потерять данные. Недостаток — операции выполняются медленнее, потому что прежде чем подтвердить транзакцию, нужно сначала продублировать ее на реплике.

Логическая репликация (Logical Replication). Логическая репликация оперирует записями в таблицах PostgreSQL. Этим она отличается от потоковой репликации, которая оперирует физическим уровнем данных: биты, байты, и адреса блоков на диске. Возможность настройки логической репликации появилась в PostgreSQL 10.
Этот вид репликации построен на механизме публикации/подписки: один сервер публикует изменения, другой подписывается на них. При этом подписываться можно не на все изменения, а выборочно. Например, на основном сервере 50 таблиц: 25 из них могут копироваться на одну реплику, а 25 — на другую.
Также есть несколько ограничений, главное из которых — нельзя реплицировать изменения структуры БД. То есть если на основном сервере добавится новая таблица или столбец — эти изменения не попадут в реплики автоматически, их нужно применять отдельно.
В отличие от потоковой репликации, логическая может работать между разными версиями PostgreSQL, ОС и архитектурами.

Облачные базы данных

Готовые к работе управляемые базы данных MySQL с встроенной репликацией.

Установить PostgreSQL

Перейдем к практике: настроим потоковую асинхронную репликацию в режиме Master-Replica: один сервер — основной, в него можно писать данные, другой — реплика, из него можно только читать.

На примере платформы Selectel создадим два отдельных сервера PostgreSQL, один из которых будет основным (Master), а второй — репликой (Replica).

В панели управления платформой заходим в раздел Облачная платформа — Серверы, нажимаем кнопку Создать сервер.

Укажем имя сервера — Master. Так нам будет проще ориентироваться в серверах. Выберем ОС — Ubuntu 22.04, конфигурацию — 2 vCPU, 8 ГБ оперативной памяти и 10 ГБ диска.

В разделе Сеть нужно выбрать подсеть с публичным адресом, чтобы к виртуальной машине можно было подключаться из интернета. В разделе Доступ нужно проверить, что вы либо записали пароль root-пользователя, либо указали правильный SSH-ключ для подключения к машине.

По такому же принципу создаем второй сервер, только укажем другое имя — Replica. Остальные параметры оставим такими же.
В итоге у нас получилось два сервера. Обратите внимание, что у них есть публичные и приватные IP-адреса.

Публичные адреса мы будем использовать для подключения к машинам, а приватные — для настройки репликации.

Теперь нужно подключиться к каждому серверу по SSH. Рекомендуем открыть 2 окна терминала и держать их открытыми, потому что мы будем часто переключаться между серверами.

Итак, подключаемся к серверам и устанавливаем PostgreSQL на каждом из них:

apt-get update apt-get install postgresql 

Все, сервера готовы к настройке репликации. Сейчас они ничем не отличаются друг от друга, кроме названия. Перейдем к настройке каждого из них.

Настроить Master-сервер

Репликацию будем выполнять под пользователем postgres, который автоматически создается после установки PostgreSQL. Установим ему пароль, он нам понадобится позже:

su - postgres psql -c "ALTER ROLE postgres PASSWORD 'ВАШ_ПАРОЛЬ'" exit 

Далее нужно разрешить этому пользователю подключаться из Replica-сервера в Master. Для этого мы отредактируем файл /etc/postgresql/12/main/pg_hba.conf.
Обратите внимание, что мы показываем настройку репликации на примере PostgreSQL 12, поэтому в пути к файлу есть номер — 12. Если у вас другая версия PostgreSQL, то вам нужно поменять путь к файлу.

Итак, откроем файл:

nano /etc/postgresql/12/main/pg_hba.conf 

Найдем в нем строчку «If you want to allow non-local connections, you need to add more» и впишем после нее такую строчку:

host replication postgres REPLICA_ВНУТРЕННИЙ_IP/32 md5

Так мы разрешаем пользователю postgres подключаться к этому серверу из Replica.

# If you want to allow non-local connections, you need to add more # “host” records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_address # configuration parameter, or via the -i or -h command line switches. host replication postgres 192.168.0.3/32 md5 

Обратите внимание, что мы используем приватные адреса, потому что виртуальные машины находятся в одной сети. При этом нам не нужно открывать порты, настраивать Firewall и так далее. Если ваши машины будут находиться в разных сетях или вы хотите, чтобы они общались друг с другом по публичным адресам — скорее всего вам придется настроить Firewall.
Далее нужно указать настройки репликации. Открываем конфигурационный файл PostgreSQL:

nano /etc/postgresql/12/main/postgresql.conf 

Находим в нем эти параметры, раскомментируем их и подставляем указанные значения.

listen_addresses = 'localhost, MASTER_ВНУТРЕННИЙ_IP' wal_level = hot_standby archive_mode = on archive_command = 'cd .' max_wal_senders = 8 hot_standby = on 

Все, Master настроен. Чтобы применить настройки, перезапускаем сервер:

service postgresql restart 

Настроить Replica-сервер

Переключаемся в окно терминала Replica-сервера. Перед началом настройки нужно остановить PostgreSQL-сервер:

service postgresql stop 

Аналогично Master-серверу отредактируем файл pg_hba.conf. В то же самое место вставим ту же самую строчку, но только теперь укажем IP-адрес мастера.

nano /etc/postgresql/12/main/pg_hba.conf 

Добавляем в него строчку:

host replication postgres MASTER_ВНУТРЕННИЙ_IP/32 md5 

Затем правим файл postgresql.conf. Настройки те же самые, как и у Master, только нужно поменять IP-адрес. Открываем файл на редактирование:

nano /etc/postgresql/12/main/postgresql.conf 

Находим в нем эти параметры, раскомментируем их и подставляем указанные значения:

listen_addresses = 'localhost, REPLICA_ВНУТРЕННИЙ_IP' wal_level = hot_standby archive_mode = on archive_command = 'cd .' max_wal_senders = 8 hot_standby = on 

Сейчас настройки обоих серверов одинаковые, отличаются только IP-адреса. Это потому, что при необходимости реплики могут становиться мастером, а вся разница будет в наличии одного лишь файла. О нем расскажем далее.
Прежде чем Replica-сервер сможет начать реплицировать данные, нужно создать новую БД, идентичную Master-серверу. Для этого воспользуемся утилитой pg_basebackup. Она создаст бэкап с Master-сервера и скачает его на Replica-сервер. Эту операцию нужно выполнять от имени пользователя postgres, поэтому логинимся от него:

su - postgres 

Далее переходим в каталог с базой данных:

cd /var/lib/postgresql/12/ 

Удалим каталог с дефолтной БД и снова его создадим, но уже пустой:

rm -rf main; mkdir main; chmod go-rwx main 

Теперь выгрузим БД с мастера. Для выполнения этой команды нужно будет ввести пароль от пользователя postgres, который мы задавали в самом начале настройки Master-сервера.

pg_basebackup -P -R -X stream -c fast -h MASTER_ВНУТРЕННИЙ_IP -U postgres -D ./main 

В этой команде есть важный параметр -R. Он означает, что PostgreSQL-сервер также создаст пустой файл standby.signal. Несмотря на то, что файл пустой, само наличие этого файла означает, что этот сервер — реплика.

Файл standby.signal появился только в PostgreSQL версии 12. Раньше вместо него создавался файл recovery.conf, в котором хранились настройки для подключения к Master-серверу. Имейте это ввиду, если вы используете более ранние версии PostgreSQL.

Возвращаемся в root-пользователя и запускаем PostgreSQL-сервер:

exit service postgresql start 

Проверить репликацию

Теперь нужно протестировать репликацию и убедиться, что мы все правильно настроили. На Master-сервере создадим таблицу и вставим в нее одну строчку:

su - postgres psql -c "CREATE TABLE test_table (id INT, name TEXT);" psql -c "INSERT INTO test_table (id, name) VALUES (1, 'test');" 

Переключимся в терминал Replica-сервера и проверим, что таблица с данными появилась:

su - postgres psql -c "SELECT * FROM test_table;" 

 id | name ----+------ 1 | test (1 row) 

Еще одна проверка — попробуем создать новую таблицу на сервере Replica. Если мы все сделали правильно, то сервер не должен позволить нам этого сделать, потому что он настроен только на репликацию с основной БД.
На Replica-сервере выполняем команду:

psql -c "CREATE TABLE test_table2 (id INT, name TEXT);" 

ERROR: cannot execute CREATE TABLE in a read-only transaction 

Значит репликация настроена правильно.
Теперь покажем, как можно из Replica-сервера сделать Master. Сымитируем ситуацию, что основной сервер вышел из строя. Для этого в консоли управления платформой Selectel просто выключим сервер Master.

Чтобы перевести Replica-сервер в режим записи, выполните команду:

/usr/lib/postgresql/12/bin/pg_ctl promote -D /var/lib/postgresql/12/main 

Проверяем, снова пробуем создать новую таблицу:

psql -c "CREATE TABLE test_table2 (id INT, name TEXT);" 

На этот раз таблица создастся. Значит, мы перевели сервер из режима чтения в режим записи.
Но нужно понимать, что запросы от приложений не начнут автоматически направляться на этот сервер. Если сервисы и приложения подключались к «старому» Master-серверу напрямую, они так и будут пытаться подключаться к нему.

Обычно в такой ситуации используется балансировщик нагрузки. Он сам следит за состоянием серверов и распределяет нагрузку между всеми рабочими инстансами. При этом приложения отправляют запросы не напрямую в СУБД, а в балансировщик нагрузки.

Заключение

В статье мы показали, как настроить репликацию в PostgreSQL и проверить ее. Это не сложно, но требует некоторой подготовки. Есть и другой способ — использовать managed-решения.
На нашей платформе есть управляемая PostgreSQL, которая создается в несколько кликов мыши. Вам не придется настраивать и сопровождать СУБД, а репликация и балансировщик нагрузки есть «из коробки». Если Master-сервер выйдет из строя, платформа автоматически переключит одну из реплик в режим записи и перенаправить на нее все запросы.

Установка и использование PostgreSQL в Ubuntu 22.04

Резервное копирование и восстановление PostgreSQL: pg_dump, pg_restore, wal-g

Зарегистрируйтесь в панели управления

И уже через пару минут сможете арендовать сервер, развернуть базы данных или обеспечить быструю доставку контента.

Читайте также:

Инструкция

Как создать 100 серверов в облаке за минуту? Работа с OpenStack клиентом

Инструкция

Как создать веб-приложение на базе Telegram Mini Apps

Инструкция

Что делает команда chmod и как ее использовать в Linux

Настройка потоковой репликации PostgreSQL

Обновлено: 10.01.2024 Опубликовано: 04.05.2019

Тематические термины: PostgreSQL. Репликация PostgreSQL представляет из себя способ реализации отказоустойчивого кластера. Инструкция написана на примере PostgreSQL 14/13/12/11/10/9.6, также она будет работать для PostgreSQL 9.2 (все нюансы будут отмечены отдельными комментариями). В данном примере мы настроим потоковую (streaming) репликацию. Другой тип репликации (логическая) добавлена в PostgreSQL 10. Она позволяет реплицировать разные базы данных и таблицы на разные реплики. Также, мы будем применять асинхронную репликацию — это вид репликации, при котором запросы выполняются сначала на мастере, затем попадают в журнал операций (WAL) и только после этого — на slave. При синхронной репликации запросы сначала попадают в WAL — после в мастер и слейв. Используемые в данном руководстве команды, применимы для операционных систем Linux. Если Postgre работает под Windows, данную инструкцию можно использовать как шпаргалку для настройки конфигурационных файлов СУБД.

1. Подготовка серверов

Для начала, готовим наши серверы к настройке кластера.

PostgreSQL

На всех серверах баз данных должна быть установлена одна и та же версия PostgreSQL. Также, все серверы должны иметь одну и ту же архитектуру процессора. Вот пример установки сервера PostgreSQL на CentOS 7.

Брандмауэр

При использовании брандмауэра, необходимо открыть TCP-порт 5432 — он используется сервером postgre. а) Если управление выполняется с помощью Firewalld:

firewall-cmd —permanent —add-port=5432/tcp
firewall-cmd —reload
б) Если используем Iptables:
iptables -A INPUT -p tcp —dport 5432 -j ACCEPT
в) Если используем UFW:
ufw allow 5432/tcp

SELinux

Если активирована система безопасности SELinux (по умолчанию в системах Red Hat / CentOS / Fedora), отключаем ее:

setenforce 0
sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config
Если необходимо, чтобы SELinux работал, настраиваем его.

2. Настройки на Master

В данной статье мы будем настраивать серверы с IP-адресами 192.168.1.10 (первичный или master) и 192.168.1.11 (вторичный или slave). Переходим на сервер, с которого будем реплицировать данные (мастер) и выполняем следующие действия.

Создаем пользователя в PostgreSQL

Входим в систему под пользователем postgres:
su — postgres
Создаем нового пользователя для репликации:
createuser —replication -P repluser

* система запросит пароль — его нужно придумать и ввести дважды. В данном примере мы создаем пользователя repluser. Выходим из оболочки пользователя postgres:

Настраиваем postgresql

Смотрим расположение конфигурационного файла postgresql.conf командой:
su — postgres -c «psql -c ‘SHOW config_file;'»
В моем случае система вернула строку:
/etc/postgresql/9.6/main/postgresql.conf

* конфигурационный файл находится по пути /etc/postgresql/9.6/main/postgresql.conf. Открываем конфигурационный файл postgresql.conf.

vi /etc/postgresql/9.6/main/postgresql.conf

* мы открываем файл, который получили sql-командой SHOW config_file;. Редактируем следующие параметры:

listen_addresses = ‘localhost, 192.168.1.10’
wal_level = replica
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on
hot_standby_feedback = on

• 192.168.1.10 — IP-адрес сервера, на котором он будем слушать запросы Postgre;
• wal_level указывает, сколько информации записывается в WAL (журнал операций, который используется для репликации);
• max_wal_senders — количество планируемых слейвов;
• max_replication_slots — максимальное число слотов репликации (данный параметр не нужен для postgresql 9.2 — с ним сервер не запустится);
• hot_standby — определяет, можно или нет подключаться к postgresql для выполнения запросов в процессе восстановления;
• hot_standby_feedback — определяет, будет или нет сервер slave сообщать мастеру о запросах, которые он выполняет.

Открываем конфигурационный файл pg_hba.conf — он находитсяч в том же каталоге, что и файл postgresql.conf:

Добавляем следующие строки:

host replication repluser 127.0.0.1/32 md5
host replication repluser 192.168.1.10/32 md5
host replication repluser 192.168.1.11/32 md5

* данной настройкой мы разрешаем подключение к базе данных replication пользователю repluser с локального сервера (localhost и 192.168.1.10) и сервера 192.168.1.11.

Перезапускаем службу postgresql:

systemctl restart postgresql

* обратите внимание, что название для сервиса в системах Linux может различаться.

3. Настройки на Slave

Смотрим путь до конфигурационного файла postgresql:

su — postgres -c «psql -c ‘SHOW data_directory;'»

В моем случае путь был:

Также смотрим путь до конфигурационного файла postgresql.conf (нам это понадобиться ниже):

su — postgres -c «psql -c ‘SHOW config_file;'»

Останавливаем сервис postgresql:

systemctl stop postgresql

На всякий случай, создаем архив базы:

tar -czvf /tmp/data_pgsql.tar.gz /var/lib/pgsql/9.6/data

* в данном примере мы сохраним все содержимое каталога /var/lib/pgsql/9.6/data в виде архива /tmp/data_pgsql.tar.gz.

Удаляем содержимое каталога с данными:

rm -rf /var/lib/pgsql/9.6/data/*

И реплицируем данные с master сервера.

а) Если у нас postgresql 9:

su -u postgres -с «pg_basebackup -h 192.168.1.10 -U repluser -D /var/lib/pgsql/9.6/data —xlog-method=stream —write-recovery-conf»

* где 192.168.1.10 — IP-адрес мастера; /var/lib/pgsql/9.6/data — путь до каталога с данными.

б) Если у нас postgresql 10:

su — postgres -c «pg_basebackup —host=192.168.1.10 —username=repluser —pgdata=/var/lib/pgsql/10/data —wal-method=stream —write-recovery-conf»

* где 192.168.1.10 — IP-адрес мастера; /var/lib/pgsql/10/data — путь до каталога с данными.

После ввода команды система запросит пароль для созданной ранее учетной записи repluser — вводим его. Начнется процесс клонирования данных.

Открываем конфигурационный файл postgresql.conf на слейве:

И редактируем следующие параметры:

listen_addresses = ‘localhost, 192.168.1.11’

* где 192.168.1.11 — IP-адрес нашего вторичного сервера.

Снова запускаем сервис postgresql:

systemctl start postgresql

4. Проверка репликации

Посмотреть статус

Статус работы репликации можно посмотреть следующими командами.

=# select * from pg_stat_replication;

=# select * from pg_stat_wal_receiver;

Создать тестовую базу

На мастере заходим в командную оболочку Postgre:

su — postgres -c «psql»

Создаем новую базу данных:

=# CREATE DATABASE repltest ENCODING=’UTF8′;

Теперь на вторичном сервере смотрим список баз:

su — postgres -c «psql»

Мы должны увидеть среди баз ту, которую создали на первичном сервере:

Какой тип репликации используется в кластерах postgresql

Логическая репликация — это метод репликации объектов данных и изменений в них, использующий репликационные идентификаторы (обычно это первичный ключ). Мы называем такую репликацию «логической», в отличие от физической, которая построена на точных адресах блоков и побайтовом копировании. PostgreSQL поддерживает оба механизма одновременно; см. Главу 26. Логическая репликация позволяет более детально управлять репликацией данных и аспектами безопасности.

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

Логическая репликация таблицы обычно начинается с создания снимка данных в публикуемой базе данных и копирования её подписчику. После этого изменения на стороне публикации передаются подписчику в реальном времени, когда они происходят. Подписчик применяет изменения в том же порядке, что и узел публикации, так что для публикаций в рамках одной подписки гарантируется транзакционная целостность. Этот метод репликации данных иногда называется транзакционной репликацией.

Типичные сценарии использования логической репликации:

Передача подписчикам инкрементальных изменений в одной базе данных или подмножестве базы данных, когда они происходят.

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

Объединение нескольких баз данных в одну (например, для целей анализа).

Репликация между разными основными версиями PostgreSQL.

Репликация между экземплярами PostgreSQL на разных платформах (например, с Linux на Windows)

Предоставление доступа к реплицированным данным другим группам пользователей.

База данных подписчика функционирует так же, как и любой другой экземпляр базы PostgreSQL, и может стать публикующей, если создать публикации в ней. Когда подписчик действует как исключительно читающее приложение, никаких конфликтов с одной подпиской не будет. Но они могут возникнуть, если в тот же набор таблиц производят запись какие-либо приложения или другие подписчики.

Пред.	Наверх	След.
30.5. Внутреннее устройство WAL	Начало	31.1. Публикация