PostgreSQL/QuickStart/ru

Это краткая инструкция к PostgreSQL. Она охватывает установку PostgreSQL и ее конфигурацию. Она является дополнением к официальной документации, но не заменяет ее.

Краткое описание PostgreSQL
PostgreSQL - это свободная система управления реляционными базами данных (RDBMS, или СУРБД) с открытым исходным кодом. Она поддерживает такие вещи как транзакции, схемы и внешние ключи, и часто позиционируется как более строго соответствующая стандартам SQL и более безопасная, по умолчанию, чем любая другая база данных, коммерческая или иная.

Посетите страницу About на postgresql.org для более подробной информации.

Что охватывает эта статья?
Эта статья проведет Вас через характерные для Gentoo шаги для установки СУРБД PostgreSQL.

Ebuild-файлы, охватываемые этой статьей: dev-db/postgresql-docs, dev-db/postgresql-base и dev-db/postgresql-server.

В этой статье предполагается, что Вы будете устанавливать последнюю, стабильную версию PostgreSQL; на время написания, этой версией является 9.0.3. Исправьте команды в этой статье так, как это требуется для Вашей определенной версии.

О ebuild-файлах
Ebuild-файлы PostgreSQL в портеже отличаются номерами слотов, основанными на главной версии. Это позволяет Вам иметь две главных версии PostgreSQL действующих одновременно; библиотеки и сервера версий 8.4 и 9.0 могут устанавливаться и обслуживаться в одно и то же время. Это полезно в тех обстоятельствах, когда Вам нужно перенести данные из старой базы данных в новую, или требуется иметь рабочую и тестовую базу данных на одной и той же машине. Также, это предотвращает перезаписывание базы данных, соответствующих библиотек или исполняемых файлов несовместимым обновлением. Это требует миграции, которая описана в данном руководстве.

Вдобавок, исправления багов и уязвимостей безопасности, которые поставляются через обновления младших версий, могут применяться без страха повреждения базы данных или самой сборки PostgreSQL; 9.0.2 может обновляться до 9.0.3, так как гарантируется их совместимость и они не требуют от Вас большего, чем установка и перезапуск серверного процесса. Ни миграция, ни повторная конфигурация, ни инициализация не являются необходимыми.

За подробностями обратитесь к PostgreSQL Versioning Policy.

Что эта статья не охватывает
Большая часть информации не будет описана. Официальная документация находится где-то во окрестностях 2000 страниц. Поэтому, в этом кратком руководстве большинство подробностей будет пропущено. Будут описаны только проблемы, характерные для Gentoo, и некоторые основные рекомендации по конфигурации.

Устаревшие ebuild-файлы
Если у Вас установлены какие-либо из следующих ebuild-файлов, то у Вас устаревшая Gentoo-сборка PostgreSQL, и вы должны мигрировать сейчас: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq и/или dev-db/postgresql.

Эта статья описывает миграцию со старых ebuild-файлов к новым.

Начало Установки
Вы можете получить уведомление по поводу того, что какие-либо их вышеперечисленных пакетов заблокированы одним или всеми из следующих пакетов: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq или dev-db/postgresql. Эти пакеты не поддерживаются и являются устаревшими. Обратитесь к разделу по миграции с предыдущих ebuild-файлов к новым чтобы узнать как справиться с этой ситуацией.

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

PGDATA определяет где размещать файлы настроек. DATA_DIR определяет где создавать кластер базы данных и сопутствующие файлы. PG_INITDB_OPTS может хранить любые дополнительные параметры, которые Вы можете пожелать установить. Установка дополнительных параметров не требуется, так как разумные значения по умолчанию, кхм, разумны.

В следующем примере, PGDATA определяет, что файлы настроек должны быть расположены в. DATA_DIR определяет, что кластер базы данных должен быть установлен в, который является каталогом по умолчанию. Если Вы решите отклониться от значений по умолчанию, держите в уме, что очень хорошей идеей будет хранить номер старшей версии в пути. PG_INITDB_OPTS определяет, что локалью по умолчанию должна быть en_US.UTF-8. То есть, U.S. English упорядочивание и форматирование, и кодировка символов UTF-8.

Существуют шесть параметров локали, которые могут быть установлены для переопределения --locale=. Следующая таблица перечисляет шесть этих параметров, которые, если используются, должны быть отформатированы как:.

