Postgresql windows server 2012 r2 настройка

Обновлено: 04.07.2024

Postgres Pro предоставляет инсталлятор с интерактивным мастером, который устанавливает и конфигурирует ключевые компоненты Postgres Pro , создаёт начальную базу данных и настраивает автозапуск сервера. Для следующих компонентов предоставляются индивидуальные инсталляторы, которые должны запускаться отдельно после основного инсталлятора:

Для установки ключевых компонентов Postgres Pro запустите основной инсталлятор от имени администратора и следуйте инструкциям на экране. Учтите следующую специфику установки:

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

Выбранный каталог данных должен быть пустым. В противном случае Postgres Pro не сможет создать начальную базу данных. По умолчанию каталогом данных будет C:\Program Files\PostgresPro\12\data .

Если установлен флажок Allow external connections (Разрешить внешние подключения) (отмеченный по умолчанию), инсталлятор вносит изменения в postgresql.conf и pg_hba.conf для разрешения подключений извне. В противном случае сервер Postgres Pro будет принимать подключения только с локального узла. Если вы решите разрешить внешние подключения после завершения установки, вы должны будете изменить конфигурацию Брандмауэра Windows, чтобы сервер Postgres Pro мог принимать подключения.

Запомните имя и пароль пользователя, заданные вами при установке Postgres Pro , так как они потребуются для подключения к серверу Postgres Pro при использовании аутентификации с проверкой пароля.

По умолчанию в Postgres Pro используются правила сортировки icu . Если вы обновляете инсталляцию, в которой использовались правила сортировки libc , например, инсталляцию PostgreSQL , выберите libc в качестве провайдера правил сортировки, воспользовавшись соответствующим выпадающим списком в инсталляторе.

По завершении инсталляции экземпляр Postgres Pro готов к использованию, а для службы сервера включён автозапуск. Если вам понадобится больше одного экземпляра Postgres Pro в одной системе, вам нужно будет настроить дополнительные экземпляры вручную. За подробностями обратитесь к Подразделу 16.2.5.

16.2.3. Установка в командной строке

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

16.2.3.1. Параметры командной строки

Путь каталога инсталляции:

Полностью автоматическая установка:

INI -файл, содержащий параметры установки сервера:

Если вы хотите скорректировать стандартные параметры, вы должны создать INI -файл вручную, как описано в Подразделе 16.2.3.2.

16.2.3.2. Формат INI-файла

В разделе [options] данного файла можно задать следующие параметры:

InstallDir — путь для установки сервера. Если вы зададите параметр /D в командной строке, значение InstallDir будет иметь приоритет.

DataDir — путь для создания баз данных по умолчанию

Port — порт TCP/IP для приёма подключений. По умолчанию: 5432.

SuperUser — имя пользователя, который получит права администратора баз данных

Password — пароль этого пользователя

noExtConnections = 1 — не разрешать внешние подключения.

Coding = UNICODE — кодировка символов для использования в базе данных

Locale — локаль для использования в базе данных (для каждой кодировки может быть несколько локалей)

vcredist = no — не устанавливать распространяемые библиотеки Visual C (это можно сделать, только если эти библиотеки уже установлены в системе)

envvar = 1 — установить полезные для Postgres Pro переменные окружения: PGDATA , PGDATABASE , PGUSER , PGPORT , PGLOCALEDIR

needoptimization = 0 — отключить автоматическую настройку параметров конфигурации в зависимости от имеющихся системных ресурсов.

datachecksums = 0 — отключить контрольные суммы в кластере.

serviceaccount — пользователь Windows, от имени которого будет запускаться служба Postgres Pro . Указанный пользователь должен иметь право запуска служб Windows. По умолчанию служба Postgres Pro запускается от имени NT AUTHORITY\NetworkService , специальной учётной записи для служб Windows.

servicepassword — пароль для пользователя Windows, указанного в параметре serviceaccount .

Начнем с того, что дистрибутив PostgreSQL нужно брать ИТС-ный, ибо че-то там не так, если качать с официальных страниц СУБД.

*Буду стараться делать так, сначала будет идти скриншот, ниже описание.

У меня на руках postgresql-9.1.2-1.1C(x64) так что нажимаю на установщике .exe

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

И здесь оставил все по умолчанию, ибо сам не знаю толком, какая опция и за что отвечает, все и так заработает без проблем.

Здесь зададим пользователю postgres, под которым будет запускаться СУБД (если данного пользователя нет в системе, он будет автоматически создан) пароль, сложный, сложный, все остальные параметры заполнились самостоятельно и трогать их не вижу смысла.

Как видим из описания о пользователе, postgres пользователю также нужно задать пароль, что и сделаем.

Кодировку лучше изменить на UTF-8, почему? А я не знаю, уже и забыл преимущества данной кодировки, умные люди в комментариях опишут, почему лучше та или иная кодировка

