Устанавливаем PostgreSQL. Устанавливаем PostgreSQL Установка и настройка 1с сервер postgresql
Вариант использования в качестве сервера баз данных PostgreSQL на windows платформе не очень популярен, но имеет место быть как правило, когда необходимо хоть как-то сэкономить на продуктах от MS. Так же существуют специализированные приложения, которые наилучшим образом работают с PostgreSQL. Для 1с существует модифицированная сборка PostgreSQL дающая как уверяют разработчики сопоставимый с MSSQL уровень производительности и отказоустойчивости. Так ли это на самом деле, проверим на практике:)
1. Установка PostgreSQL
Качаем с сайта 1с последнюю сборку PostgreSQL 64-bit 9.1.2-1.1C, распаковываем архив, запускаем msi-пакет, тот что без int, имеет не большой размер файла.
Нажимаем Start.
Опции установки оставляем по умолчанию.
Задаем пароль пользователю postgres
от которого будет стартовать сервис.
Нажимаем Далее. Если установка PostgreSQL производится впервые, то мастер предложит создать пользователя postgres.
На этапе инициализации БД, выбираем кодировку UTF8. Задаем логин и пароль внутреннему пользователю postgres. Внимание! Пароли пользователя сервиса PostgreSQL и пароль внутреннего пользователя БД PostgreSQL не должны совпадать. Пароль должен состоять как минимум из четырех символов. Если сервер 1C и PostgreSQL планируется запускать на разных машинах, то необходимо поставить галочку «Поддерживать соединения с любых IP, а не только с localhost». Нажимаем Далее и еще раз Далее. :)
Нажимаем еще два раза Далее и дожидаемся окончания установки.
Затем идем в Start\All Programs\PostgreSQL 9.1.2-1.1C(x64). Запускаем утилиту администрирования pgAdmin III. Пробуем подключится к БД. Вводим пароль, который указывали во время установки.
И получаем следующую ошибку: Error connecting to the server: FATAL: password authentication failed for user «postgres».
Довольно неожиданно, с учетом того, что пароль был набран верно. Решил поковырять pg_hba.conf, но на первый взгляд там все хорошо.
# TYPE DATABASE USER ADDRESS METHOD # IPv4 local connections: host all postgres::1/128 md5 host all postgres 127.0.0.1/32 md5 host all postgres 192.168.1.0/24 md5
Решил, поменять метод авторизации с md5 на trust. Перезапускаю сервис и снова пробую подключится к БД. На этот раз получаю такое сообщение. 
Действительно на сайте pgAdmin доступна уже более новая версия. После чего подключение к БД завершается успехом!!?!! Помнится, ранее md5 не вызывал подобных проблем, видимо данный глюк действительно связан со старой версией pgAdmin’a. 
Теперь можем создать базу для нужд 1С, либо сделать это при помощи самой 1С:)
2. Установка 1C предприятие 8.2.
Для установки отметим, следующие компоненты: 1С:Предприятие, Сервер 1С:Предприятия, Модули расширения веб-сервера, Администрирование сервера 1С:Предприятия.
На этапе, установки «Установить 1С Предприятие как сервис», задаем пароль пользователю USR1C82. 
Нажимаем далее, следим за ходом установки:) Пользователю USR1CV82
при установке должны быть назначены следующие права:
Вход в систему как сервис (Log on as a service), Вход в систему как пакетное задание (Log on as a batch job). Посмотреть можно в Local Computer Policy\Computer Configuration\Windows Setings\Security Setings\Local Policies\User Right Assigments.
Переходим в оснастку Администрирование серверов 1С Предприятие,
смотрим что кластер поднялся, и висит на 1541 порту. На вкладке «Рабочие серверы» так же присутствует наш сервер.
Теперь, можно добавить базу на сервер 1С. Для этого переходим на вкладку «Информационные базы
» щелкаемся правой кнопкой и выбираем New — Информационная база
. Задаем необходимые параметры для подключения к серверу PostgreSQL. Нажимаем ОК.
Запускаем 1С: Предприятие. Выбираем, добавить существующую информационную базу на сервере. 
Далее, задаем параметры для подключения. Нажимаем «Далее» и наконец «Готово».
Операцию по созданию базы, можно проделать напрямую из 1С: Предприятия. Для этого при запуске, выбираем пункт «Создание новой информационной базы».
Для подключения клиентов 1С к серверу извне и работы сервера баз данных, на файрволе, должны быть открыты следующие порты:
Агент сервера (ragent ) — tcp:1540 Главный менеджер кластера (rmngr ) — tcp:1541 Диапазон сетевых портов, для динамического распределения рабочих процессов — tcp:1560-1591, tcp:5432 — Postgresql. Создадим правило через стандартный интерфейс, либо с помощью команды:
netsh advfirewall firewall add rule name=»1Cv8-Server» dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=ANY remoteip=ANY interfacetype=LAN
Теперь с другого компьютера мы спокойно запускаем клиент 1С:Предприятия, добавляем существующую информационную базу newdb . Не забываем про лицензии, программной / аппаратной защиты. Теперь, можем загрузить тест Гилева и померить производительность нашей системы.
На VirtualBox с 1Гб памяти, Dual-Core 2.6 GHz, 319-релиз 1с, тест Гилева выдает — 11.42 баллов, примерно так же как на CentOS. На 16.362 чуть больше 11.60 баллов. Оптимизация настроек при помощи EnterpriseDB Tuning Wizard ощутимого прироста (11.66 и 11.62) не дала, хотя возможно в целом польза от него имеется. :)
3. Регламентные работы на сервере PostgreSQL.
Резервное копирование.
Запускаем утилиту администрирования pgAdmin III, щелкаемся правой кнопкой по нужной базе данных. Выбираем »Резервное копирование». 
Выбираем формат (Настраиваемый (степень сжатия от 0 до 9), Tar, Простой, Каталог). По степени сжатия, лучше всего сжимает «настраиваемый формат» любой степени сжатия, затем «каталог», потом «простой» и наконец «tar». Кодировку указываем UTF8, имя роли postgresql. Все дополнительные опции оставляем по умолчанию. Нажимаем кнопку «Резервная копия». В поле «Сообщения» отображается список всех произведенных операций с кодом завершения. Если 0, то успех. Здесь же можно подсмотреть, как запустить подобную операцию из командной строки.
F)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump.backup" "newdb"
Соответственно, скрипт автоматического резервного копирования, который мы добавим в планировщик может выглядеть примерно следующим образом:
"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0,2%_%date:~3,2%_%date:~6,4%.backup" "newdb"
Восстановление.
Для восстановления, выбираем базу, в которую хотим восстановить данные из резервной копии, желательно в пустую. Щелкаемся правой кнопкой и выбираем «Восстановление». Задаем файл бэкапа, имя роли: postgres, нажимаем «Восстановить» 
С помощью командной строки:
"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --host 192.168.1.200 --port 5432 --username "postgres" --dbname "testdb" --role "postgres" --no-password --verbose "G:\Backups\gilev_dump_26_09_2012.backup"
где, testdb — пустая база, в которую восстанавливается архив резервной копии.
Операции по обслуживанию:
Команда VACUUM (Сжатие):
Последовательно чистит все таблицы базы данных, подключенной в настоящий момент, удаляет временные данные и освобождает место на диске. Чаще всего команда VACUUM выполняется именно для получения максимального объема свободного дискового пространства на диске и увеличения скорости доступа к данным.
VACUUM
— помечает место, занимаемое старыми версиями записей, как свободное. Использование этого варианта команды, как правило, не уменьшает размер файла, содержащего таблицу, но позволяет не дать ему бесконтрольно расти, зафиксировав на некотором приемлемом уровне. При работе VACUUM возможен параллельный доступ к обрабатываемой таблице. Существует несколько дополнительных опций использования VACUUM: VACUUM FULL, VACUUM FREEZE, VACUUM ANALYZE.
VACUUM FULL — пытается удалить все старые версии записей и, соответственно, уменьшить размер файла, содержащего таблицу. Этот вариант команды полностью блокирует обрабатываемую таблицу.
VACUUM FREEZE — Если VACUUM FULL удаляет «мусор» из таблиц и перемещает записи так, чтобы таблицы располагались на диске компактно и состояли из наименьшего числа фрагментов, при этом сжатие выполняется долго и блокирует записи, то VACUUM FREEZE просто удаляет «мусор» из таблиц, но сами записи не перемещает, поэтому выполняется быстрее и не блокирует записи. В настоящий момент эту опцию заменяет autovacuum — автоматическая сборка мусора в postgresql.conf плюс несколько дополнительных опций расширяющих функциональность:
autovacuum = on
# Включает автоматическую сборку мусора.
log_autovacuum_min_duration = -1
# Установка равная нулю регистрирует все действия autovacuum. Минус один (по умолчанию) запрещает вывод в лог. Например, если вы установите значение
равное 250 мс, то все действия autovacuum и analyzes, которые работают 250 мс и более, будут заноситься в журнал. Включение этого параметра может быть полезно для отслеживания autovacuum.
Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
autovacuum_naptime = 10min
# Время в секундах через которое база данных проверяется на необходимость в сборке мусора. По умолчанию это происходит раз в минуту.
autovacuum_vacuum_threshold
= 1800 # Порог на число удалённых и изменённых записей в любой таблице по превышению которого происходит сборка мусора (VACUUM).
autovacuum_analyze_threshold
= 900 # Порог на число вставленных, удалённых и изменённых записей в любой таблице по превышению которого запускается процесс анализа (ANALYZE).
autovacuum_vacuum_scale_factor
= 0.2 # Процент изменённых и удалённых записей по отношению к таблице по превышению которого запускается сборка мусора.
autovacuum_analyze_scale_factor
= 0.1 # То же, что и предыдущая переменная, но по отношению к анализу.
VACUUM ANALYZE
— Если в базе есть таблицы, данные в которых не изменяются и не удаляются, а лишь добавляются, то для таких таблиц можно использовать отдельную команду ANALYZE. Также стоит использовать эту команду для отдельной таблицы после добавления в неё большого количества записей.
Команда ANALYZE (Анализ):
Служит для обновления информации о распределении данных в таблице. Эта информация используется оптимизатором для выбора наиболее быстрого плана выполнения запроса. Обычно команда используется в связке с VACUUM ANALYZE .
Команда REINDEX (переиндексация):
Используется для перестройки существующих индексов. Использовать её имеет смысл в случае
— порчи индекса;
— постоянного увеличения его размера.
Второй случай требует пояснений. Индекс, как и таблица, содержит блоки со старыми версиями записей. PostgreSQL не всегда может заново использовать эти блоки, и поэтому файл с индексом постепенно увеличивается в размерах. Если данные в таблице часто меняются, то расти он может весьма быстро. Если вы заметили подобное поведение какого-то индекса, то стоит настроить для него периодическое выполнение команды REINDEX. Учтите: команда REINDEX, как и VACUUM FULL, полностью блокирует таблицу, поэтому выполнять её надо тогда, когда загрузка сервера минимальна.
Устанавливать будем сборку от компании Postgres Professional . На странице с версией для 1С:Предприятие найдем информацию об установке на CentOS 7 свежей версии PostgreSQL.
Подключим репозитории и установим PostgreSQL 9.6:
Sudo rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm sudo yum makecache sudo yum install postgresql-pro-1c-9.6
Базовая настройка PostgreSQL
Инициализируем служебные базы данных с русской локализацией:
Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 exit service postgresql-9.6 initdb
Запускаем службу PostgreSQL и добавляем его в автозагрузку:
Systemctl enable postgresql-9.6 systemctl start postgresql-9.6 systemctl status postgresql-9.6
Задаем пароль пользователю postgres, для того чтобы была возможность подключаться к серверу удаленно:
Su - postgres psql ALTER USER postgres WITH ENCRYPTED PASSWORD "yourpassword"; \q exit
Mcedit /var/lib/pgsql/9.6/data/pg_hba.conf
в открывшемся файле раскомментируем и изменим строки:
host all all 127.0.0.1/32 ident на host all all 127.0.0.1/32 md5
host all all 0.0.0.0/0 ident на host all all 0.0.0.0/0 md5
Оптимизация настроек PostgreSQL (postgresql.conf) для 1С:Предприятие
Здесь будут настройки для PostgreSQL, работающей в виртуальной машине ESXi 6.5.
Ресурсы выделенные для ВМ:
процессор — 8 vCPU;
память — 48 GB;
диск для ОС — 50 GB на LUN аппаратном RAID1 из SAS HDD;
диск для БД — 170 GB на программном RAID1 из SSD
диск для логов — 100 GB на программном RAID1 из SSD
Для редактирования настроек выполним команду:
Mcedit /var/lib/pgsql/9.6/data/postgresql.conf
Закомментированные параметры, которые будем изменять необходимо активировать.
Процессор
autovacuum_max_workers = 4
autovacuum_max_workers = NCores/4..2 но не меньше 4
Количество процессов автовакуума. Общее правило - чем больше write-запросов, тем больше процессов. На read-only базе данных достаточно одного процесса.
ssl = off
Выключение шифрования. Для защищенных ЦОД’ов шифрование бессмысленно, но приводит к увеличению загрузки CPU
Память
shared_buffers = 12GB
shared_buffers = RAM/4
Количество памяти, выделенной PgSQL для совместного кеша страниц. Эта память разделяется между всеми процессами PgSQL. Операционная система сама кеширует данные, поэтому нет необходимости отводить под кэш всю наличную оперативную память.
temp_buffers = 256MB
Максимальное количество страниц для временных таблиц. Т.е. это верхний лимит размера временных таблиц в каждой сессии.
work_mem = 64MB
work_mem = RAM/32..64 или 32MB..128MB
Лимит памяти для обработки одного запроса. Эта память индивидуальна для каждой сессии. Теоретически, максимально потребная память равна max_connections * work_mem, на практике такого не встречается потому что большая часть сессий почти всегда висит в ожидании. Это рекомендательное значение используется оптимайзером: он пытается предугадать размер необходимой памяти для запроса, и, если это значение больше work_mem, то указывает экзекьютору сразу создать временную таблицу. work_mem не является в полном смысле лимитом: оптимайзер может и промахнуться, и запрос займёт больше памяти, возможно в разы. Это значение можно уменьшать, следя за количеством создаваемых временных файлов:
maintenance_work_mem = 2GB
maintenance_work_mem = RAM/16..32 или work_mem * 4 или 256MB..4GB
Лимит памяти для обслуживающих задач, например по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске.
effective_cache_size = 36GB
effective_cache_size = RAM — shared_buffers
Оценка размера кеша файловой системы. Увеличение параметра увеличивает склонность системы выбирать IndexScan планы. И это хорошо.
Диски
effective_io_concurrency = 5
Оценочное значение одновременных запросов к дисковой системе, которые она может обслужить единовременно. Для одиночного диска = 1, для RAID - 2 или больше.
random_page_cost = 1.3
random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для SSD
Стоимость чтения рандомной страницы (по-умолчанию 4). Чем меньше seek time дисковой системы тем меньше (но > 1.0) должен быть этот параметр. Излишне большое значение параметра увеличивает склонность PgSQL к выбору планов с сканированием всей таблицы (PgSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). И это плохо.
autovacuum = on
Включение автовакуума.
autovacuum_naptime = 20s
Время сна процесса автовакуума. Слишком большая величина будет приводить к тому, что таблицы не будут успевать вакуумиться и, как следствие, вырастет bloat и размер таблиц и индексов. Малая величина приведет к бесполезному нагреванию.
bgwriter_delay = 20ms
Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на checkpoint процесс и процессы, обслуживающие сессии (backend). Малое значение приведет к полной загрузке одного из ядер.
bgwriter_lru_multiplier = 4.0
bgwriter_lru_maxpages = 400
Параметры, управляющие интенсивностью записи фонового процесса записи. За один цикл bgwriter записывает не больше, чем было записано в прошлый цикл, умноженное на bgwriter_lru_multiplier, но не больше чем bgwriter_lru_maxpages.
synchronous_commit = off
Выключение синхронизации с диском в момент коммита. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.
wal_keep_segments = 256
wal_keep_segments = 32..256
Максимальное количество сегментов WAL между checkpoint. Слишком частые checkpoint приводят к значительной нагрузке на дисковую подсистему по записи. Каждый сегмент имеет размер 16MB
wal_buffers = 16 MB
Объём разделяемой памяти, который будет использоваться для буферизации данных WAL, ещё не записанных на диск. Значение по умолчанию, равное -1, задаёт размер, равный 1/32 (около 3%) от , но не меньше, чем 64 КБ и не больше, чем размер одного сегмента WAL (обычно 16 МБ). Это значение можно задать вручную, если выбираемое автоматически слишком мало или велико, но при этом любое положительное число меньше 32 КБ будет восприниматься как 32 КБ. Этот параметр можно задать только при запуске сервера.
Содержимое буферов WAL записывается на диск при фиксировании каждой транзакции, так что очень большие значения вряд ли принесут значительную пользу. Однако значение как минимум в несколько мегабайт может увеличить быстродействие при записи на нагруженном сервере, когда сразу множество клиентов фиксируют транзакции. Автонастройка, действующая при значении по умолчанию (-1), в большинстве случаев выбирает разумные значения.
default_statistics_target = 1000
Устанавливает целевое ограничение статистики по умолчанию, распространяющееся на столбцы, для которых командой ALTER TABLE SET STATISTICS не заданы отдельные ограничения. Чем больше установленное значение, тем больше времени требуется для выполнения ANALYZE , но тем выше может быть качество оценок планировщика. Значение этого параметра по умолчанию - 100.
checkpoint_completion_target = 0.9
Степень «размазывания» checkpoint’a. Скорость записи во время checkpoint’а регулируется так, что бы время checkpoint’а было равно времени, прошедшему с прошлого, умноженному на checkpoint_completion_ target.
min_wal_size = 4G
max_wal_size = 8G
min_wal_size = 512MB .. 4G
max_wal_size = 2 * min_wal_sizeМинимальное и максимальный объем WAL файлов. Аналогично checkpoint_segments
fsync = on
Выключение параметра приводит к росту производительности, но появляется значительный риск потери всех данных при внезапном выключении питания. Внимание: если RAID имеет кеш и находиться в режиме write-back, проверьте наличие и функциональность батарейки кеша RAID контроллера! Иначе данные записанные в кеш RAID могут быть потеряны при выключении питания, и, как следствие, PgSQL не гарантирует целостность данных.
row_security = off
Отключение контроля разрешения уровня записи
enable_nestloop = off
Включает или отключает использование планировщиком планов соединения с вложенными циклами. Полностью исключить вложенные циклы невозможно, но при выключении этого параметра планировщик не будет использовать данный метод, если можно применить другие. По умолчанию этот параметр имеет значение on .
Блокировки
max_locks_per_transaction = 256
Максимальное число блокировок индексов/таблиц в одной транзакции
Настройки под платформу 1С
standard_conforming_strings = off
Разрешить использовать символ \ для экранирования
escape_string_warning = off
Не выдавать предупреждение о использовании символа \ для экранирования
Настройка безопасности
Сделаем так, чтобы сервер PostgreSQL был виден только для сервера 1С: Предприятие, установленного на этой же машине.
listen_addresses = ‘localhost’
Если сервер 1С: Предприятие установлен на другой машине или существует необходимость подключиться подключиться к серверу СУБД с помощью оснастки PGAdmin, то вместо localhost нужно указать адрес этой машины.
Хранение базы данных
PostgreSQL как и почти любая СУБД критична к дисковой подсистеме, поэтому для повышения быстродействия СУБД разместим систему PostgreSQL, логи и сами базы на разные диски.
Останавливаем сервер
Systemctl stop postgresql-9.6
Переносим логи на из 120GB SSD:
Mv /var/lib/pgsql/9.6/data/pg_xlog /raid120 mv /var/lib/pgsql/9.6/data/pg_clog /raid120 mv /var/lib/pgsql/9.6/data/pg_log /raid120
Ln -s /raid120/pg_xlog /var/lib/pgsql/9.6/data/pg_xlog ln -s /raid120/pg_clog /var/lib/pgsql/9.6/data/pg_clog ln -s /raid120/pg_log /var/lib/pgsql/9.6/data/pg_log
Так же перенесем каталог с базами:
Mv /var/lib/pgsql/9.6/data/base /raid200
Ln -s /raid200/base /var/lib/pgsql/9.6/data/base
запустим сервер и проверим его статус
Systemctl start postgresql-9.6 systemctl status postgresql-9.6
Хотя интернет уже переполнен статьями о «правильной» настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самая большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно.
Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?
Итак, что имеем: игрушку IBM x3650 M4 c двумя процессорами, 32 GB оперативки, массив RAID 10 из 6-и дисков общим объемом ~900GB. Являясь сторонником опенсорсного ПО и немалый опыт работы с системами а-ля Debian и производные, решил выбрать в качестве операционки самую «человечную» из них - Ubuntu Server x64. Как потом оказалось - это была первая моя ошибка.
С СУБД знаком не понаслышке но, имею пока еще малый опыт работы именно на Linux платформу. Поэтому, если где-то ошибся, прошу пинать строго советами. Не один я такой все-таки.
Наконец 1С выпустила свежую сборку PostgreSQL под Debian/Ubuntu которая работает почти «из коробки».
Процес установки упростился до дюжины консольных комманд.
Admin@srv1c:~# sudo su
1. Увеличиваем максимальный размер сегмента памяти до 8Гб. Для менее мощных машин устанавливают от 64Мб до половины объема оперативки.
Root@srv1c:~# echo "kernel.shmmax=8589934592" >>/etc/sysctl.conf root@srv1c:~# sysctl -p
2. Генерируем русскую локаль и задаем переменную среды LANG, именно с ней будет работать скрипт инициализации базы данных.
Root@srv1c:~# locale-gen en_US ru_RU ru_RU.UTF-8 root@srv1c:~# export LANG="ru_RU.UTF-8"
3.Устанавливаем необходимые зависимисти.
Root@srv1c:~# apt-get install libssl0.9.8 ssl-cert postgresql-common libossp-uuid16 libxslt1.1
4. Берем с сайта users.v8.1c.ru архив с PostgreSQL 9.1.2 для 64-битных DEB-систем, распаковываем и устанавливаем нужные компоненты. Нужных и не нужных компонентов в архиве много, для того что бы все заработало достаточно postgresql, postgresql-client и postgresql-contrib.
Root@srv1c:~# tar zxf postgresql_9_1_2_deb_x86_64_tar.gz
5. Установка пакетов:
Root@srv1c:~# cd ./postgres root@srv1c:~# dpkg -i postgresql-9.1_9.1.2-1.1C_amd64.deb libpq5_9.1.2-1.1C_amd64.deb postgresql-client-9.1_9.1.2-1.1C_amd64.deb postgresql-contrib-9.1_9.1.2-1.1C_amd64.deb
6. После установки нужно еще немного подправить конфигурационный файл, как не странно будучи поставленным в пакете 1с он содержит не правильные настройки для обработки экранирующих символов, и при создании базы 1с выдает ошибки “syntax error at or near “SECOND” at character 127″ или “syntax error at or near “SECOND” at character 227″. Исправляем в файле /etc/postgresql/9.1/main/postgresql.conf следующие параметры.
Root@srv1c:~# nano /etc/postgresql/9.1/main/postgresql.conf
Backslash_quote = on escape_string_warning = off standart_conforming_strings = off
И закрываем с сохранением: Ctrl+x, Y
7. Перезапускаем сервис.
Root@srv1c:~# service postgresql restart
8.Меняем пароль для пользователя postgres – это тот пароль который мы будем задавать при создании базы данных.
Root@srv1c:~# su postgres postgres@srv1c:/root$ cd ~ postgres@srv1c:~$ psql -U postgres -c "alter user postgres with password "ваш пароль";" postgres@srv1c:~$ exit
9. Отключаем обновление для пакетов 1с-овского PostgreSQL.
Root@srv1c:~# echo "libpq5" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-9.1" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-client-9.1" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-contrib-9.1" hold | dpkg --set-selections
10. Перезапускаем службу и проверяем, запустился ли PostgreSQL:
Root@srv1c:~# service postgresql restart root@srv1c:~# netstat -atn|grep 5432
Ответ должен быть примерно таким:
Tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN
Tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN
Здесь установка PostgreSQL закончена можно считать законченной.
При сравнении скорости работы связки 1C 8.2.16 + PostgeSQL 9.1.2 были обнаружены жуткие тормоза под Ubuntu Server 12.04. Тест от Гилёва «TPC_1С_GILV» в Ubuntu в среднем показал 10-14 баллов, что обусловлено тестовой базой, которая не задействует управляемые блокировки. Для сравнения, на менее мощную систему с четырехядерным процессором i5, 8GB оперативки, под Win 2k8 и IBM DB2 тот же тест показал 52 попугая. Проведение документов за месяц занимало в трое меньше времени на младшую машину. Аналогичные результаты получены и с PostgreSQL. Некоторые коллеги отзываются о результатах на CentOS при аналогичных параметрах. Так на CentOS получают по тому же тесту 56-62 балла а на чистую Debian - от 54 балла. Во всех тестах использовались идентичные настройки PG с отключенным fsync. В Ubuntu проверялись ext4, в CentOS LVM+ext3.
На всех платоформах ничего не ставилось кроме PG и 1C. На Ubuntu проверялись несколько версий PG, от Etersoft, собранная вручную с патчами от 1С и сборка от 1С, под CentOS использовалась версия Etersoft.
Есть какие-то варианты улучшения производительности в Ubuntu?
Я уже готовлю систему под CentOS. О результатах тестирования отпишусь в новой статье.
Инструкция по установке PostgreSQL 9.0.3-3.1C на Windows Server 2008 x64
Для установки используем пакет - PostgreSQL 9.0.3-1C (x 86 или x 64).
Запускаем msi-пакет:
Отмечаем галочкой, если не отмечено «Директория с данными», «psql » и «pgAdmin III ». Далее.
Устанавливаем "как сервис". Для работы этого сервиса потребуется специальный пользователь. Указываем учетную запись, домен (если имеется) и пароль. Далее.
Если такого пользователя в системе нет, тогда мастер сам предложит создать нового. Отвечаем "да" - пользователь создается. Далее.
Теперь инициализируем БД. Указываем порт 5432. Проверяем, что кодировка UTF 8. Задаем логин и пароль пользователя PostgreSQL (система предупреждает, что пароль пользователя системы и пароль пользователя PostgreSQL НЕ ДОЛЖНЫ совпадать – учитываем это). Если кластер серверов 1С и PostgreSQL на разных машинах, то ставим галочку «Поддерживать подсоединения с любых IP , а не только с localhost ». Далее.
Может возникнуть ошибка «Secondary Logon » . Тогда идем в «Администрирование» – «Службы». Стартуем службу «Вторичный вход в систему» или «Secondary Logon »:
Программа устанавливается.
Через меню "Пуск" - "Все программы" запускаем утилиту администрирования «pgAdmin III ».
Подключаемся к серверу. Там вводим пароль для пользователя «postgres ». Если подключиться удалось, попробуем создать новую базу средствами самой 1С.
Запускаем клиентскую часть 1С. Жмем кнопку "Добавить", ставим галочку "Сервер предприятия 1С". Далее заполняем следующее: сервер базы данных (IP или DNS имя того сервера, куда ставили PostgreSQL) - если тот же, что и кластер 1С, то указываем 127.0.0.1. Имя базы данных: [любое_имя]. Пользователь: "postgres" Пароль: [ваш_пароль_postgres]. Далее.
Проверяем, что база 1С создается успешно.
1 Ноя 2012 Преимущества использования свободно распространяемого программного обеспечения очевидны. К сожалению, очевидны и недостатки - нет официальной поддержки, зачастую документация противоречива, неполна и разбросана по разным источникам. Эта статья поможет разобраться с процессом установки PosgreSQL для "1С:Предприятие 8", избежав подводные камни, которые не описаны в официальной документации.
Необходимые компоненты для установки
СУБД PostgreSQL распространяется бесплатно и входит в комплект поставки сервера приложений "1С". Сервер приложений "1С:Предприятие 8" поставляется в двух вариантах: 32-разрядный и 64-разрядный. Postgre может работать с обоими.
Итак, имеем на руках дистрибутивы:
- Postgre: postgresql-9_1_2-1_1Cx64.zip, любезно предоставленный фирмой "1С".
- Дистрибутив сервера приложений "1С:Предприятие" для Windows x64, версии 8.2.16.368.
Казалось бы, чего проще - запусти и установится. Легко! Но установка в стандартном режиме даст одно небольшое ограничение: кластер у нас будут лежать в папке "Program Files". Не всем это понравится. Рассмотрим два варианта установки, простой и расширенный.
Статья разбита на 5 разделов:
1) Установка сервера 1C.
2) Установка PostgreSQL в стандартном виде, достаточном для запуска 1С без дополнительных настроек.
3) Установка PostgreSQL с выбором папки хранения кластера.
4) Создание новой информационной базы 1С.
5) Указание папки хранения файлов базы данных на сервере СУБД.
Перед установкой обязательно прочитайте всю статью целиком!
Установка сервера приложений 1С
Запускаем setup.exe из папки с дистрибутивом сервера 1С.
В том случае, если вы установите сервер приложений не как сервис, нужно будет вручную его запускать каждый раз. Требуется такой вариант редко. Устанавливаем как службу (сервис), и решаем, под каким пользователем он будет запускаться. Из соображений безопасности лучше создать отдельного пользователя USR1CV82, а не разрешать сервису работать под полными правами.
После установки сервера приложений система предложит установить драйвер ключа защиты HASP. Соглашаемся:
Дожидаемся сообщения:
Если сообщение будет другим, в системе, скорее всего, остались "хвосты" от предыдущих установок драйверов HASP. Удаляйте их все, и пробуйте заново.
Готово, сервер приложений "1С:Предприятие 8" мы установили успешно.
Установка PostgreSQL в стандартном виде, достаточном для запуска 1С без дополнительных настроек
Запускаем "postgresql-9.1.2-1.1C(x64).msi"
Опции установки можно не менять, 1С работать будет. Далее.
Postgre, как и сервер 1С, может сам создать пользователя, под которым будете запускаться служба. Обращаю ваше внимание на то, что если указать учетную запись с правами администратора, то служба корректно работать не будет. Обязательно создавайте нового пользователя.
Следующее окно установки.
Инициализируем кластер. Если у нас сервер баз данных и сервер приложений 1С находятся на разных компьютерах, тогда устанавливаем галочку «Поодерживать подсоединения с любых IP», иначе не трогаем. Обязательно указываем кодировку UTF8. Создаем суперпользователя СУБД. Далее…
Для начальной работы нам ничего дополнительного не нужно, снимаем галочку, завершаем установку.
Результат наших усилий - готовый к работе PostgreSQL. Если нас устраивает, что базы будут лежать в Program Files\PostgreSQL\9.1.2-1.1C\data - заканчиваем на этом, раскрываем базы и наслаждаемся процессом. Однако, чаще все-таки базы данных "лежат" на специально предназначенных для этого дисковых массивах, а не на системном диске. Для того, чтобы настроить расположение данных, перед установкой прочитайте следующий раздел.
Установка Postgre с выбором места хранения кластера
Приступаем к установки Postgre и выполняем все шаги до тех пор, пока нам не предложат инициализировать кластер:
Снимаем галочку "Инициализировать кластер базы данных" и нажимаем "Далее".
Да, уверены.
Снимаем галочку "По выходу запустить Stack Builder" и завершаем установку.
1. Необходимо выдать полные права на папку в которую мы установили PostgreSQL, обычно это C:\Program Files\PostgreSQL
2. Из под админских прав запускаем cmd. Если это делаете в win7, то запускаем от Администратора.
3. Создаем папку где будет храниться кластер. Например d:\postgredata.
md d:\postgredata
4. Проводим инициализацию кластера вручную с указанием пути где он будет находиться.
“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\initdb.exe” -D d:\postgredata --locale=Russian_Russia --encoding=UTF8 -U postgres
5. Удаляем службу PostgreSQL, которая была установлена в ходе установки.
sc delete pgsql-9.1.2-1.1C-x64
Где pgsql-9.1.2-1.1C-x64 - Это название службы. Если не знаете название точно, можно посмотреть свойствах службы “PostgreSQL Database Server…” (Пуск – Панель управления – Администрирование – Службы)
6. Создаем новый сервис с указанием нашего кластера
“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl” register -N pgsql -U postgresql -P пароль -D d:/postgredata
7. Теперь заходим в службы. Пуск – Панель управления – Администрирование – Службы и стартуем нашу службу.
Создание новой базы данных 1С на сервере с PostgreSQL
Есть несколько вариантов создания базы данных. Можно попробовать создавать базу через pgAdmin3, консоль администрирования серверов 1С. Но тут вы столкнетесь с массой непонятных вопросов и кучей ошибок, ответы на которые будете долго искать. Оставьте это для специалистов. Наша задача получить работоспособную базу с минимальными усилиями. Опишем самый простой путь добиться этого.
Запускаем клиент 1С.
Нажимаем "Добавить...".
Придумываем название базы, указываем "На сервере 1С:Предприятия", далее.
Кластер серверов 1С:Предприятия – localhost, если мы создаем базу на том же компьютере, где установлен сервер 1С, или имя сервера приложений 1С, если на другом.
Имя информационной базы в кластере - в дальнейшем это название будет указываться при подключении с других компьютеров.
Тип СУБД – Выбираем PostgreSQL.
Сервер баз данных - указываем название сервера PostgreSQL. Если создаем базу на сервере, так же указываем localhost.
Имя базы данных – с таким название будет создана база в PostgreSQL.
Пользователь, пароль – имя пользователя, которого мы указывали как суперпользователя при установке PostgreSQL. Обязательно поднимаем галочку "Создать базу данных в случае ее отсутствия".
Возникает вопрос - а где база будет храниться физически? В папке Base указанного кластера. А если мы не хотим, чтоб она лежала там, где лежат все базы? Тут пока ничего поделать нельзя, просто создаем базу и двигаемся дальше. Далее…
Указание папки хранения базы данных
Итак, мы создали базу. В большинстве случаев на этом установка заканчивается. Однако, если баз много, и есть несколько дисковых массивов для разных групп баз, нужно указать, где физически должны располагаться базы. Чтобы сделать это, запускаем pgAdmin3 из Пуск – Программы – PostgreSQL. Подключаемся к нашему серверу.
При первом подключении Postgre попросит пароль для пользователя postgres (которого мы создавали при установке).
Создаем новый TableSpace, это будет та папка, в которой будут храниться наши базы.
Указали место хранения файлов базы. Ок.
Теперь открываем свойства уже созданной ранее базы данных, размещение которой мы хотим изменить.
Меняем свойство Tablespace. После нажатия "ОК" файлы базы данных будут автоматически перемещены. Готово! Надеемся, что статья была вам полезна. Если это так - оставляйте комментарии, делитесь ссылками на эту страницу. Спасибо!