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.3.5. Исправьте команды в этой статье так, как это требуется для вашей определенной версии.

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

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

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

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

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

The split ebuilds, , and/or have been unified into a single package:. Nothing is required for you to move from the split ebuilds to the unified ebuild other than to emerge the unified ebuild.

Эта статья описывает миграцию со старых 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 определяет, что кластер базы данных должен быть установлен в, который является каталогом по умолчанию. Если вы решите отказаться от значений по умолчанию, помните, что очень хорошей идеей будет хранить номер старшей версии в переменной PATH. PG_INITDB_OPTS определяет, что локалью по умолчанию должна быть en_US.UTF-8. То есть, будет использоваться английское упорядочивание и форматирование, и кодировка символов 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.

Метод 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. Это руководство проведет вас через создание ролей, баз данных, схем и все эти интересные и полезные вещи.

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

Миграция после версии 9.0
When upgrading from a previous version of the recent ebuilds, which is any version after 8.4, follow the beginning of this guide before proceeding with this migration.

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

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

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

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

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

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

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

И вот все готово:

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

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

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

Необходимо отредактировать пару файлов перед началом миграции. Установите PGPORT в файле конфигурации на 6543. (Подойдет любой порт отличный от того, который привязан к предыдущей установке.)

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

Следующие инструкции должны быть безопасны. Прочтите документацию, чтобы быть в этом уверенными.

Не забудьте скопировать те файлы конфигурации, которые могут вам понадобиться.

Начинайте переправлять данные со старого кластера на новый кластер.

Установите PGPORT обратно на 5432.

Разрешите пользователям доступ еще один раз.

Надеемся, все прошло по плану и вы успешно обновили сервер, который содержит те же самые данные, точь-в-точь, как и старый сервер.

Миграция перед версией 9.0: со старых ebuild-файлов
Вам потребуется запланировать некоторое время простоя для вашего сервера. Старые ebuild-файлы не могут быть установлены в то же самое время, что и новые. Таким образом, заранее предположите, что сервер будет остановлен в течение нескольких часов. Даже, может быть, на все выходные.

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

Следуйте шагам по установке и конфигурации сервера, описанным в подробностях в этой статье.

Вы можете повредить некоторые пакеты, которые были собраны с этими пакетами, но как только вы установили dev-db/postgresql-base и/или dev-db/postgresql-server, вы можете запустить , чтобы заново установить любые пакеты, которые могут быть повреждены.

pgAdmin III
pgAdmin III — это графическая утилита для управления PostgreSQL.

Сообщение "Server Lacks Instrumentation Functions"
Эту проблему легко решить, с решением, зависящим от версии, которую вы используете. Что сложно, так это найти ответ. То, что потребуется — это импорт из файла, который уже существует на запоминающем устройстве:. Чтобы решить эту проблему, запустите одну из следующих команд, соответствующую имеющейся версии:

Для PostgreSQL 9.0 и более ранних версий:

Для PostgreSQL 9.1 и более поздних версий:

Отсутствующие файлы настроек в и
Вы можете попытаться переместить файлы настроек в каталог следующим образом (x - это ваша версия postgresql):

Если данные файлы отсутствуют, вам нужно их инициализировать.

Сначала зайдите как пользователь postgres:

Затем, как пользователь postgres, запустите  и укажите каталог с данными:

После этого будут созданы файлы настроек, и вы сможете скопировать их в каталог, как было показано в первом примере данного раздела.

Ошибки "ERROR: timezone directory stack overflow" или "FATAL: too many private dirs demanded"
Это вызвано ссылающимися друг на друга символическими ссылками. Чтобы исправить данную проблему, введите следующее:

Помните, что любое обновление zoneinfo снова создаст данную символическую ссылку, и вам понадобится удалить ее снова.

Systemd
Заставьте сервис запускаться при загрузке:

Чтобы запустить сервис немедленно:

Если вы получите ошибку, проверьте, что существует каталог. Если он не существует, создайте его следующим образом:

Проверьте разрешения для файла настроек: