Базы данных on Sysadminium

Репликация в PostgreSQL

Mon, 21 Jun 2021 00:00:00 +0000

Задачи и виды репликации

Репликация PostgreSQL решает две задачи:

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

Репликация на серверах PostgreSQL бывает двух видов:

Физическая — основной сервер передает поток wal записей на сервер репликации. Требования следующие:
- одинаковые версии PostgreSQL;
- одинаковые ОС;
- возможна репликация только всего кластера.
Логическая — поставщик публикует свои изменения, а подписчик получает и применяет эти изменения у себя. Особенности следующие:
- оба сервера могут быть и поставщиком и подписчиком, но на разные объекты. Например на в одном кластере опубликована одна табличка, а на другом — другая, и эти кластера подписаны друг на друга (на эти таблички). Это позволяет использовать двухсторонний обмен;
- репликация возможна между разными ОС;
- возможна выборочная репликация отдельных объектов кластера.

Физическая репликация PostgreSQL

Алгоритм создания такой репликации следующий:

Резервирование PostgreSQL

Fri, 18 Jun 2021 00:00:00 +0000

Введение

Существует логическое и физическое резервирование PostgreSQL. Первый тип сохраняет SQL команды выполнив которые можно восстановить объекты, например создать базу данных, наполнить её таблицами, заполнить таблицы данными и тому подобное. А второй тип резервирует сами данные, то есть сохраняет каталог PGDATA.

Логическое резервирование PostgreSQL

Недостаток логического копирования — невысокая скорость. При этом логическую копию можно загрузить в более новую версию сервера postgres. Или выгрузить базу с сервера на Windows и загрузить её на Linux. Также логическое резервное копирование позволяет сохранять не только базы, но и отдельно таблички или весь кластер.

Методы аутентификации в PostgreSQL

Thu, 17 Jun 2021 00:00:00 +0000

Процесс подключения

Процесс подключение можно разделить на три этапа:

Идентификация — определение имени роли базы данных.
Аутентификация — проверка того, что пользователь тот за кого себя выдаёт. Есть много разных методов аутентификации, например проверка пароля.
Авторизация — проверка прав этого пользователя. Например может ли этот пользователь подключаться к этой базе данных или нет.

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

Политики защиты строк (RLS) в PostgreSQL

Thu, 10 Jun 2021 00:00:00 +0000

Что такое политики защиты строк

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

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

Один предикат применяется для существующих строк и используется командами:

Привилегии в PostgreSQL

Thu, 10 Jun 2021 00:00:00 +0000

Привилегий для разных объектов

Каждый вид объектов имеет разный набор привилегий, таблицы например имеют самый большой набор:

SELECT — чтение данных;
INSERT — вставка данных;
UPDATE — изменение строк;
REFERENCES — внешний ключ (право ссылаться на таблицу);
DELETE — удаление строк;
TRUNCATE — очистка таблицы;
TRIGGER — создание триггеров.

Представления имеют всего две привилегии:

SELECT — право читать представление;
TRIGGER — право создавать триггеры.

Последовательности:

SELECT — право читать последовательность;
UPDATE — право изменять последовательность;
USAGE — право использовать последовательность.

Табличные пространства:

Роли и атрибуты в PostgreSQL

Thu, 03 Jun 2021 00:00:00 +0000

Теория

Псевдороль public неявно включает в себя все остальные роли. Её нельзя найти в списке ролей, но она существует.

У ролей есть несколько атрибутов. Эти атрибуты указываются при создании роли:

LOGIN / NOLOGIN — возможность подключения;
SUPERUSER / NOSUPERUSER — суперпользователь;
CREATEDB / NOCREATEDB — возможность создавать базы данных;
CREATEROLE / NOCREATEROLE — возможность создавать роли;
REPLICATION / NOREPLICATION— использование протокола репликации;
и другие.

Создают роль следующим способом:

CREATE ROLE <роль> [WITH] <атрибуты через запятую>;

Если при создании роли не указать атрибуты, то роль получит запрещающие атрибуты (NOLOGIN, NOSUPERUSER) автоматом.

Мониторинг индексов в PostgreSQL и их перестроение

Wed, 02 Jun 2021 00:00:00 +0000

Поиск неиспользуемых индексов

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

В представлении pg_stat_all_indexes в поле idx.scan вы можете увидеть количество обращений к индексу. Если там ноль, значит индекс не используется и возможно его следует удалить. Но следует точно понимать что вы делаете, и перепроверить все перед удалением таких индексов.

Процедура очистки VACUUM в PostgreSQL

Wed, 02 Jun 2021 00:00:00 +0000

Варианты запуска очистки

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

Очищать таблицы или базы данных от ненужных версий строк можно с помощью следующих команд:

VACUUM таблица; — очищает таблицу;
VACUUM; — базу данных;
$ vacuumdb — обёртка для использования в ОС.

Процедура VACUUM выполняется параллельно с другими транзакциями. При этом частый запуск нагружает систему, редкий запуск приводит к росту размера файлов. Подробнее почитать про очистку PostgreSQL можно тут . Мы уже встречались с понятием VACUUM в статье Изоляция и многоверсионность в Postgresql .

Разрастание таблиц и индексов в PostgreSQL

Wed, 02 Jun 2021 00:00:00 +0000

Подключаем расширение pgstattuple

В начале скомпилируем расширение pgstattuple , которое поможет понять сколько в базе данных полезной информации, а сколько служебной или неактуальной. Для этого перейдем в каталог с исходниками и выполним:

postgres@s-pg13:~$ exit
выход

root@s-pg13:~# cd ~/pg/postgresql-13.3/contrib/pgstattuple/
root@s-pg13:~/pg/postgresql-13.3/contrib/pgstattuple# make
root@s-pg13:~/pg/postgresql-13.3/contrib/pgstattuple# make install
root@s-pg13:~/pg/postgresql-13.3/contrib/pgstattuple# su - postgres

Затем подключим расширение в самой базе данных с помощью команды CREATE EXTENSION:

postgres@s-pg13:~$ psql
Timing is on.
psql (13.3)
Type "help" for help.

postgres@postgres=# CREATE EXTENSION pgstattuple;
CREATE EXTENSION
Time: 45,688 ms

Проводим тестирование

Создадим табличку bloat и наполним её данными. После чего сделаем для этой таблицы индекс:

Журнал PostgreSQL. Настройка и анализ

Mon, 31 May 2021 00:00:00 +0000

Введение

При запуске PostgreSQL, мы можем указать файл журнала: pg_ctl start -l /home/postgres/logfile.

В этот журнал PostgreSQL записывает некоторые из своих действий. Настраивая журналирование мы можем задать:

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

Если сейчас заглянуть в журнал и посмотреть последние строчки в которых есть слово FATAL, то можно увидеть следующее:

postgres@s-pg13:~$ grep FATAL /home/postgres/logfile | tail
2021-06-28 16:49:47.333 MSK [15360] FATAL: terminating connection due to administrator command

FATAL: terminating connection due to administrator command — это завершение процесса с помощью функции pg_terminate_backend(pid). Это мы проделывали на прошлом уроке .

Текущие активности в PostgreSQL

Sun, 30 May 2021 00:00:00 +0000

Введение

Что в этой статье будет рассмотрено:

Вы можете посмотреть на текущие активности сервера PostgreSQL с помощью представления pg_stat_activity .
Чтобы завершить один из обслуживающих процессов нужно использовать функцию pg_terminate_backend(<pid>).
Вы можете, с помощью функции pg_blocking_pids(<pid>), посмотреть кого ожидает процесс с этим pid.

Все эти действия можно выполнить с помощью инструментов командной строки операционной системы:

посмотреть процессы с помощью команды ps;
завершить процесс с помощью команды kill -9 <pid>.

Но операционная система не сможет определить чем занят процесс postgress, поэтому ps не будет столь-же информативен, как представление pg_stat_activity.

Статистика работы PostgreSQL

Tue, 25 May 2021 00:00:00 +0000

Теория

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

Статистика PostgreSQL включается конфигурационными параметрами в файле postgresql.conf, например:

track_counts — обращения к таблицам и индексам. Этот параметр включен по умолчанию.
track_io_timing — статистика операций ввода/вывода. Этот параметр выключен по умолчанию, в результате нужно включать. Но следует учитывать что включение этого параметра может замедлить сервер;
track_functions — статистика вызовов функций и времени их выполнения. Этот параметр, тоже выключен по умолчанию. Если мы захотим включить его, то можем указать следующие значения:
- pl — включает отслеживание функций только на процедурном языке,
- all — включает отслеживание функций на всех языках, например SQL и C.

Каждый backend процесс собирает статистику в процессе своей работы. Затем эта статистика отправляется процессу stats collector, который собирает статистику со всех backend процессов. Раз в полсекунды, статистика сбрасывается в каталог $PGDATA/pg_stat_tmp, этот период (500мс) можно изменить только при компиляции. В результате эту статистику можно посмотреть с помощью представлений и функций.

Слои данных и TOAST таблицы в PostgreSQL

Mon, 24 May 2021 00:00:00 +0000

Слои

Подробнее про физическое хранение базы данных можете почитать тут .

