Basics Of PostgreSQL · AboutNet

AboutNet all about networks

Basics Of PostgreSQL

Часть “Архитектура PostgreSQL” является конспектом лекций Postgres Professional.

Архитектура PostgreSQL

Изначально при старте PostgreSQL запускается процесс postmaster. Он:

  1. Создает структуры в памяти, которые будут использоваться другими процессами;
  2. Создает все остальные процессы (fork) и управляет ими (перезапуск и т.д.);
  3. Слушает входящие соединения и на каждого клиента создает отдельный серверный процесс postgres.

Организация данных

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

Массив буферов

Часто используемые страницы остаются в буферном кэше, редко используемые заменяются. Страницы записываются на диск время от времени (процесс background writer). Иногда серверный процесс также может инициировать запись данных на диск.

Транзакции

  1. Атомарность - либо выполняются все изменения, либо ни одно из них;
  2. Согласованность (целостность данных) - система переходит из одного целостного состояния в другое;
  3. Изоляция - на результат не должны оказывать влияния другие транзакции. Postgres поддерживает 3 уровня изоляции из 4 (commit не поддерживается);
  4. Долговечность - зафиксированные изменения не теряются (подробнее в секции про WAL).

Журнал (Write Ahead Log)

Общая идея - при выполнении любых изменений в журнал записывается информация, достаточная для повторения данных изменений. Данная информация должна попасть на диск раньше, чем запишутся сами изменения (процесс wal writer). При пропадании из буфера данных, которые не успели записаться на диск (перезагрузка и т.д.) они восстанавливаются из WAL. Информация записывается в файлы по 16 МБ по умолчанию (возможна архивация старых файлов процессом wal archiver). Возможна синхронная (надежно), либо асинхронная (быстро) запись.

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

Многоверсионность (MVCC)

Каждая транзакция работает со снимком (snapshot). На нижнем уровне, когда в таблицу вставляется/удаляется строка, в ней отмечается номер транзакции, которая создала/удалила данную строку.

Периодически (либо вручную) запускается процесс vacuum, который очищает версии строк, недоступные более ни в одном снимке.

Базовая настройка потоковой репликации

Шпаргалка по мотивам https://eax.me/postgresql-replication/

Вкратце - потоковая репликация в PostgreSQL это передача WAL от мастера к репликам. Работает только в пределах одной архитектуры, а также одной версии PostgreSQL.

Настройка репликации от имени пользователя postgres (ограничения доступа по IP отсутствуют) производится следующим образом

Master

pg_hba.conf
host    replication      postgres       0.0.0.0/0           md5
host    all              postgres       0.0.0.0/0           md5
postgresql.conf
listen_addresses = '*'
wal_level = hot_standby
wal_log_hints = on
max_wal_senders = 8
wal_keep_segments = 64
hot_standby = on

Slave

Для выполнения следующего действия необходимо, чтобы директория с БД (в примере main) была пустой. Будет целесообразно сделать резервную копию предыдущего содержимого, либо параллельно изменить данную директорию в postgresql.conf (data_directory). Действие выполняется при остановленном процессе PostgreSQL.

pg_basebackup -P -R -X stream -c fast -h master_ip -U postgres -D ./main

После этого БД будет скопирована на slave, также будет создан файл recovery.conf, описывающий параметры репликации.

pg_hba.cong и postgresql.conf требуется отредактировать аналогично файлам на master.

Далее можно запустить PostgreSQL на slave и убедиться, что репликация запустилась, с использованием следующего запроса на master:

SELECT * FROM pg_stat_replication;

Следует отметить, что читать можно как с master, так и со slave (по крайней мере в данном примере), но писать, по понятным причинам, можно только в master.

Самый простой способ превратить slave в standalone ноду (например, при миграции БД между серверами) - удалить файл recovery.conf и перезапустить PostgreSQL.

PgBouncer

Утилита, созданная для проксирования соединений к PostgreSQL (для каждого соединения по умолчанию создается отдельный процесс). PgBouncer объединяет некоторое количество соединений клиентов в пул и тратит только одно соединение сервера на их обработку.

Базовая конфигурация (без учета требований к безопасности):

pgbouncer.ini
[databases]
* = host=localhost port=5432
postgres = dbname=postgres
auth_type = trust
admin_users = postgres

[pgbouncer]
listen_addr = *
listen_port = 6432
userlist.txt 
"postgres" "postgres"
Categories: SQL