Поддерживать подсоединения с любых IP, а не только с localhost – означает, мол, будет возможность подключаться к серверу извне в локальной сети

Уведомление смиренно прочитали и запомнили, что нужно и куда нужно зайти после установки, продолжаем .

Тут как бы все понятно, жмем WIN+R вводим services.msc находим службу «Вторичный вход в систему» и запускаем ее + ставим автозапуск службы, далее опять повторяем нажатие «Далее», где видим

Это что-то такое мудрёное, что для нашей задачи навряд ли понадобится, пропускаем смело, оставляем все как есть

Какие там модули, мы устанавливать без модулей еще не научились, поэтому что было по умолчанию, то и оставляем.

Ждем окончания установки.

Нам эти фишки ни к чему, снимаем галку, жмем «Завершить»

Управление СУБД осуществляется утилитой pgAdmin III, которую можно найти в списке программ Пуск, но имейте в виду, что нужно ее обновить, ибо после запуска pgAdmin III и последующего подключения к БД получаем картинку

Обновление я качнул с официального ресурса

Приступим к установке 1С сервера

У меня мега 1C_8.3.7.1633 версия, так что поехали

Здесь ничего нового, устанавливаем компоненты сервера и, чтобы администрировать им, устанавливаем компоненты администрирования

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

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

! Для управление кластером серверов 1С используем Администрирование серверов 1С Предприятия
! Для управления СУБД используем pgAdmin III

Давайте теперь попробуем создать новую, пустую базу данных посредством программы запуска информационных баз 1С - 1cestart.exe

Кластер серверов 1С Предприятие = 192.168.1.111 это айпишник компьютера, на котором установлен сервера 1С, в нашем случаи это наш основной пк

Имя информационной базы в кластере = пишем, что хотим, если БД с таким именем не будет, создастся автоматически

Защищенное соединение = не трогаем, пока без этого обойдемся

Тип СУБ = коль установили Postgresql, тогда и выбираем данную СУБД из списка

Сервер базы данных = айпишний, тот же айпишник компьютера, на котором установлена СУБД

Имя базы данных = как назовем, так и будет называться наша БД в списке СУБД

Пользователь базы данных = да, наш пользователь из СУБД, помните, это postgres

Пароль пользователя = пароль выше упомянутого пользователя

Создать базу данных в случаи ее отсутствия = Да, ставим галку

Все иные параметры типа Язык и ниже галка о блокировке заданий не изменяем, не нужно пока это, если вы читаете данный текст.

Результат на экран

А теперь попробуем по локальной сети подключиться к нашей базе данных.

А это ничто иное, как блокировка портов брандмауэром, а именно 1541, 1560 портов, который нужно разрешить

И получаем запущенный сеанс

А теперь продемонстрирую удаленное подключение, из интернета к нашей базе

Предварительно, настраиваем на сервере 1С форвардинг портов на роутере, типа

Соответственно, напомню, эти же порты должны быть открыты брандмауэром

Далее, на удаленном компьютере (назовем его клиент), открываем файл hosts, что находится по пути в проводнике %WinDir%\System32\Drivers\Etc и добавляем запись

77.121.199.91 ws

Где циферки - это айпи адрес внешний нашего сервера, а буковки это название нашего сервера, к которому подключаемся

А также на клиенте нужно открыть файл nethasp.ini, который находится по пути C:\Program Files (x86)\1cv8\conf, найти параметр NH_SERVER_ADDR, который нужно разкомментировать + вместо <Addr1> вписать внешний айпишник нашего сервера, в итоге вышло

А далее, на том же удаленном компьютере добавляем запись для подключения к информационной базе, указываем наш алиас, который задали в файле hosts + порт кластера серверов ну и наименование нашей БД с кластера

Спасибо тебе, Хабр, за то, что ты есть и за те прекрасные часы которые я проводил в тебе! Спасибо, отважные хаброписатели, за статьи высокого качества, тонкого юмора и широкого кругозора. Только благодаря вам и Марь Ивановне (которая меня в первом классе научила читать) я добился серьёзных успехов в ИТ, а теперь хочу поделиться историей, когда нестандартное мышление помогло решить идиоматическую задачку от заказчика.

Вступление

Некоторое время назад я работал над проприетарным продуктом. Этот софт хранил свои данные во внешней СУБД. Первоначально работа осуществлялась с MS SQL, однако позже специально для пользователей «я только *nix-подобные системы ставлю» сделали совместимость с PostgreSQL. Тут взяли меня для решения задач класса «база данных упала — нужно восстановить по журналам транзакций».

Установить СУБД PostgreSQL на Windows;
Обеспечить репликацию данных между БД;
Решить вопрос с отказоустойчивостью.

1. Установка PostgreSQL

Здесь всё просто:

