Комментарии 22
Немного юмора никогда еще не вредило )
Вспоминается... для счастливого начала сводите девушку в кафе, а для счастливого конца купите презерватив.
Круто что разобрались. Плюсанул конечно.
ИМХО для 1С скорее важно архивирование, чтобы откатиться если косякнут пользователи, но не знаю какое у вас SLA, тогда надо и кластера 1С поднимать.
Что касается
Рекомендуем ознакомиться со статьёй https://postgrespro.ru/docs/postgrespro/14/config-one-c и выставить параметры в соответствии с указанными там.
online_analyze.table_type = 'temporary'
Тоже всегда так делал, пока мне не рассказали и сам не проверил по тж - последняя платформа 1С дает команду analyze самостоятельно при создании временных таблиц.
Я не знаю встречаются ли разработчики платформы и постгрес про, но получается нет смысла в этом расширении.
План перехода на PostgreSQL. Подводные камни и отказоустойчивость - 1C-RarusTechDay 2020
нашел ссылку в своих записях
Да, но огромное количество компаний работают на далеко не самых новых версиях платформы, так что этот совет будет актуален еще 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) ), где вы проверяли такое поведение платформы.
А вы как-то решили проблему с тем, что в случае выхода узла кластера из строя, или новый инстанс инициализируется путём снятия резервной копии с мастера и это pg_basebackup, что в случае большой базы может привести к неприятным эффектам? pg_auto_failover в отличие от patroni не умеет автоматически создавать реплики из последнего актуального бекапа не нагружая при этом мастер.
Я не очень понял вопрос если честно, но попытаюсь ответить. Основная решаемая задача - это высокодоступное решение. Соответственно, если мастер-нода падает - ее подменяет слейв-нода, на время пока чиним старую мастер-ноду. Тут все стандартно.
Да все в порядке, я понял ваш подход, который в целом верный, есть автоматический фейловер, а чинить зовём инженера, который работает руками. Для 1-10 кластеров это приемлемо. Но когда их 100+ уже затруднительно. Спасибо вам за статью. Действительно для PostgresPro его нужно пересобирать, благо разработчик любезно предоставляет для таких целей дев пакеты. Pg_auto_failover вполне пригодное решение, особенно мне нравится монитор, который, будучи один, может обслуживать довольно много кластеров.
Вы молодец! Что удивительно, за долгие годы развития русских «облаков» никто так и не вышел с доступным по стоимости решением для managed базы 1С
Ну ладно, может и есть доступные, но ценники конские все равно
К слову PostgresPro автоматизировать развертывание кластеров тоже умеем - https://github.com/vitabaks/postgresql_cluster/issues/38
Выучите уже ansible и пишите роли. Будет на порядок полезнее и откроете для себя новый дивный мир galaxy. узнаете, что вот это вот всё там уже давно есть и куда более отлаженное и испробованное тысячами людей.
Во-первых, я бы хотел обратить ваше внимание на мое сообщение буквально сразу же над вашим. Там описан как сделано у нас.
Во-вторых, далеко не всем нужен такой инструмент как Ansible. Есть достаточное количество компаний где в принципе 1-2 БД развернуто. Они потратят на порядок больше времени на освоение инструмента, который им нужен будет один раз в год, а то меньше.
В-третьих, хочу обратить ваше внимание, что ваша последняя статья тоже рассказывает про достаточно базовые вещи и там тоже нет упоминания про Ansible. Мне кажется что не совсем красиво упрекать других в том, что делаешь сам.
Когда обращаюсь к опубликованной через web БД 1с (прописывая ip и имя БД) получаю ошибку что сервер 1c-psql этот хост неизвестен, прописывание этого хоста в hosts проблему решает, но где поменять имя на ip чтоб не пришлось всем прописывать?
Спасибо
Кластер Postgres для 1С. Повествование об интеллектуальных скитаниях инженера со счастливым концом