postgres:osnovy:klaster_baz_dannyx []

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



Прежде чем вы сможете работать с базами данных, вы должны проинициализировать область хранения баз данных на диске. Мы называем это хранилище кластером баз данных. (В SQL применяется термин «кластер каталога».) Кластер баз данных представляет собой набор баз, управляемых одним экземпляром работающего сервера. После инициализации кластер будет содержать базу данных с именем ''postgres'', предназначенную для использования по умолчанию утилитами, пользователями и сторонними приложениями. Сам сервер баз данных не требует наличия базы ''postgres'', но многие внешние вспомогательные программы рассчитывают на её существование. При инициализации в каждом кластере создаётся ещё одна база, с именем ''template1''. Как можно понять из имени, она применяется впоследствии в качестве шаблона создаваемых баз данных; использовать её в качестве рабочей не следует. (За информацией о создании новых баз данных в кластере обратитесь к [[managing-databases|Главе 21]].)

С точки зрения файловой системы, кластер баз данных представляет собой один каталог, в котором будут храниться все данные. Мы называем его каталогом данных или областью данных. Где именно хранить данные, вы абсолютно свободно можете выбирать сами. Какого-либо стандартного пути не существует, но часто данные размещаются в ''/usr/local/pgsql/data'' или в ''/var/lib/pgsql/data''. Для инициализации кластера баз данных применяется команда [[app-initdb|initdb]], которая устанавливается в составе Postgres Pro. Расположение кластера базы данных в файловой системе задаётся параметром ''-D'', например:

<code>
$ initdb -D /usr/local/pgsql/data
</code>

Заметьте, что эту команду нужно выполнять от имени учётной записи Postgres Pro, о которой говорится в предыдущем разделе.

==== Подсказка ====

В качестве альтернативы параметра ''-D'' можно установить переменную окружения ''PGDATA''. 

Также можно запустить команду ''initdb'', воспользовавшись программой [[app-pg-ctl|pg_ctl]] , примерно так:

<code>
$ pg_ctl -D /usr/local/pgsql/data initdb
</code>

Этот вариант может быть удобнее, если вы используете ''pg_ctl'' для запуска и остановки сервера (см. [[server-start|Раздел 17.3]]), так как ''pg_ctl'' будет единственной командой, с помощью которой вы будете управлять экземпляром сервера баз данных.

Команда ''initdb'' попытается создать указанный вами каталог, если он не существует. Конечно, она не сможет это сделать, если ''initdb'' не будет разрешено записывать в родительский каталог. Вообще рекомендуется, чтобы пользователь Postgres Pro был владельцем не только каталога данных, но и родительского каталога, так что такой проблемы быть не должно. Если же и нужный родительский каталог не существует, вам нужно будет сначала создать его, используя права root, если вышестоящий каталог защищён от записи. Таким образом, процедура может быть такой:

<code>
root# mkdir /usr/local/pgsql
root# chown postgres /usr/local/pgsql
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data
</code>

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

Так как каталог данных содержит все данные базы, очень важно защитить его от неавторизованного доступа. Для этого ''initdb'' лишает прав доступа к нему всех пользователей, кроме пользователя Postgres Pro.

Однако, даже когда содержимое каталога защищено, если проверка подлинности клиентов настроена по умолчанию, любой локальный пользователь может подключиться к базе данных и даже стать суперпользователем. Если вы не доверяете другим локальным пользователям, мы рекомендуем использовать один из параметров команды ''initdb'': ''-W'', ''--pwprompt'' или ''--pwfile'' и назначить пароль суперпользователя баз данных.  Кроме того, воспользуйтесь параметром ''-A md5'' или ''-A password'' и отключите разрешённый по умолчанию режим аутентификации ''trust''; либо измените сгенерированный файл ''pg_hba.conf'' после выполнения ''initdb'', но перед тем, как запустить сервер в первый раз. (Возможны и другие разумные подходы — применить режим проверки подлинности ''peer'' или ограничить подключения на уровне файловой системы. За дополнительными сведениями обратитесь к [[client-authentication|Главе 19]].)

Команда ''initdb'' также устанавливает для кластера баз данных локаль  по умолчанию. Обычно она просто берёт параметры локали из текущего окружения и применяет их к инициализируемой базе данных. Однако можно выбрать и другую локаль для базы данных; за дополнительной информацией обратитесь к [[locale|Разделу 22.1]]. Команда ''initdb'' задаёт порядок сортировки по умолчанию для применения в определённом кластере баз данных, и хотя новые базы данных могут создаваться с иным порядком сортировки, порядок в базах-шаблонах, создаваемых initdb, можно изменить, только если удалить и пересоздать их. Также учтите, что при использовании локалей, отличных от ''C'' и ''POSIX'', возможно снижение производительности. Поэтому важно правильно выбрать локаль с самого начала.

Команда ''initdb'' также задаёт кодировку символов по умолчанию для кластера баз данных. Обычно она должна соответствовать кодировке локали. За подробностями обратитесь к [[multibyte|Разделу 22.3]].

Для локалей, отличных от ''C'' и ''POSIX'', порядок сортировки символов зависит от системной библиотеки локализации, а он, в свою очередь, влияет на порядок ключей в индексах. Поэтому кластер нельзя перевести на несовместимую версию библиотеки ни путём восстановления снимка, ни через двоичную репликацию, ни перейдя на другую операционную систему или обновив её версию.

==== Использование дополнительных файловых систем ====

Во многих инсталляциях кластеры баз данных создаются не в «корневом» томе, а в отдельных файловых системах (томах). Если вы решите сделать так же, то не следует выбирать в качестве каталога данных самый верхний каталог дополнительного тома (точку монтирования). Лучше всего создать внутри каталога точки монтирования каталог, принадлежащий пользователю Postgres Pro, а затем создать внутри него каталог данных. Это исключит проблемы с разрешениями, особенно для таких операций, как pg_upgrade, и при этом гарантирует чистое поведение в случае, если дополнительный том окажется отключён.

==== Использование сетевых файловых систем ====

Во многих инсталляциях кластеры баз данных создаются в сетевых файловых ресурсах. Иногда это реализуется с применением сетевой файловой системы (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|http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html]]). В частности, возможно разрушение данных при отложенной (асинхронной) записи на сервер NFS. Поэтому, по возможности, во избежание таких проблем монтируйте файловые системы NFS в синхронном режиме (без кеширования). Кроме того, не рекомендуется применять мягкое монтирование файловой системы NFS.

В сетях хранения данных (SAN, Storage Area Networks) обычно используются собственные протоколы, не NFS, и они могут быть не подвержены (а могут быть и подвержены) этим рискам. По вопросам гарантии согласованности данных обратитесь к документации производителя. Postgres Pro не может быть надёжнее файловой системы, которую он использует.
Инструменты пользователя

Инструменты сайта

Инструменты страницы