Качаем дистрибутив для Windows — нам подойдёт версия 9.4 для х64;
Запускаем установщик, выбираем русскую локаль, установку в директорию по умолчанию и играем в эникейщика, нажимая кнопку «Далее».

2. Репликация данных

По умолчанию нам поставиться Slony-I, однако асинхронная репликация уже есть в «коробке», чем мы и воспользуемся. Иногда доступ к командной строке linux и файлам настройки ИБшники отказывались выдавать, и мне приходилось настраивать СУБД через psql, поэтому далее пойдут mad skillz. Здесь и в последующем все утилиты берутся из папки C:\Program Files\PostgreSQL\9.4\bin\ (правильно было бы указать переменную $PGDATA, но она почему-то по умолчанию не была задана инсталлятором). На мастере:

Подключаемся к СУБД командой:

Включаем режим дублирования данных:

Отключаем режим архивирования:

Разрешаем создавать слоты репликации:

Задаём максимальное количество процессов репликации данных (второй процесс будет обслуживать работу утилиты pgadmin):

Выполняем команду "\!" и… Ха-ха! Мы оказываемся в командной строке Windows. Редактируем файл pg_hba.conf (здесь и далее имеются ввиду файлы из папки C:\Program Files\PostgreSQL\9.4\data). Он отвечает за доступ хостов\пользователей к СУБД. Добавляем строчки:

1. Останавливаем службу postgresql.

2. Удаляем содержимое папки C:\Program Files\PostgreSQL\9.4\data

3. Делаем бэкап с мастера при помощи команды pg_basebackup. В качестве параметров используем:

В конце выполнения утилита возмутиться, что WAL-архивирование не настроено, но нам это принципиально не нужно из-за следующего этапа (как бонус — экономия дискового пространства).

4. Заходим в файл postgresql.conf и устанавливаем параметры:

Возвращаемся на мастер:

1. Назначаем хост мастером:

2. Отключаем ожидание отклика от слейва:

3. Отключаем интервал в передаче WAL-журнала:

4. Перезапускаем службу СУБД на мастере (можно не выходя из psql):

5. Создаём слот репликации:

3. Отказоустойчивость

Slony-I не входил в спецификацию проекта, и к нему было лениво выдумывать скрипты PowerShell. Заказчик напрочь отказался ставить дополнительный linux-сервер, таким образом вариант с pgpool-II или pgbouncer отпал (да и непонятно, как ими работать с Windows). Поэтому остался переход в режим записи по файлу-триггеру. Донастроим слейв для перехода в режим мастера. Для этого необходимо создать файл recovery.conf и в него добавить строки:

Примечание: если слейв перейдёт в режим мастера то файл поменяет имя на recovery.done.

Запускаем службу postgres на слейве. В случае успешной настройки она стартанёт корректно и будет стягивать данные с мастера. Проверить репликацию можно:

— На мастере при помощи команды:

— На слейве можно попробовать создать какой-либо объект и получить ошибку транзакции «только на чтение». Для клиента можно на мастере создать тестовую таблицу, которая автоматически дублируется на слейве.

В случае сбоя мастера потенциальный сисадмин должен выполнить следующую последовательность действий:

а) Убедиться, что мастер на запись недоступен;
б) Проверить, что ip-адрес кластера СУБД свободен. Например, пингануть ip или вырубить сетевой интерфейс мастера;
в) Поменять ip слейва на ведущий;
г) Указать слейву работать как мастер. Для этого можно использовать pg_ctl promote (на объекте вываливалась ошибка повышений привилегий службы) или, так как мы настроили файл-триггер реконфигурации, создать пустой файл startmaster.

Дополнительно (то, что не входило в рамки поставленной задачи): из упавшего мастера можно сделать слейв, выполнив пункты настройки слейва из второго этапа.

Мой начальник пошутил: "Ты ж Шарп знаешь — напиши!". Два дня потуг в поле на коленке — я взял и запилил. Про основы ООП и потокобезопасность прошу все комментарии писать сюда).

Программа использует библиотеку Npgsql для работы с СУБД. Распаковать архив нужно на слейве и запустить программу на выполнение.

Далее требуется ввести:

— ip слейва;
— ip мастера;
— ip кластера (основной ip по идее должен совпадать с ip-мастера, но всякое бывает);
— имя БД, к которой будет производиться подключение (в ней создаться тестовая таблица testofcluster)

Для выполнения проверки кластера нужно нажав кнопку «Test». Программа проверит, что запущена на слейве, мастер позволяет производить запись в тестовую таблицу и репликация происходит в штатном режиме. В качестве бонуса будут сохранены файлы recovery.conf, postgresql.conf, postgresql.auto.conf на слейве, что упростит процедуру перевода мастера в режим слейва.

Запустить мониторинг: ПО циклически проверяет доступность мастера и в случае выхода его из строя — переводит слев в режим записи и меняет ip слева на кластерный.