Pull to refresh

Comments 22

Скитания «инженера со счастливым концом» — это пять!!! :)

Немного юмора никогда еще не вредило )

Вспоминается... для счастливого начала сводите девушку в кафе, а для счастливого конца купите презерватив.

Круто что разобрались. Плюсанул конечно.

ИМХО для 1С скорее важно архивирование, чтобы откатиться если косякнут пользователи, но не знаю какое у вас SLA, тогда надо и кластера 1С поднимать.
Что касается

Рекомендуем ознакомиться со статьёй https://postgrespro.ru/docs/postgrespro/14/config-one-c и выставить параметры в соответствии с указанными там.

online_analyze.table_type = 'temporary'

Тоже всегда так делал, пока мне не рассказали и сам не проверил по тж - последняя платформа 1С дает команду analyze самостоятельно при создании временных таблиц.

Я не знаю встречаются ли разработчики платформы и постгрес про, но получается нет смысла в этом расширении.

Да, но огромное количество компаний работают на далеко не самых новых версиях платформы, так что этот совет будет актуален еще 3-5 лет думаю

Мы же на техническом сайте, давайте фразы огромное количество, подавляющее большинство и в едином строю оставим другим ресурсам.
Для всех типовых конфигураций есть минимальная версия платформы на которой они запустятся MinAppVersion.txt.

Вот из ЗУП пример
Версия 3.1.17 предназначена для использования с версией платформы 8.3.16.1814 (и более поздних 8.3.16), 8.3.17.1851 (и более поздних 8.3.17), или 8.3.18.1289 (и более поздних).

А вот из бухгалтерии

Текущая версия конфигурации "Бухгалтерия предприятия" предназначена
для использования с версией системы 1С:Предприятие 8.3 не ниже 8.3.17.1851, 8.3.18.1741, 8.3.19.1467.

Рекомендуется использовать версию 1С:Предприятие 8.3 не ниже 8.3.18.1741.

Хорошо, это технический сайт. Я переформулирую - по моему личному опыту в проде все еще много старых платформ.

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

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

Я к этому и веду. Что все кто используют ЗУП (читайте все у кого больше 20 сотрудников) обновляют платформу регулярно.

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

А их, по моему мнению, сильно больше чем ЗУП/Бух

Вы под них держите особую старую платформу?

Тоже всегда так делал, пока мне не рассказали и сам не проверил по тж - последняя платформа 1С дает команду analyze самостоятельно при создании временных таблиц.

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

Нигде тут не нашел упоминания что такое "последняя платформа", просьба указать версию(Например (8.3.17.2316) (z) ), где вы проверяли такое поведение платформы.

Да, ваше замечание принимается полностью, в последних версиях платформы точно, но если конкретно, то например 8.3.20.1674

Проверить легко, нужно настроить технологический журнал на событие DBPOSTGRS в нем можно будет увидеть Sql=ANALYZE pg_temp

И что еще загадочнее SET enable_mergejoin=off

А вы как-то решили проблему с тем, что в случае выхода узла кластера из строя, или новый инстанс инициализируется путём снятия резервной копии с мастера и это pg_basebackup, что в случае большой базы может привести к неприятным эффектам? pg_auto_failover в отличие от patroni не умеет автоматически создавать реплики из последнего актуального бекапа не нагружая при этом мастер.

Я не очень понял вопрос если честно, но попытаюсь ответить. Основная решаемая задача - это высокодоступное решение. Соответственно, если мастер-нода падает - ее подменяет слейв-нода, на время пока чиним старую мастер-ноду. Тут все стандартно.

Да все в порядке, я понял ваш подход, который в целом верный, есть автоматический фейловер, а чинить зовём инженера, который работает руками. Для 1-10 кластеров это приемлемо. Но когда их 100+ уже затруднительно. Спасибо вам за статью. Действительно для PostgresPro его нужно пересобирать, благо разработчик любезно предоставляет для таких целей дев пакеты. Pg_auto_failover вполне пригодное решение, особенно мне нравится монитор, который, будучи один, может обслуживать довольно много кластеров.

Вы молодец! Что удивительно, за долгие годы развития русских «облаков» никто так и не вышел с доступным по стоимости решением для managed базы 1С

Ну ладно, может и есть доступные, но ценники конские все равно

насколько я знаю в Selectel сделали такую историю. не смотрели у них?

У себя в компании мы собираем собственный deb-пакет, кладем его в локальную репу и катим ансиблом. Но тут была задача рассказать как это можно сделать в базовом варианте. Мануалов как это сделать мы так и не нашли (под наш набор утилит)

Выучите уже ansible и пишите роли. Будет на порядок полезнее и откроете для себя новый дивный мир galaxy. узнаете, что вот это вот всё там уже давно есть и куда более отлаженное и испробованное тысячами людей.

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

Во-вторых, далеко не всем нужен такой инструмент как Ansible. Есть достаточное количество компаний где в принципе 1-2 БД развернуто. Они потратят на порядок больше времени на освоение инструмента, который им нужен будет один раз в год, а то меньше.

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

Когда обращаюсь к опубликованной через web БД 1с (прописывая ip и имя БД) получаю ошибку что сервер 1c-psql этот хост неизвестен, прописывание этого хоста в hosts проблему решает, но где поменять имя на ip чтоб не пришлось всем прописывать?

Спасибо

Sign up to leave a comment.

Articles