�� Создание кластера баз данных PostgreSQL
Первое, что надо сделать после установки PostgreSQL на компьютер — это создать новый кластер баз данных. В терминах Postgresql — кластер баз данных это набор баз , которые управляются одним экземпляром сервера. Один экземпляр PostgreSQL может запускать и контролировать набор баз данных, которые изолированы друг от друга, но обслуживаются через один и тот же сокет TCP/IP или UNIX.
Ограничений по количеству запущенных экземпляров PostgreSQL, кроме ограничений накладываемых доступными ресурсами системы и количеством свободных сокетов.
Процесс создания кластера баз данных состоит из создания директории, где будут храниться данные, создания общих таблиц (shared catalog tables) (таблицы, которые относятся ко всему кластеру, а не к какой-либо конкретной базе), создания базы-шаблона template1 (вообще-то создаются две шаблонные базы: template1 и template0. template0 выступает в качестве дублирующей копии для template1, в случае, если последняя будет разрушена) и служебной базы postgres.
Таким образом кластер использует файловую систему для хранения всех баз и их данных: есть главная директория (индивидуальная на кластер), состоящая из нескольких поддиректорий, по одной на каждую базу, которые, в свою очередь, хранят все объекты в базе (таблицы, генераторы последовательностей и т.п.).
initdb — создание нового PostgreSQL кластера баз данных
initdb [ option …] [ —pgdata | -D ] directory
Команда initdb должна выполняться от имени пользователя, под которым будет запускаться сервер, т.к. ему необходим полный доступ к файлам и директориям, создаваемым initdb. Сервер не может запускаться от имени суперпользователя, поэтому выполнение команды initdb от его лица будет отклонено.
initdb инициализирует локали и кодировки баз данных кластера, которые будут использоваться по умолчанию. Кодировка, порядок сортировки (LC_COLLATE), классы наборов символов (LC_CTYPE, например, верхний, нижний, цифра) могут устанавливаться раздельно при создании новой базы данных. initdb определяет настройки для шаблона template1, которые будут применяться по умолчанию для новых баз.
Чтобы изменить порядок сортировки по умолчанию или классы наборов символов, используются опции —lc-collate и —lc-ctype. Порядок сортировки, отличающийся от C или POSIX, оказывает влияние на производительность. Поэтому необходимо тщательно выбирать необходимую и достаточную локаль при выполнении initdb.
Другие категории локали можно изменить и после старта сервера. Также можно использовать опцию —locale, чтобы задать локаль для всех категорий одновременно, включая порядок сортировки и классы наборов символов. Значения локалей сервера (lc_*) можно вывести командой SHOW ALL. Подробнее см. в Раздел 22.1.
Для изменения кодировки по умолчанию используется опция —encoding.
-A authmethod
—auth=authmethod
Опция указывает на метод аутентификации локальных пользователей, используемый в файле pg_hba.conf (строки host и local). trust используется по умолчанию для облегчения процесса установки.
-D directory
—pgdata=directory
Опция указывает директорию хранения кластера. Это единственная опция, обязательная для команды initdb. Но и ее можно не использовать, а указать в переменной окружения PGDATA, что будет удобным при дальнейшем использовании (postgres обращается к этой же переменной).
-E encoding
—encoding=encoding
Устанавливает кодировку шаблона баз данных по умолчанию, если не указать иное при их создании. По умолчанию устанавливается исходя из указанной локали.
Указывает на необходимость проверки системой ввода/вывода контрольных сумм страниц для обнаружения поврежденных данных, т.к. по умолчанию проверка не производится. Включение проверки может в значительной мере оказать влияние на производительность. Устанавливается на этапе развертывания кластера, и далее не может быть изменена. Когда проверка включена, производится вычисление контрольных сумм для всех объектов всех баз данных кластера.
Устанавливает локаль кластера по умолчанию. Если флаг не указан, локаль устанавливается согласно окружению, в котором исполняется команда initdb.
—lc-collate=locale
—lc-ctype=locale
—lc-messages=locale
—lc-monetary=locale
—lc-numeric=locale
—lc-time=locale
Аналогично —locale устанавливает необходимую локаль, но в заданной категории.
Указывает initdb прочитать пароль суперпользователя БД из файла. В качестве пароля используется первая строка файла
-U username
—username=username
Устанавливает имя суперпользователя кластера. По умолчанию используется имя пользователя, от которого был запущен initdb.
Указывает initdb на необходимость запросить пароль для суперпользователя. Если не хотите использовать аутентификацию по паролю — эта опция Вам не нужна. В противном же случае не сможете использовать аутентификацию по паролю до тех пор пока не зададите пароль.
-X directory
—xlogdir=directory
Эта опция определяет каталог где будет храниться лог транзакции
Другие реже используемые опции описаны здесь:
Распечатывает отладочный вывод и некоторую дополнительную информацию при начальной работе загрузчика. Загрузчик это приложение initdb, используемое для создания каталога таблиц.
Указывает initdb, где необходимо искать входные файлы для развертывания кластера. Обычно это не требуется. Приложение само запросит эти данные, если будет необходимо.
По умолчанию, при выявлении ошибки на этапе развертывания кластера, initdb удаляет все файлы, которые к тому моменту были созданы. Опция предотвращает очистку файлов для целей отладки.
Выводит версию initdb и останавливается.
Показывает помощь по аргументам команды initdb и останавливается.
Указывает директорию хранения данных кластера, можно изменить опцией -D.
Указывает временную зону кластера по умолчанию. Значение это полное имя временной зоны.
И в завершении — initdb можно выполнить и командой pg_ctl initdb.
�� Похожие статьи на сайте
- Резервное копирование и восстановление баз данных PostgreSQL
- Создание кластера баз данных PostgreSQL
- Настройка аутентификации клиентов в PostgreSQL — файл pg_hba.conf
- Системные колонки таблиц PostgreSQL
- Оптимизация PostgreSQL. Autovacuum — сборка мусора
- Оптимизация PostgreSQL. Журнал транзакций и контрольные точки
- Оптимизация PostgreSQL. Настройка ресурсов
- Шпаргалка по основным командам PostgreSQL
- Установка 1C 8.3 под PostgreSQL 9.3 на Ubuntu Server 14.04 X64
Как создать новый кластер postgresql
Прежде чем вы сможете работать с базами данных, вы должны проинициализировать область хранения баз данных на диске. Мы называем это хранилище кластером баз данных. (В SQL применяется термин «кластер каталога».) Кластер баз данных представляет собой набор баз, управляемых одним экземпляром работающего сервера. После инициализации кластер будет содержать базу данных с именем postgres , предназначенную для использования по умолчанию утилитами, пользователями и сторонними приложениями. Сам сервер баз данных не требует наличия базы postgres , но многие внешние вспомогательные программы рассчитывают на её существование. При инициализации в каждом кластере создаётся ещё одна база, с именем template1 . Как можно понять из имени, она применяется впоследствии в качестве шаблона создаваемых баз данных; использовать её в качестве рабочей не следует. (За информацией о создании новых баз данных в кластере обратитесь к Главе 22.)
С точки зрения файловой системы кластер баз данных представляет собой один каталог, в котором будут храниться все данные. Мы называем его каталогом данных или областью данных. Где именно хранить данные, вы абсолютно свободно можете выбирать сами. Какого-либо стандартного пути не существует, но часто данные размещаются в /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 для запуска и остановки сервера (см. Раздел 18.3), так как pg_ctl будет единственной командой, с помощью которой вы будете управлять экземпляром сервера баз данных.
Команда initdb попытается создать указанный вами каталог, если он не существует. Конечно, она не сможет это сделать, если initdb не будет разрешено записывать в родительский каталог. Вообще рекомендуется, чтобы пользователь PostgreSQL был владельцем не только каталога данных, но и родительского каталога, так что такой проблемы быть не должно. Если же и нужный родительский каталог не существует, вам нужно будет сначала создать его, используя права root, если вышестоящий каталог защищён от записи. Таким образом, процедура может быть такой:
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsqlroot#su postgrespostgres$initdb -D /usr/local/pgsql/data
Команда initdb не будет работать, если указанный каталог данных уже существует и содержит файлы; это мера предохранения от случайной перезаписи существующей инсталляции.
Так как каталог данных содержит все данные базы, очень важно защитить его от неавторизованного доступа. Для этого initdb лишает прав доступа к нему всех пользователей, кроме пользователя PostgreSQL и, возможно, его группы. Если группе разрешается доступ, то только для чтения. Это позволяет непривилегированному пользователю, входящему в одну группу с владельцем кластера, делать резервные копии данных кластера или выполнять другие операции, для которых достаточно доступа только для чтения.
Заметьте, чтобы корректно разрешить или запретить доступ группы к данным существующего кластера, необходимо выключить кластер и установить соответствующий режим для всех каталогов и файлов до запуска PostgreSQL . В противном случае в каталоге данных возможно смешение режимов. Для кластеров, к которым имеет доступ только владелец, требуется установить режим 0700 для каталогов и 0600 для файлов, а для кластеров, в которых также разрешается чтение группой, режим 0750 для каталогов и 0640 для файлов.
Однако даже когда содержимое каталога защищено, если проверка подлинности клиентов настроена по умолчанию, любой локальный пользователь может подключиться к базе данных и даже стать суперпользователем. Если вы не доверяете другим локальным пользователям, мы рекомендуем использовать один из параметров команды initdb : -W , —pwprompt или —pwfile и назначить пароль суперпользователя баз данных. Кроме того, воспользуйтесь параметром -A md5 или -A password и отключите разрешённый по умолчанию режим аутентификации trust ; либо измените сгенерированный файл pg_hba.conf после выполнения initdb , но перед тем, как запустить сервер в первый раз. (Возможны и другие разумные подходы — применить режим проверки подлинности peer или ограничить подключения на уровне файловой системы. За дополнительными сведениями обратитесь к Главе 20.)
Команда initdb также устанавливает для кластера баз данных локаль по умолчанию. Обычно она просто берёт параметры локали из текущего окружения и применяет их к инициализируемой базе данных. Однако можно выбрать и другую локаль для базы данных; за дополнительной информацией обратитесь к Разделу 23.1. Команда initdb задаёт порядок сортировки по умолчанию для применения в определённом кластере баз данных, и хотя новые базы данных могут создаваться с иным порядком сортировки, порядок в базах-шаблонах, создаваемых initdb, можно изменить, только если удалить и пересоздать их. Также учтите, что при использовании локалей, отличных от C и POSIX , возможно снижение производительности. Поэтому важно правильно выбрать локаль с самого начала.
Команда initdb также задаёт кодировку символов по умолчанию для кластера баз данных. Обычно она должна соответствовать кодировке локали. За подробностями обратитесь к Разделу 23.3.
Для локалей, отличных от C и POSIX , порядок сортировки символов зависит от системной библиотеки локализации, а он, в свою очередь, влияет на порядок ключей в индексах. Поэтому кластер нельзя перевести на несовместимую версию библиотеки ни путём восстановления снимка, ни через двоичную репликацию, ни перейдя на другую операционную систему или обновив её версию.
18.2.1. Использование дополнительных файловых систем
Во многих инсталляциях кластеры баз данных создаются не в « корневом » томе, а в отдельных файловых системах (томах). Если вы решите сделать так же, то не следует выбирать в качестве каталога данных самый верхний каталог дополнительного тома (точку монтирования). Лучше всего создать внутри каталога точки монтирования каталог, принадлежащий пользователю PostgreSQL , а затем создать внутри него каталог данных. Это исключит проблемы с разрешениями, особенно для таких операций, как pg_upgrade , и при этом гарантирует чистое поведение в случае, если дополнительный том окажется отключён.
18.2.2. Файловые системы
Вообще говоря, для PostgreSQL может использоваться любая файловая система с семантикой POSIX. Пользователи предпочитают различные файловые системы по самым разным причинам, в частности, по соображениям производительности, изученности или поддержки поставщиком. Как показывает практика, в результате лишь смены файловой системы или корректировки её параметров при прочих равных не следует ожидать значительного изменения производительности или поведения.
18.2.2.1. NFS
Каталог данных PostgreSQL может размещаться и в файловой системе NFS . PostgreSQL не подстраивается специально под NFS , что означает, что с NFS он работает точно так же, как и с локально подключёнными устройствами. PostgreSQL не использует такую функциональность файловых систем, которая имеет свои особенности в NFS , например блокировки файлов.
Единственное убедительное требование — используя NFS c PostgreSQL , монтируйте эту файловую систему в режиме hard . При использовании режима hard процессы могут « зависать » на неопределённое время в случае сетевых проблем, поэтому могут потребоваться особые меры контроля. В режиме soft системные вызовы будут прерываться в случаях перебоев в сети, но PostgreSQL не повторяет вызовы, прерванные таким образом, и это будет проявляться в ошибках ввода/вывода.
Использовать параметр монтирования sync не обязательно. Поведения режима async достаточно, так как PostgreSQL вызывает fsync в нужные моменты для сброса кеша записи (так же, как и с локальной файловой системой). Однако параметр sync настоятельно рекомендуется использовать при экспортировании файловой системы на сервере NFS в тех ОС, где он поддерживается (в основном это касается Linux). В противном случае не гарантируется, что в результате выполнения fsync или аналогичного вызова NFS-клиентом данные действительно окажутся в надёжном хранилище на сервере, вследствие чего возможно повреждение данных, как и при выключенном параметре fsync. Значения по умолчанию параметров монтирования и экспортирования меняются от производителя к производителю и от версии к версии, поэтому рекомендуется перепроверить их или, возможно, явно задать нужные значения во избежание неоднозначности.
В некоторых случаях внешнее устройство хранение может быть подключено по NFS или посредством низкоуровневого протокола, например iSCSI. В последнем случае такое хранилище представляется в виде блочного устройства, и на нём можно создать любую файловую систему. При этом администратору не придётся иметь дело со странностями NFS, но надо понимать, что сложности управления удалённым хранилищем в таком случае просто перемещаются на другие уровни.
| Пред. | Наверх | След. |
| 18.1. Учётная запись пользователя PostgreSQL | Начало | 18.3. Запуск сервера баз данных |
Как создать новый кластер postgresql
Инициализация кластера PostgreSQL представляет собой создание базовой структуры файлов для хранения БД. Unix-версии, как правило, размещают БД в каталоге /var/lib/postgres. Windows-инсталлятор запрашивает расположение при установке.
В качестве кодировки сервера мы рекомендуем выбирать вариант с поддержкой UTF8.
Ручная инициализация БД производится с помощью запуска утилиты initdb из пакета postgresql, например, со следующими параметрами:
initdb --username=postgres --pwprompt -E UTF8 /mnt/raid/db
Данная команда создает в каталоге /mnt/raid/db первичную базу данных с администратором postgres. В момент создания у вас запросят пароль нового администратора БД.
Предупреждение
После создания директории с файлами убедитесь, что пользователь, из-под которого будет работать сервер PostgreSQL (как правило, postgres), имеет права на чтение/запись в эту папку. В среде Unix лучше назначить этого пользователя владельцем данной директории.
Как создать новый кластер postgresql
Прежде чем вы сможете работать с базами данных, вы должны проинициализировать область хранения баз данных на диске. Мы называем это хранилище кластером баз данных. (В SQL применяется термин «кластер каталога».) Кластер баз данных представляет собой набор баз, управляемых одним экземпляром работающего сервера. После инициализации кластер будет содержать базу данных с именем postgres , предназначенную для использования по умолчанию утилитами, пользователями и сторонними приложениями. Сам сервер баз данных не требует наличия базы postgres , но многие внешние вспомогательные программы рассчитывают на её существование. При инициализации в каждом кластере создаётся ещё одна база, с именем template1 . Как можно понять из имени, она применяется впоследствии в качестве шаблона создаваемых баз данных; использовать её в качестве рабочей не следует. (За информацией о создании новых баз данных в кластере обратитесь к Главе 21.)
С точки зрения файловой системы, кластер баз данных представляет собой один каталог, в котором будут храниться все данные. Мы называем его каталогом данных или областью данных. Где именно хранить данные, вы абсолютно свободно можете выбирать сами. Какого-либо стандартного пути не существует, но часто данные размещаются в /usr/local/pgsql/data или в /var/lib/pgsql/data . Для инициализации кластера баз данных применяется команда initdb , которая устанавливается в составе Postgres Pro . Расположение кластера базы данных в файловой системе задаётся параметром -D , например:
$initdb -D /usr/local/pgsql/data
Заметьте, что эту команду нужно выполнять от имени учётной записи Postgres Pro , о которой говорится в предыдущем разделе.
Подсказка
В качестве альтернативы параметра -D можно установить переменную окружения PGDATA .
Также можно запустить команду initdb , воспользовавшись программой pg_ctl , примерно так:
$pg_ctl -D /usr/local/pgsql/data initdb
Этот вариант может быть удобнее, если вы используете pg_ctl для запуска и остановки сервера (см. Раздел 17.3), так как pg_ctl будет единственной командой, с помощью которой вы будете управлять экземпляром сервера баз данных.
Команда initdb попытается создать указанный вами каталог, если он не существует. Конечно, она не сможет это сделать, если initdb не будет разрешено записывать в родительский каталог. Вообще рекомендуется, чтобы пользователь Postgres Pro был владельцем не только каталога данных, но и родительского каталога, так что такой проблемы быть не должно. Если же и нужный родительский каталог не существует, вам нужно будет сначала создать его, используя права root, если вышестоящий каталог защищён от записи. Таким образом, процедура может быть такой:
root#mkdir /usr/local/pgsqlroot#chown postgres /usr/local/pgsqlroot#su postgrespostgres$initdb -D /usr/local/pgsql/data
Команда initdb не будет работать, если указанный каталог данных уже существует и содержит файлы; это мера предохранения от случайной перезаписи существующей инсталляции.
Так как каталог данных содержит все данные базы, очень важно защитить его от неавторизованного доступа. Для этого initdb лишает прав доступа к нему всех пользователей, кроме пользователя Postgres Pro .
Однако, даже когда содержимое каталога защищено, если проверка подлинности клиентов настроена по умолчанию, любой локальный пользователь может подключиться к базе данных и даже стать суперпользователем. Если вы не доверяете другим локальным пользователям, мы рекомендуем использовать один из параметров команды initdb : -W , —pwprompt или —pwfile и назначить пароль суперпользователя баз данных. Кроме того, воспользуйтесь параметром -A md5 или -A password и отключите разрешённый по умолчанию режим аутентификации trust ; либо измените сгенерированный файл pg_hba.conf после выполнения initdb , но перед тем, как запустить сервер в первый раз. (Возможны и другие разумные подходы — применить режим проверки подлинности peer или ограничить подключения на уровне файловой системы. За дополнительными сведениями обратитесь к Главе 19.)
Команда initdb также устанавливает для кластера баз данных локаль по умолчанию. Обычно она просто берёт параметры локали из текущего окружения и применяет их к инициализируемой базе данных. Однако можно выбрать и другую локаль для базы данных; за дополнительной информацией обратитесь к Разделу 22.1. Команда initdb задаёт порядок сортировки по умолчанию для применения в определённом кластере баз данных, и хотя новые базы данных могут создаваться с иным порядком сортировки, порядок в базах-шаблонах, создаваемых initdb, можно изменить, только если удалить и пересоздать их. Также учтите, что при использовании локалей, отличных от C и POSIX , возможно снижение производительности. Поэтому важно правильно выбрать локаль с самого начала.
Команда initdb также задаёт кодировку символов по умолчанию для кластера баз данных. Обычно она должна соответствовать кодировке локали. За подробностями обратитесь к Разделу 22.3.
Для локалей, отличных от C и POSIX , порядок сортировки символов зависит от системной библиотеки локализации, а он, в свою очередь, влияет на порядок ключей в индексах. Поэтому кластер нельзя перевести на несовместимую версию библиотеки ни путём восстановления снимка, ни через двоичную репликацию, ни перейдя на другую операционную систему или обновив её версию.
17.2.1. Использование дополнительных файловых систем
Во многих инсталляциях кластеры баз данных создаются не в « корневом » томе, а в отдельных файловых системах (томах). Если вы решите сделать так же, то не следует выбирать в качестве каталога данных самый верхний каталог дополнительного тома (точку монтирования). Лучше всего создать внутри каталога точки монтирования каталог, принадлежащий пользователю Postgres Pro , а затем создать внутри него каталог данных. Это исключит проблемы с разрешениями, особенно для таких операций, как pg_upgrade , и при этом гарантирует чистое поведение в случае, если дополнительный том окажется отключён.
17.2.2. Использование сетевых файловых систем
Во многих инсталляциях кластеры баз данных создаются в сетевых файловых ресурсах. Иногда это реализуется с применением сетевой файловой системы ( NFS , Network File System) или сетевых хранилищ ( NAS , Network Attached Storage), использующих NFS внутри. Postgres Pro не делает ничего специфического с файловыми системами NFS , то есть он предполагает, что NFS работает точно так же, как и локально подключённые диски. Но если реализация клиента или сервера NFS не обеспечивает стандартное поведение файловой системы, это чревато нестабильной работой (см. http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html). В частности, возможно разрушение данных при отложенной (асинхронной) записи на сервер NFS . Поэтому, по возможности, во избежание таких проблем монтируйте файловые системы NFS в синхронном режиме (без кеширования). Кроме того, не рекомендуется применять мягкое монтирование файловой системы NFS .
В сетях хранения данных ( SAN , Storage Area Networks) обычно используются собственные протоколы, не NFS , и они могут быть не подвержены (а могут быть и подвержены) этим рискам. По вопросам гарантии согласованности данных обратитесь к документации производителя. Postgres Pro не может быть надёжнее файловой системы, которую он использует.
| Пред. | Наверх | След. |
| 17.1. Учётная запись пользователя Postgres Pro | Начало | 17.3. Запуск сервера баз данных |