18.2. Создание кластера базы данных#
18.2. Создание кластера базы данных
Перед тем, как что-либо делать, необходимо инициализировать область хранения базы данных на диске. Мы называем это кластером баз данных. (Стандарт SQL использует термин "кластер каталогов"). Кластер баз данных - это набор баз данных, управляемый одним экземпляром работающего сервера баз данных. После инициализации кластер баз данных будет содержать базу данных с именем postgres, которая предназначена в качестве базы данных по умолчанию для использования утилитами, пользователями и сторонними приложениями. Сам сервер баз данных не требует наличия базы данных postgres, но многие внешние утилиты предполагают ее наличие. Во время инициализации в каждом кластере создаются еще две базы данных с именами template1 и template0. Как следует из названий, они будут использоваться в качестве шаблонов для последующего создания баз данных; их не следует использовать для реальной работы. (См. Глава 22 для получения информации о создании новых баз данных внутри кластера).
С точки зрения файловой системы, кластер базы данных - это один каталог, в котором будет храниться вся информация. Мы называем его каталогом данных или областью данных. Полностью зависит от вас, где вы выберете хранить свои данные. Нет значения по умолчанию, хотя популярными местами являются /usr/local/pgsql/data или /var/lib/pgsql/data. Каталог данных должен быть инициализирован перед использованием с помощью программы initdb
который устанавливается вместе с Tantor SE.
Если вы используете предварительно упакованную версию Tantor SE, она, скорее всего, имеет определенное соглашение о том, где размещать каталог данных, и может также предоставлять скрипт для создания каталога данных. В этом случае вы должны использовать этот скрипт вместо прямого запуска initdb. Подробности смотрите в документации пакета.
Для инициализации кластера базы данных вручную запустите команду initdb и укажите желаемое расположение файловой системы кластера базы данных с помощью опции -D, например:
$initdb -D /usr/local/pgsql/data
Обратите внимание, что вы должны выполнить эту команду, находясь в учетной записи пользователя Tantor SE, которая описана в предыдущем разделе.
В качестве альтернативы, вы можете запустить команду initdb через программу pg_ctl
как вот так:
$pg_ctl -D /usr/local/pgsql/data initdb
Это может быть более интуитивным, если вы используете pg_ctl для запуска и остановки сервера (см. Раздел 18.3), таким образом, pg_ctl будет единственной командой, которую вы используете для управления экземпляром сервера базы данных.
initdb попытается создать указанный каталог, если она еще не существует. Конечно, это не удастся, если у initdb нет разрешений на запись в родительский каталог. Обычно рекомендуется, чтобы пользователь Tantor SE был владельцем не только каталога данных, но и его родительским каталогом, чтобы это не стало проблемой. Если нужный родительский каталог также не существует, вам нужно будет сначала создать его, используя привилегии root, если каталог-предок не доступен для записи. Таким образом, процесс может выглядеть так:
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsqlroot#su postgrespostgres$initdb -D /usr/local/pgsql/data
initdb откажется запускаться, если каталог данных уже существует и содержит файлы; это сделано для предотвращения случайного перезаписывания существующей установки.
Поскольку каталог данных содержит все данные, хранящиеся в базе данных, важно обеспечить его защиту от несанкционированного доступа. Команда initdb отзывает разрешения на доступ у всех, кроме пользователя Tantor SE и, при необходимости, группы. Доступ группы, при включении, является только для чтения. Это позволяет непривилегированному пользователю в той же группе, что и владелец кластера, создать резервную копию данных кластера или выполнить другие операции, которые требуют только чтения.
Обратите внимание, что включение или отключение группового доступа в существующем кластере требует его остановки и установки соответствующего режима для всех каталогов и файлов перед перезапуском Tantor SE. В противном случае, в каталоге данных могут существовать файлы с разными режимами доступа. Для кластеров, которые разрешают доступ только владельцу, соответствующие режимы доступа для каталогов - 0700, а для файлов - 0600. Для кластеров, которые также разрешают чтение группой, соответствующие режимы доступа для каталогов - 0750, а для файлов - 0640.
Однако, хотя содержимое каталога защищено, настройка аутентификации клиента по умолчанию позволяет любому локальному пользователю подключаться к базе данных и даже становиться суперпользователем базы данных. Если вы не доверяете другим локальным пользователям, рекомендуется использовать одну из опций initdb - -W, --pwprompt или --pwfile для назначения пароля суперпользователю базы данных.
Также, укажите -A scram-sha-256, чтобы не использовать режим аутентификации по умолчанию trust; или измените сгенерированный файл pg_hba.conf после запуска initdb, но перед первым запуском сервера. (Другие разумные подходы включают использование аутентификации peer или ограничение соединений с помощью прав доступа к файловой системе. См. Глава 20 для получения дополнительной информации).
initdb также инициализирует локаль по умолчанию
для кластера базы данных.
Обычно он просто берет настройки локали из окружения
и применяет их к инициализированной базе данных. Возможно
указать другую локаль для базы данных; более подробную информацию об этом
можно найти в разделе Раздел 23.1. Порядок сортировки по умолчанию,
используемый в конкретном кластере базы данных, устанавливается
initdb, и хотя вы можете создавать новые базы данных с использованием
другого порядка сортировки, порядок, используемый в шаблонных базах данных, созданных initdb,
не может быть изменен без их удаления и повторного создания.
Использование локалей, отличных от C или POSIX, также влияет на производительность.
Поэтому важно сделать правильный выбор с первого раза.
initdb также устанавливает кодировку символов по умолчанию для кластера баз данных. Обычно это должно быть выбрано в соответствии с настройкой локали. Подробности см. в Раздел 23.3.
Все локали, кроме C и POSIX, полагаются на библиотеку правил сортировки операционной системы для упорядочивания набора символов. Это контролирует упорядочивание ключей, хранящихся в индексах. По этой причине кластер не может переключиться на несовместимую версию библиотеки правил сортировки, ни через восстановление снимка, двоичная потоковая репликация, другую операционную систему или обновление операционной системы.
18.2.1. Использование вторичных файловых систем
Многие установки создают свои кластеры баз данных на файловых системах (томах), отличных от “корневого” тома машины. Если вы решите сделать это, не рекомендуется пытаться использовать верхний каталог (точку монтирования) вторичного тома в качестве каталога данных. Лучшей практикой является создание каталога внутри каталога точки монтирования, который принадлежит пользователю Tantor SE, а затем создание каталога данных внутри него. Это избегает проблем с разрешениями, особенно для операций, таких как pg_upgrade, и также гарантирует чистые сбои, если вторичный том выйдет из строя.
18.2.2. Файловые системы
Обычно для PostgreSQL можно использовать любую файловую систему с POSIX-семантикой. Пользователи предпочитают различные файловые системы по разным причинам, включая поддержку поставщика, производительность и знакомство. Опыт показывает, что, при прочих равных условиях, не следует ожидать значительных изменений производительности или поведения просто от переключения файловых систем или внесения незначительных изменений в конфигурацию файловой системы.
18.2.2.1. NFS
Возможно использовать файловую систему NFS для хранения каталога данных Tantor SE. Tantor SE не предпринимает никаких специальных действий для файловых систем NFS, что означает, что он предполагает, что NFS ведет себя точно так же, как локально подключенные диски. Tantor SE не использует никаких функций, которые известно, что имеют нестандартное поведение на NFS, такие как блокировка файлов.
Единственное жесткое требование для использования NFS с Tantor SE заключается в том, что файловая система должна быть смонтирована с использованием опции hard. С опцией hard процессы могут «зависнуть» на неопределенное время в случае проблем с сетью, поэтому для этой конфигурации требуется тщательная настройка мониторинга. Опция soft прерывает системные вызовы в случае проблем с сетью, но Tantor SE не повторяет системные вызовы, прерванные таким образом, поэтому любое такое прерывание приведет к сообщению об ошибке ввода-вывода.
Необходимость использования опции монтирования sync не обязательна. Поведение опции async достаточно, так как Tantor SE выполняет вызовы fsync в нужные моменты для сброса кешей записи. (Это аналогично работе на локальной файловой системе). Однако настоятельно рекомендуется использовать опцию экспорта sync на сервере NFS в системах, где она существует (в основном на Linux). В противном случае, вызов fsync или эквивалентный на клиенте NFS фактически не гарантирует достижение постоянного хранения на сервере, что может привести к повреждению, аналогичному работе с параметром fsync выключенным. Значения по умолчанию для этих опций монтирования и экспорта различаются между поставщиками и версиями, поэтому рекомендуется проверить и, возможно, явно указать их в любом случае, чтобы избежать неоднозначности.
В некоторых случаях внешний накопитель можно получить доступ как через NFS, так и через более низкоуровневый протокол, такой как iSCSI. В последнем случае хранилище появляется в виде блочного устройства, и на нем можно создать любую доступную файловую систему. Такой подход может освободить администратора базы данных от необходимости иметь дело с некоторыми особенностями NFS, но, конечно же, сложность управления удаленным хранилищем возникает на других уровнях.