Создание кластера баз данных
Эта страница переведена при помощи нейросети GigaChat.
Перед началом любых действий необходимо инициализировать область хранения базы данных на диске. Этот процесс называют кластером баз данных. (Стандарт SQL называет это набором каталогов.) Кластер баз данных представляет собой совокупность баз данных, управляемую одним экземпляром работающего сервера. После инициализации кластер баз данных будет содержать базу данных с именем postgres, предназначенную для использования различными инструментами, пользователями и сторонними приложениями в качестве базы данных по умолчанию. Сам сервер базы данных не требует обязательного присутствия базы данных postgres, но многие внешние инструменты ожидают ее наличия. В процессе инициализации внутри каждого кластера создаются две дополнительные базы данных: template1 и template0. Их названия отражают назначение — служить шаблоном для будущих баз данных; использовать их для реальных рабочих нагрузок не следует. (Подробности о создании новых баз данных в кластере можно найти в разделе Управление базами данных.)
С точки зрения файловой системы, кластер баз данных представлен одним каталогом, в котором хранится вся необходимая информация. Назовем его каталогом данных или областью данных. Местоположение этого каталога целиком зависит от администратора, и общепринятыми местами расположения являются /usr/local/pgsql/data или /var/lib/pgsql/data. Программа initdb, поставляемая вместе с PostgreSQL, должна быть использована для инициализации каталога данных перед первым использованием.
Если используется предварительно подготовленное программное обеспечение PostgreSQL, оно может предусматривать специальную схему размещения каталога данных и предлагать готовый сценарий для его создания. В таком случае лучше использовать этот сценарий, а не вызывать initdb напрямую. Подробности можно найти в документации, сопровождающей установленный пакет.
Чтобы вручную инициализировать кластер баз данных, запустите команду initdb, указывая местоположение каталога данных с помощью опции -D, например:
$ initdb -D /usr/local/pgsql/data
Стоит обратить внимание, что данная команда должна быть выполнена от имени учетной записи пользователя PostgreSQL, описанной в предыдущем разделе.
Вместо параметра -D можно установить переменную среды PGDATA.
Альтернативный подход заключается в запуске initdb через программу pg_ctl:
$ pg_ctl -D /usr/local/pgsql/data initdb
Этот метод может оказаться более удобным, если планируется использовать pg_ctl для запуска и остановки сервера (см. раздел Запуск сервера баз данных). Тогда pg_ctl станет основным инструментом для управления экземпляром сервера баз данных.
Программа initdb попробует создать указанный каталог, если он не существует. Однако если у нее нет необходимых прав на запись в родительский каталог, операция завершится неудачей. Рекомендуется, чтобы владельцем как самого каталога данных, так и его родительского каталога являлся пользователь PostgreSQL, что помогает избежать подобных ситуаций. Если нужного родительского каталога нет, его следует создать с правами суперпользователя, если родительский каталог недоступен для записи. Процедура может выглядеть следующим образом:
root# mkdir /usr/local/pgsql
root# chown postgres /usr/local/pgsql
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data
Если каталог данных уже существует и содержит файлы, initdb прекратит выполнение, предотвращая случайное уничтожение существующих данных.
Поскольку каталог данных хранит всю информацию, находящуюся в базе данных, критически важно защищать его от несанкционированного доступа. Initdb ограничивает доступ ко всем файлам и каталогам, делая их доступными только владельцу и группе PostgreSQL. Права доступа для группы ограничиваются чтением, позволяя непривилегированным членам группы, к которой принадлежит владелец кластера, выполнять резервное копирование данных или иные операции, требующие только права на чтение.
Следует понимать, что включение или выключение группового доступа для уже существующего кластера требует его останова и корректировки прав доступа для всех файлов и каталогов перед перезапуском PostgreSQL. В противном случае в каталоге данных могут остаться несогласованные режимы доступа. Для кластеров, предназначенных только для владельца, правильными режимами являются 0700 для каталогов и 0600 для файлов. Для кластеров с поддержкой группового доступа подойдут режимы 0750 для каталогов и 0640 для файлов.
Хотя защита содержимого каталога важна, стандартные настройки аутентификации клиентов позволяют любому локальному пользователю подключаться к базе данных и даже становиться суперпользователем. Чтобы минимизировать риски, рекомендуется воспользоваться параметрами initdb: -W, --pwprompt или --pwfile для установки пароля суперпользователя базы данных. Дополнительно можно указать параметр -A scram-sha-256, чтобы запретить использование режима аутентификации trust по умолчанию, либо скорректировать сгенерированный файл pg_hba.conf после выполнения initdb, но до первого запуска сервера. Среди других мер защиты — использование аутентификации peer или изменение настроек разрешений файловой системы для контроля подключений. Дополнительные сведения можно найти в разделе Аутентификация клиентов.
Процесс инициализации initdb также устанавливает локаль по умолчанию для кластера баз данных, основываясь на текущих настройках окружения. Локаль можно задать вручную, подробности изложены в разделе Поддержка локализации. Порядок сортировки для кластера баз данных фиксируется при помощи initdb и наследуется всеми базами данных-шаблонами. Его изменение невозможно без удаления и пересоздания базы данных. Следует учитывать, что локали, отличные от C или POSIX, могут оказывать влияние на производительность.
Одновременно с выбором локали, initdb устанавливает кодировку набора символов по умолчанию для кластера баз данных, обычно совпадающую с текущей локалью. Подробнее о выборе кодировок рассказано в разделе Поддержка набора символов.
Важно помнить, что использование нелокальных окружений C и POSIX зависит от библиотеки сравнения символов операционной системы. Вследствие этого нельзя перейти на несовместимую версию библиотеки, будь то при восстановлении копий, потоковой репликации, смене операционной системы или ее обновлении.
Рекомендуется избегать использования верхнего каталога вторичной файловой системы в качестве каталога данных. Вместо этого лучше создать подкаталог внутри точки монтирования, принадлежащей пользователю PostgreSQL, и расположить там каталог данных. Это предотвращает возникновение проблем с разрешениями и гарантирует правильное поведение в случае отключения вторичного тома.
Хотя PostgreSQL поддерживает работу с любой файловой системой, придерживающейся POSIX-семантики, опыт показывает, что небольшие изменения в конфигурации файловой системы или переход на другую файловую систему редко оказывают значительное влияние на производительность или поведение системы. Тем не менее, пользователи могут отдавать предпочтение определенным файловым системам исходя из соображений производительности, поддержки производителями или личного опыта.
При хранении данных на файловой системе NFS важно убедиться, что она смонтирована с опцией hard. Это предотвращает преждевременное завершение системных вызовов в случае сетевых проблем, что могло бы привести к ошибкам ввода-вывода.
Использование вторичных файловых систем
Часто кластеры баз данных размещают на файловых системах (томах), отличающихся от корневой файловой системы компьютера. Если решено поступить подобным образом, не рекомендуется использовать точку монтирования (верхний каталог вторичной файловой системы) в качестве каталога данных. Желательно создать подкаталог внутри каталога точки монтирования, принадлежащий пользователю PostgreSQL, и разместить в нем каталог данных. Такой подход позволяет избежать конфликтов с разрешениями, особенно при операциях вроде pg_upgrade, а также обеспечивает корректное поведение в случае отключения вторичного тома.
Файловые системы
PostgreSQL поддерживает работу с любой файловой системой, поддерживающей POSIX-семантику. Выбор конкретной файловой системы чаще всего обусловлен опытом пользователей, ожиданиями относительно производительности и уровнем осведомленности о системе. Практика показывает, что изменения в производительности или поведении системы происходят редко исключительно из-за изменения файловой системы или незначительных изменений в ее конфигурации.
NFS
NFS можно использовать для хранения каталога данных PostgreSQL. PostgreSQL не выдвигает специальных требований к NFS, рассчитывая на ее нормальное функционирование аналогичное локальным дискам. PostgreSQL не использует функциональные возможности, которые могли бы повлиять на поведение NFS, например, блокировки файлов.
Единственное важное требование при использовании NFS с PostgreSQL — это монтаж файловой системы с опцией hard. С этой опцией процессы будут ждать бесконечное время в случае сетевых проблем, поэтому необходимо внимательно подходить к мониторингу сети. Опция soft прекращает системные вызовы при проблемах с сетью, но PostgreSQL не восстанавливает прерванные вызовы, что может привести к ошибкам ввода-вывода.
Опция монтирования sync не обязательна. Поведение опции async приемлемо, так как PostgreSQL своевременно вызывает fsync для сброса буферов записи. (Такое поведение характерно и для локальных файловых систем.) Однако настоятельно рекомендуется использовать опцию экспорта sync на стороне сервера NFS в системах, где она доступна (обычно это Linux). Отсутствие этой опции означает, что вызов fsync или аналогичный на стороне клиента NFS не гарантирует фактическое сохранение данных на постоянной памяти сервера, что повышает вероятность повреждений, сходных с ситуацией, когда функция fsync отключена. Значения по умолчанию для параметров монтирования и экспорта различаются в зависимости от поставщика и версии программного обеспечения, поэтому рекомендуется проверять и явно указывать их, чтобы избежать неопределенностей.
Иногда внешнюю память предоставляют через NFS или с использованием низлежащих протоколов, таких как iSCSI. В последнем случае хранилище появляется как блочное устройство, на которое можно наложить любую подходящую файловую систему. Это избавляет от необходимости учитывать особенности NFS, но усложняет управление внешним хранилищем, поднимая его на другой уровень ответственности.