Таким образом, если Вы хотите в качестве языка по умолчанию взять Английский, но сообщения должны быть, скажем, на Шведском, то Ваши PG_INITDB_OPTS будут выглядеть так:

Установка PG_INITDB_OPTS

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

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

Это создаст кластер базы данных и сохранит все принадлежащие серверу файлы в PGDATA и DATA_DIR.

Где размещаются файлы конфигурации
На этот раз мы сосредоточимся на файлах в каталоге PGDATA,, с основным фокусом на файлах и.

postgresql.conf
Это основной файл конфигурации. Строкой, которая может немедленно показаться Вам интересной, является listen-addresses. Эта переменная определяет к каким адресам PostgreSQL будет осуществлять привязку. По умолчанию, привязаны только localhost и доменный сокет Unix. Изменения listen_addresses недостаточно для разрешения удаленных соединений. Это будет описано в следующем разделе. Официальная документация довольно легка для понимания и всесторонне охватывает все доступные настройки. Вам следует прочесть ее в дополнение к тому что описано здесь, так как некоторые вещи могут измениться.

Второстепенным вопросом является место назначения логирования. По умолчанию, все пишется в в каталоге DATA_DIR. Имеется целый подраздел, который охватывает большое количество вариантов того как, что и куда нужно логировать. Подраздел обозначен как: ERROR REPORTING AND LOGGING.

Кроме listen_addresses и параметров логирования, остальная часть значений по умолчанию в довольно приемлема для начала.

pg_hba.conf
Файл определяет кому разрешается подключаться к серверу баз данных и какой метод аутентификации должен быть использован для установки соединения. Опять же, документация по настройкам и тому что они означают является довольно исчерпывающей, но несколько вещей здесь описаны для разъяснения.

Как было упомянуто ранее, сервер по умолчанию сконфигурирован безопасно. В своем роде. Существует только одна роль базы данных, которая доступна для входа по умолчанию: postgres. И только одним способом инициировать соединение к базе данных является соединение через сокет Unix, который принадлежит системному пользователю и группе postgres, или установка соединения через localhost. Теперь вернемся к в своем роде. Любой пользователь системы может сделать соединение к базе данных через localhost. Даже в качестве суперпользователя базы данных postgres.

Однако же, чтобы сделать соединение через доменный сокет Unix, пользователи, включая пользователей других служб, таких как apache, должны принадлежать системной группе postgres. Используйте, чтобы добавить user в группу postgres. Пользователи, которые не входят в группу postgres будут отклонены сообщением Permission denied.

Метод trust - это то, что позволяет каждому пользователю входить от имени любого пользователя без пароля. Оно указывает только то, что оно подразумевает: доверять всем соединениям для определенного типа к определенной базе данных от определенного пользователя базы данных (но не системного пользователя) из определенного местонахождения без пароля. Это то что изначально позволяет каждому пользователю системы входить от имени любого пользователя через соединение localhost. Это не настолько опасно, как кажется, но представляет серьезный риск для безопасности в большинстве обстоятельств.

Два метода, которые Вы наиболее вероятно будете использовать, это password и md5. Метод password только указывает, что для начала соединения требуется пароль и пароль отправляется в виде простого текста. Этот метод хорош когда такого рода информация никогда не покинет машину, как, например, соединение через доменный сокет Unix или localhost. Метод md5 схож с password, но защищает пароль использованием хэша md5. Это то, что Вам потребуется использовать, когда бы пароль ни был отправлен через сеть.

В данный момент, автор хотел бы обратить Ваше внимание на последние две строчки, четыре строчки включающие комментарии, в файле. PostgreSQL имеет нативную поддержку IPv6 независимо от того, желаете ли Вы такую поддержку или нет. Вдобавок, адреса IPv4 автоматически отображаются в адреса IPv6, т.е., 127.0.0.1 будет отображен в ::FFFF:127.0.0.1 и как чистый IPv6 ::FFFF:7F00:0001.

Хотя, кажется, есть некоторое непонимание того как имена хостов отображаются в IP-адреса. Давайте рассмотрим файл.

Из примера выше Вы можете видеть, что оба адреса IPv4 и IPv6 отображаются на localhost. Когда  обращается к этому файлу, она захватит первое совпадение и использует его в качестве адреса; в этом случае 127.0.0.1. Когда Postgresql его проанализирует, он также будет соответствовать адресу в формате IPv6, например, ::ffff:127.0.0.1. Если, однако же, адрес IPv6 появится первым, тогда  отобразит его только в один ::1; ::1 - это не то же самое, что ::ffff:127.0.0.1. Таким образом, если Вы не имеете ::1 в виде разрешенных средств доступа,  не будет способна установить соединение. Кроме того, Ваше ядро должно поддерживать протокол IPv6.

