Переключились на использование readonly-реплик ( Сервер ЛЭРС УЧЁТ | Документация ЛЭРС УЧЁТ ). В среднем 5% нагрузки на CPU с основного сервера переместилась на readonly-реплики.
Предложения:
Исправить документацию - вместо LERS_SERVER_ConnectionStrings__Default и LERS_SERVER_ConnectionStrings__ReadOnly сейчас работает только ConnectionStrings__Default и ConnectionStrings__ReadOnly соответственно.
Из документации не понятно как в случае с репликами поступать с переменной LERS_SERVER_DATABASE__ConnectionString. Нужно ли ее оставлять при задании ConnectionStrings__Default?
Со стороны пользователя логичнее бы было оставить переменную LERS_SERVER_DATABASE__ConnectionString и, например, при добавлении переменной LERS_SERVER_DATABASE__ConnectionString__ReadOnly - переключится на использование реплик.
Т.е. если задана одна переменная LERS_SERVER_DATABASE__ConnectionString - использовать обычный режим работы. А если заданы две переменные: LERS_SERVER_DATABASE__ConnectionString и LERS_SERVER_DATABASE__ConnectionString__ReadOnly - использовать режим работы с репликами.
По 1 пункту понятно, в документации есть недоработки, исправим.
Думаю, что достаточно просто дописать, что при работе с репликами она не используется. Этот параметр мы считаем устаревшим, хотя и убирать не планируем. В принципе можно использовать только ConnectionStrings__Default и добавить ConnectionStrings_ReadOnly если используются реплики.
Там мы описываем больше параметры бизнес-логики сервера (расчёт, опрос, и так далее), а не способы его запуска.
А вы это написали, потому что столкнулись с такой необходимостью? Или это просто пожелание, а фактически для windows такую настройку вы не делали?
Наш пользовательский опыт (DX):
Системный администратор. Задача - установить отказоустойчивый сервер под высокую нагрузку.
Захожу в руководство пользователя - вижу раздел установка и настройка.
Прохожу раздел “Установка в docker”. Далее - “Установка ЛЭРС УЧЁТ и сервера баз данных”, далее Postgresql.
Качаю compose.yml. Вижу, что подключение возможно только с указанием адреса сервера (без реплики). (При тестовой установке через скрипт )
Захожу в Установка и настройка Postgresql - там почему-то тоже описан способ установки Postgresql, но уже не через docker (про реплики - ни слова).
Иду в расширенную конфигурацию сервера - там подробно описываются переменные окружения и Lers.Server.xml, но нет LERS_SERVER_DATABASE__ConnectionString, описываемого в документации по установке и в compose.yml. (про реплики также ни слова).
То, что надо идти в Компоненты - Сервер и там смотреть то, как настроить подключение к postgresql с репликами показалось не очевидным.
Если посмотреть шире на примере нашей компании, то есть разделение:
системный администратор(DEVOPS): он устанавливает, настраивает сервера, сеть, БД, бэкапы и т.д
администратор системы: он разбирается в приборах учета, модемах и т.д. Какие-то узлы добавляет сам, следит за опросами формирует требования к настройке модемов.
Соответственно сисадмину хорошо бы понимать какие сервисы как установить, настроить, обновлять и бэкапить. Он работает с системами управления конфигурациями - поэтому делает все через переменные окружения и конфиг-файлы. Желательно иметь возможность посмотреть где-то что значит тот или иной параметр в конфиг-файле. Сейчас приходится прыгать с раздела “Установка и настройка” в “Компоненты” и “Администрирование”.
Администратор системы и пользователи - работают уже в интерфейсе программы - настраивает группы, добавляет пользователей, следит за службами опроса и т.д. Сейчас разделы дублируются и не всегда интуитивно их расположение - например “Опрос” есть как в корневом разделе, так и в “WEB интерфейсе”, а “Объекты учета” описываются в разделе “Рабочее место оператора” и в “WEB интерфейсе”. Часть информация касающаяся работы в Web-интерфейсе расположена в корневом Опросе.
Поэтому предлагаю:
описать полностью все возможные переменные окружения в одном месте.
структурировать документацию по ролям — блок для devops (установка, настройка сервисов и баз данных, бэкапов, обновления), блок для администраторов (пользователи, роли, службы опроса, системные параметры, модули) и пользователей системы (узлы учета и точки учета, опрос, отчеты, просмотр данных). Особенности работы в различных интерфейсах(web и АРМ) - описывать уже внутри каждого раздела.