Каждый файл занимает не больше 1 GB и кратен 8 KB. Поэтому если таблица больше 1 GB, то она хранится в нескольких файлах. Файлы состоят из 8 KB страниц, которые в случае необходимости помещаются в буферный кэш.

Существуют следующие слои:

Основной слой (main) — сами данные. Этот слой существует у всех объектов;
Слой инициализации (init) — существует только для нежурналируемых таблиц. Содержит пустую копию таблицы. В случае сбоя PostgreSQL не пытается восстановить нежурналируемую таблицу, а перезаписывает её пустой таблицей из этого слоя. Поэтому после сбоя нежурналируемые таблицы окажутся пустыми.
Карта свободного пространства (fsm) — хранит информацию о том, где внутри файлов есть свободное пространство.
Карта видимости (vm) — отмечает страницы, в которых все версии строк видны. Другими словами VACUUM уже их почистил от неактуальных версий строк. Такой слой существует только для таблиц. Он нужен для оптимизации, чтобы VACUUM знал, какие страницы чистить уже не нужно.

Работа с большими строками (TOAST)

В PostgreSQL одна строка должна помещаться в одну страницу, то есть не быть больше 8 КБ. Чтобы поместить большую строку у PostgreSQL есть следующие стратегии:

Табличные пространства в PostgreSQL

Fri, 21 May 2021 00:00:00 +0000

Теория

Вы можете почитать про табличные пространства в документации .

При инициализации кластера создаются 2 табличных пространства:

pg_default — табличное пространство по умолчанию, находится в каталоге $PGDATA/base;
pg_global — пространство для общих объектов системного каталога, $PGDATA/global.

PostgreSQL позволяет создать свои табличные пространства и использовать их для каких-либо объектов. Например для баз данных, таблиц и других объектов.

Каталог $PGDATA/base разбит на подкаталоги по идентификаторам баз данных.

Когда мы создаём своё табличное пространство, мы сами указываем нужный каталог. При этом PostgreSQL создает символическую ссылку $PGDATA/pg_tblspc/<TS_OID> на указанный каталог (/путь/ver/dboid).

Системный каталог в PostgreSQL

Tue, 18 May 2021 00:00:00 +0000

Системный каталог PostgreSQL

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

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

То есть, если мы создадим новую базу данных, то её описание можно будет получить из системного каталога. Если мы в базе данных создадим таблицу, то её описание будет в системном каталоге.

Схемы и шаблоны в СУБД PostgreSQL

Mon, 17 May 2021 00:00:00 +0000

Базы данных и шаблоны

Когда мы создаём новые кластер командой initdb у нас создается 3 одинаковые базы данных:

postgres
template0
template1

postgres@s-pg13:~$ psql
Timing is on.
psql (13.3)
Type "help" for help.

postgres@postgres=# \l
 List of databases
 Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 postgres | postgres | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 |
 template0 | postgres | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres +
 | | | | | postgres=CTc/postgres
 template1 | postgres | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres +
 | | | | | postgres=CTc/postgres
(3 rows)

База postgres используется, чтобы по умолчанию к ней подключаться. Принципиально она не нужна, но есть приложения которым она может понадобится, поэтому лучше её не удалять.

Буферный кэш и журнал WAL в PostgreSQL

Wed, 05 May 2021 00:00:00 +0000

Устройство буферного кэша

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

В общей памяти отводится определённый кусок памяти под массив буферов. В каждом буфере хранится одна страница памяти. Страница памяти это 8 КБ. Когда мы собираем PostgreSQL из исходных кодов мы можем изменить размер этой страницы. А после сборки это изменить уже не получится.

Изоляция и многоверсионность в Postgresql

Tue, 04 May 2021 00:00:00 +0000

Многоверсионность

Представим следующие ситуации на сервере баз данных:

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

В первом случае проблем не возникает. Несколько процессов могут одновременно читать одну и туже строчку без всяких сложностей.

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

Общее устройство PostgreSQL

Fri, 23 Apr 2021 00:00:00 +0000

Клиент серверная работа PostgreSQL

PostgreSQL эта сервер который обслуживает базы данных SQl. К нему подключаются клиенты и с помощью SQL запросов работают с этими базами. Клиентские приложения могут быть расположены на сервере приложений или прямо на компьютере пользователя.

Клиент — это какое-то приложение, например psql. Клиент с сервером общается по определённому протоколу. Протокол у PostgreSQL открытый, но для каждого приложения его не нужно реализовывать. Обычно используют стандартные библиотеки и драйверы. Основная библиотека это libpq, её использует psql и все штатные утилиты PostgreSQL. Для многих языков программирования есть свои библиотеки, которые основаны на libpq.