Поэтому, лучше будет указать только одни IP адреса для  и в файле, вместо того, чтобы полагаться на то, что  упорядочен должным образом. Это устраняет любые сомнения по поводу того какие IP-адреса разрешены или к какому серверу Вы будете подключаться.

Поехали!
Теперь, запустите PostgreSQL и установите пароль для суперпользователя базы данных postgres. Эти команды должны быть запущены под 'root' в следующем листинге кода.

Измените 'trust' на 'password' для соединений с localhost.

Теперь запустите базу данных:

Откройте соединение к серверу и установите пароль:

Измените 'trust' на 'password' для локальных соединений:

Теперь перезапустите базу данных:

На данный момент Вы готовы продолжать с официальным Руководством PostgreSQL. Это руководство проведет Вас через создание ролей, баз данных, схем и все эти интересные и полезные вещи.

Когда Вам Требуется Миграция
Существуют только две причины по которым Вам необходимо выполнить миграцию: при переходе от одной главной версии к другой, например, от PostgreSQL 8.4.7 к 9.0.3, но не от 9.0.2 к 9.0.3; или при переключении с устаревшего формата временных меток с плавающей точкой к новому 64-битному целочисленному формату временных меток.

Миграция после версии 9.0
pg_upgrade, новая утилита, которая поставляется с версиями 9.0 и позже, радикально упрощает процесс миграции.

Однако, имеются два предостережения при использовании утилиты pg_upgrade. Во-первых, она не поддерживает файлы конфигурации, находящиеся в каталоге, отличном от того, где хранятся данные. Это может быть разрешено использованием символьных ссылок. Во-вторых, Вы можете использовать ее только для миграции с базы данных начинающейся с версии 8.3 или более новой. Если Вы имеете более старую базу данных, Вам нужно следовать инструкциям по миграции с установок, предшествующих версии 9.0.

Не забудьте инициализировать новую базу данных:

Остановите серверы с которых и на которые Вы собираетесь мигрировать:

Проверьте доступные версии и затем выберите Вашу:

Измените метод аутентификации пользователя базы данных 'postgres' так чтобы доверять локальным соединениям на всех базах данных:

Вам может потребоваться изменить разрешения на '/var/lib/postgresql/' перед выполнением следующего шага.

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

Удалите символьные ссылки, которые мы создали ранее:

Миграция до версии 9.0: С Помощью Новых ebuild-файлов
По той причине, что новые ebuild-файлы предлагают более совершенный метод слоттинга, чем предыдущие, время простоя довольно мало, скорее всего это будут минуты, нежели часы.

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

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

A couple of files need to be tweaked before beginning the migration. Edit PGPORT in the configuration file to 6543. (Any port number other than what your old installation is bound to will do.)

Затем, отредактируйте так чтобы только суперпользователь базы данных postgres мог получить доступ к кластеру базы данных через доменный сокет Unix.

The following should be safe. Read the documentation to be sure.

Don't forget to copy over any other configuration files that you may need.

Begin piping the data from the old cluster to the new cluster.

Edit PGPORT back to 5432.

Allow users access once more.

Hopefully everything went according to plan and you have a successfully updated server that contains precisely the same data, bit for bit, as the old server.

Pre-9.0 Migration: From the Obsolete Ebuilds
You will need to schedule some downtime for your server. The old ebuilds cannot be installed at the same time as the new ebuilds. As such, assume that the server will have to be down for a few hours. Maybe for the weekend, even.

Before starting, you will need to deny access to the server, so that no changes are made. You may also want to backup your and  and any other configuration file that you deem important.

Follow the steps detailed in this article for installing and configuring the server.

You may break some packages that were built against those packages, but once you have installed dev-db/postgresql-base and/or dev-db/postgresql-server you can run  to reemerge any packages that may have been broken.

pgAdmin III
pgAdmin III is a graphical utility for managing PostgreSQL.

Server Lacks Instrumentation Functions
This problem is easy to solve, with the solution depending on the version you are using. What is difficult about it is finding the answer. What is required is an import from a file that already exists on the storage drive:. To resolve this issue, run the command appropriate to the version you have:

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Aaron W. Swenson
 * Mikkel A. Clausen