PostgreSQL 10.4 для 1С


#1

так - дошли руки до докера 10-ки, с мест сообщают что уже 2 месяца не могут собрать контейнер с 10-кой на борту

докладываю

Установка

  • изменились имена пакетов - полный список тут http://repo.postgrespro.ru/1c-archive/meta.json
  • изменилось место установки - теперь это /opt/pgpro/1c-10/bin/ - теперь никакого /etc
  • включен режиме “альтернатив в ubuntu” - то есть теперь симлинки создаются сами, нет нужды содавать символические ссылки на дистрибутив для 1С

Сборка расширений из исходников

  • установка пакета для сборки из исходников dev который не добавляет команды pg_config в нужное место :wink: приходится явно делать
RUN ln -s /opt/pgpro/1c-10/bin/pg_config /usr/bin/pg_config 

Расширение https://github.com/reorg/pg_repack - не собирается под 10-ку от PG.PRO по причине того что где-то в глубинах есть зависимость от -lib=systemd которую пока починить ну удалось (что жаль - хорошее расширение)

Основной дистрибутив

пришлось мигрировать на https://hub.docker.com/r/library/ubuntu/tags/bionic/ 18-04 имеет 6 уязвимостей в противовес https://hub.docker.com/r/library/ubuntu/tags/14.04/ на котором основывались ранее

но это еще не все https://github.com/sameersbn/docker-postgresql/pulse/monthly

обратите внимание автор Gitlab Docker скажем так подзабил на развитие контейнера с PG

если кстати посмотреть на https://github.com/sameersbn/docker-gitlab/pulse/monthly
то можно увидеть что развитием docker-gitlab занимается совершенно другой человек и вообще сообщество

Переменные окружения

так как установка проходит в opt поменялось и установка в /var/lib/`

ENV PG_APP_HOME="/etc/docker-postgresql"\
    PG_VERSION=1c-10 \
    PG_USER=postgres \
    PG_HOME=/var/lib/pgpro/${PG_VERSION} \
    PG_RUNDIR=/run/postgresql \
    PG_LOGDIR=/var/log/postgresql \
    PG_CERTDIR=/etc/postgresql/certs

ENV PG_BINDIR=/opt/pgpro/${PG_VERSION}/bin \
    PG_DATADIR=${PG_HOME}/${PG_VERSION}/data \
    PG_WAL=${PG_HOME}/pg_xlog \
    PG_TEMPTBLSPC=${PG_HOME}/temptblspc \
    PG_V81C_DATA=${PG_HOME}/v81c_data \
    PG_V81C_INDEX=${PG_HOME}/v81c_index 

симлинки в /etc/ больше не нужны - все делает инсталятор сам от PostgreSQL.Pro

И в итоге - 10-ка работает

P.S. Знающие люди - знают где искать commit с исправлением :wink:


Пропала организация из github
#2

Забыл еще одно - по совету отсюда https://postgres.ru/t/ustanovka-versii-9-x-na-slishkom-novye-apt-based-distributivy/129

заменить приорите на установку пакетов - чтобы конфликтов не было

Package: postgrespro* libpq* libecpg* libpqtypes*
Pin: origin *.postgrespro.ru
Pin-Priority: 1001


#3

если кто не в курсе - то это в рамках вот этой активности https://silverbulleters.org/1c-mssql-to-pg


#4

/me ушел грустить по поводу своих компетенций в Posgres


#5

Именно из-за отсутствия достаточного количества спецов с компетенциями возникают сложности: Миграцию и разворачивание автоматизировал, все в один клик (откуда, куда, кто), но потом (слава богу до прода) не оказалось спецов, в нужном количестве.


#6

/me пошел следом за @EvilBeaver


#7

Тема очень интересна. Хотелось бы услышать мнение по поводу развертывания на Win/Lin.
Причем очень интересно сравнение производительности СУБД Postgres при расположении в СХД и локально на сервере. Есть ли смысл мигрировать с MSSQL на Postgres при использовании ERP или лучше не рисковать, т.к. подводных камней достаточно много?


#8

Лучше собрать из исходников + патчи от 1С или же лучше использовать готовые “пропатченные” сборки?


#9

“на некоторых профилях нагрузки 1С может наблюдаться производительность лучше на 20%-40-60% чем у MSSQL” - хотелось бы понять что за профили, цифра 40% очень заманчивая и очень хотелось бы ее достигнуть. Есть ли такие профили в ERP ?


#10

Мы рекомендуем 1С сервер (Windows) + PG (Linux).
ключевой момент в этом - НЕ все расширения на Си собираются штатно под Windows.

Есть точно, но выбор базы обусловлен только внутренней компетенцией - например мне ERP не страшно мигрировать, потому что там нет подводных камней, есть просто процесс настройки ну и мониторинга: рутина DBA в общем. Если выбирается первая база для миграции и в первый раз - то лучше менее критичную смигрировать. Например БП 3.0 :wink:

Нет - лучше брать сборку от PG.Pro

СКД почти вся, запросы ЗУПа составные, времянки и прямое управление блокировками. Тут же нет никакой магии почему так происходит - влияют 3 фишки основные

  • версионник
  • сжатие на простых типах данных
  • параллельные планы запросов

Так что в ERP у тебя такие профили есть и много.


#11

А еще постгря меньше прощает. Запросы надо писать головой. На самом деле оптимизатор в постгре очень хороший, понятно что делает и как делает и зачем делает. А в MSSQL сука какой-то магический. Даже говнозапросы в ~70% умудряется выполнить сносно. Ладно постргрес, но даже дорогущий Oracle при малейшем “шаг влево-шаг-вправо” умирает на хреновом плане запроса. А MSSQL работает.

Вывод: MSSQL позволяет не думать головой, оптимизатор вывезет с высокой долей вероятности. Но если писать запрос сразу прикидывая план - то постгрес отлично работает.

У нас эксплуатировалась 24/7 база хелпдеска федеральная на постгресе. Документы льются рекой, даже не ожидал. Сначала умирала, потом после оптимизации запросов и части метаданных стала практически беспроблемной.

@theshadowco по поводу компетенций: тонкого тюнинга на уровне конфигов и плагинов не потребовалось. Техжурнал, планы запросов, мозги. Так что мегакомпетенций особо и не надо.


#12

ты еще версию вспомни ;-). Она была далеко не 10.4 - сейчас при переходе на 10.4 становится еще быстрей и интересней


#13

@EvilBeaver
Проблема в компетенциях в том, что мы сами то были не супер гуру, а вот клиент вообще не обладал своими спецами, брать или аутсорсить не хотел.

А так да, тюнить не приходилось, все настраивали по манам от постгреспро и 1С


#14

Мы наконец-то сделали вот так развертывание, обновления.

Достаточно развернуть docker инфраструктуру по нашей инструкции и иметь логин пароль к нашему ГИТу. Всё разворачивается в несколько кнопок.


#15

Почему руками? Где

ansible-playbook -i inventories/dev/hosts postgres.yml --vault-password-file=/tmp/mypipeansible

#16

Имхо, ансиблы пишутся, когда понятно - что именно настроить. А это понимание приходит только после протыкивания ручками


#17

всем подавай мышку - не захотели клиенты ansible хотя он есть