1️⃣🔤 "Падение" кластера 1С из-за лицензии разработчика

Недавно в рамках РКЛ разбирали очень интересную ситуацию.

Кластер 1С состоит из трёх серверов:
▫️Server1 - Центральный сервер (ТНФ отсутствуют)
▫️Server2 - Рабочий сервер (ТНФ: Клиентские соединения - Авто, Для всех - Не назначать)
▫️ServerLic - Рабочий сервер (ТНФ: Сервис лицензирования - Назначать, Для всех - Не назначать). На этом сервере активированы обе серверные лицензии 1С (для Server1 и Server2) и какое-то количество клиентских лицензий 1С.

Ожидаемое поведение кластера 1С:
Клиентские соединения равномерно (по производительности серверов 1С) распределяются по серверам 1С.

❗️Всё именно так и работало долго и успешно, но в один "прекрасный" момент соединения перестали назначаться на Server2 и все пользователи работали только на Server1

В консоли администрирования было видно что рабочий процесс Server2 не имел лицензии.
Сначала казалось что проблема именно в этом, было идея что серверную лицензию Server2 занял какой-то другой кластер.
Подробно я разбирал это здесь: https://news.1rj.ru/str/explorer1c/21
Анализ показал что это не так и лицензию никто не занимает.

Ок, решили тогда попробовать удалить Server2 из кластера и добавить заново...
Вот тут то мы и получили ошибку со скриншота,

Ошибка регистрации рабочего сервера в кластере:
Ошибка операции администрирования
Лицензия для разработчиков позволяет использовать только один рабочий в кластере...

Казалось бы - фигня делов, сейчас исправим! Мы же знаем где хранятся файлы программных лицензий!

Не тут то было, ни в одном из каталогов хранения программных лицензий никаких лицензий разработчиков не оказалось.
Поиск файлов по всей системе по маске *.lic выдал только 3 файла на сервере ServerLic:
▫️Серверная лицензия для Server1
▫️Серверная лицензия для Server2
▫️Клиентская лицензия на 500 пользователей

Что делать когда предыдущий опыт не помогает?
ВЕРНО! Читать ИТС!!!
Но и там не оказалось ничего про то где и как хранится лицензия для разработчиков...

Опытным путём, а именно пересобиранием кластера было выяснено что лицензия разработчика активирована именно на Server2.

❗️В итоге попробовали на Server2 переименовать каталог reg_1541 (каталог кластера 1С) и о чудо всё заработало, кластер собрался без ошибок!

Пошли выяснять дальше, оказалось что лицензия разработчика хранится в каталоге сеансовых данных сервера 1С. Достаточно почистить этот каталог и проблема вместе с лицензией разработчика исчезает.
Это было очень неожиданно!

❗️И теперь самое важное: пока не просматривается сценария защиты на уровне платформы от этого, так как активировать лицензию можно не только из Конфигуратора, но и из пользовательского режима...
Достаточно при активации просто выбрать в пункте "Дополнительно" сервер кластера 1С.

❗️❗️❗️Что мы можем сделать чтобы всё таки уменьшить вероятность:
▫️Закрыть доступ по TCP опубликовав базу по https и настроить сетевой экран на серверах 1С на запрет доступа по портам 1540,1541,1560-1591 (по умолчанию) всем кроме серверов 1С кластера 1С и web-сервера с публикацией 1С.
▫️Написать и применить расширение, блокирующее пункт в меню "Получение лицензии".
▫️Остаётся конфигуратор - тут только знание, что не надо на продовых кластерах и базах пытаться активировать лицензию разработчика.

1️⃣🔤 Во время выполнения действия была потеряна связь с сервером...

Достаточно давно, периодически (естественно почти не подтверждаемая на тестах) как у наших клиентов РКЛ так и у клиентов нашего Облака стала возникать ошибка как на скриншоте.
Причём возникает она просто при работе клиента с 1С ни с того ни с сего.

В результате попыток понять что-же это за проблема было обнаружено два момента:
▫️Ошибка возникает только при работе с базами по http/https, по TCP всё хорошо
▫️Ошибка возникает только если обращение к базе 1С идёт через NGINX, если работать напрямую с apache/iis, то всё хорошо

Ок, определили что с NGINX что-то не так.
Но как всегда, до этого же всё работало!)))
Поэтому сильно хочется начать поиски ключа там где светло, а не там где потерял ключ...

Включаем лог ошибок в NGINX

в файл nginx.conf вверху добавляем строку:
error_log /var/log/nginx/error.log error;
nginx -t (проверить корректность настройки)
nginx -s reload (перечитываем настройки)

В лог ошибок во время получения ошибки пользователем в 1С фиксируется запись:

[error] 3408371#3408371: *954123377 upstream timed out (110: Connection timed out) while reading response header from upstream, client:

Т.е. у нас срабатывает таймаут чтения ответа от проксируемого сервера...

Ок, идём на итс и смотрим какие настройки таймаутов рекомендует 1С и там видим рекомендацию:

proxy_read_timeout 300s;

Но проблема в том, что у нас в настройках уже есть этот параметр и более того он выставлен в значение 3600s, что больше чем рекомендуемое в 20 раз.

Ок, может мы чего-то не понимаем, ставим 300s.
Ситуация поменялась, но уже в части другого.
Ошибок у пользователей осталось как было, а вот других записей в лог ошибок NGINX резко прибавилось:

connect() failed (110: Connection timed out) while connecting to upstream, client:

Вернули параметр в 3600s, всё стало как прежде.

Ну и если честно, то тут прям взяли грех на душу и посчитали что во всём виновато обновление на платформу 1С 8.3.27, так как вроде бы обращения пользователей коррелируют с временем обновления.

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

Так в расстройстве прошло какое-то время, но червячок всё таки грыз понемногу - что ну не может такого быть!)))

Поиск в интернете по ошибке "upstream timed out (110: Connection timed out) while reading response header from upstream," всё равно приводил к параметру proxy_read_timeout, что нам не помогало...

И только в одном из форумов был намёк "попробуйте установить значение параметра "proxy_send_timeout" в больше чем по умолчанию (60s)

Ну когда ничего не остаётся надо идти читать документацию)))
▫️proxy_read_timeout - Задаёт таймаут при чтении ответа проксированного сервера.
▫️proxy_send_timeout - Задаёт таймаут при передаче запроса проксированному серверу

Ну и опять же, вроде мы не тупим - ошибка "while reading response header from upstream" как раз про чтение ответа, а это параметр proxy_read_timeout.
Опять тупик...

С другой стороны, вроде бы нам ничего не мешает установить и значение параметра proxy_send_timeout в 3600s.

Делаем, и вуаля!!!
Ошибки исчезли!

Вот так разное описание параметра в документации и реакции сервера на этот параметр в логе привело в нескольким неделям блужданий в темноте...

❗️Так что если у вас наблюдается ошибка потери связи и при этом у вас есть NGINX, то попробуйте установить параметр proxy_send_timeout в значение 3600s.

🔤🔤🔤 Резервное копирование в PostgreSQL и его мифы

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

Заблуждение № 1:
Резервная копия PostgreSQL будет настоящей только если выгнать всех пользователей из базы 1С и заблокировать базу.

Заблуждение № 2:
Резервное копирование PostgreSQL это только Dump.

Заблуждение № 3:
Резервное копирование PostgreSQL это только весь сервер с помощью basebackup, а базу отдельно забэкапить невозможно.

Заблуждение № 4:
Резервная копия PostgreSQL не имеет обратной совместимости, т.е. копия сделанная на версии 14 не сможет быть восстановлена на версии 15 и новее (сейчас есть уже 18).

Заблуждение № 5:
Резервная копия PostgreSQL может быть только полной и не умеет делать дифференциальные или инкрементные копии.

Как обстоят дела на самом деле:
Резервная копия (бэкап) субд PostgreSQL является что ни на есть настоящей и консистентной даже если сделана во время работы базы и не требует ни отсутствия пользователей в 1С ни блокировки базы.
В отличии от MS SQL где есть только один вид резервного копирования, PostgreSQL имеет два основных вида:
▫️PG_Dump
▫️PG_BaseBackup

В чём их особенности:
PG_Dump - это логическое чтение всех данных со всех таблиц базы данных.
В следствии этого копия созданная утилитой pg_dump консистентна на начало копирования (в отличии от MS SQL, резервная копия которого консистентна на момент окончания копирования).
Так же pg_dump поскольку является по факту просто запросом select с выводом в файл имеет много гибких настроек.
Можно исключить определенные таблицы из копии (очень полезно при создании копии для среды разработки и тестирования, например можно выкинуть иэ бэкапа таблицу истории данных или версионирования данных)
Так же dump не содержит индексов, а содержит только команды их создания. Из-за этого бэкап сделанный с помощью dump занимает намного меньше места чем копия созданная на СУБД MS SQL, которая как раз таки содержит и индексы.
Копия созданная утилитой pg_dump имеет обратную совместимость, т.е. нет никаких проблем в том чтобы создать копию на версии 14 и восстановить её на версии 17.
Единственный нюанс состоит в том, что использовать утилиту восстановления pg_restore нужно в этом случае именно версии 17.

Это ещё не всё про pg_dump)))
Формат резервной копии этой утилиты может быть трёх видов:
▫️-Fp - plain
▫️-Fc - custom
▫️-Fd - directory

Plain - просто текстовый формат, выходной файл будет состоять из команд insert.
Особенность в том что этот формат однопоточный, НО можно немного схитрить и отправить результат команды не в файл, а в поток, а этот поток уже многопоточно сжать через pigz для windows или любого аналога для Linux и тем самым кратно ускорить создание резервной копии | c:\util\pigz\pigz.exe -p4
Плюсы - квазимногопоточность создания бэкапа
Минусы - восстановление только в один поток и предварительно необходимо распаковать файл резервной копии

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

Directory - бэкап на уровне каталога.
Особенность - гарантированно выполняется только на заблокированной базе, если же базу не блокировать, то возможно что система затребует блокировку таблицы, которую ещё не забэкапили и тогда pg_dump прервёт свою работу по ошибке.
Плюсы - многопоточное создание и восстановление. Не требует предварительной распаковки
Минусы - гарантированное выполнение только на заблокированной базе.

Особенности любых резервных копий, создаваемых через pg_dump:
Только полное резервное копирование, никаких дифференциальных и инкрементальных копий.
После восстановления из резервной копии необходимо выполнить операцию обновления статистики, благо в PostgreSQL она очень быстрая.
Проверки на валидность файла резервной копии не существует, контролировать нужно именно отсутствие ошибок при работе pg_dump.

Про особенности, плюсы и минусы pg_basebackup расскажу в следующий раз.

🔤🔤🔤 Резервное копирование в PostgreSQL и его мифы часть 2

В этой части поговорим про другой вид резервного копирования в PostgreSQL. а именно про pg_basebackup

Главное отличие от pg_dump состоит в том, что pg_basebackup это резервная копия всего сервера, а не отдельной базы.

Процесс создания резервной копии включает 3 этапа:
▫️Выполнение контрольной точки
▫️Копирование журналов транзакций (WAL)
▫️Копирование самих данных (каталог сервера СУБД)

Последние 2 этапа идут параллельно, и копирование журнала транзакций заканчивается сразу после того как закончилось копирование самих данных.
Таким образом резервная копия консистентна на момент окончания процедуры копирования.
Резервная копия pg_basebackup всегда идёт в 1 поток и содержит как данные так и индексы, так как является по факту копией каталога.
Резервная копия pg_basebackup не имеет обратной совместимости, т.е. копия созданная на версии 15 будет работать только с версией 15.

Начиная с 17-ой версии PostgreSQL pg_basebackup может быть как полным так и инкрементом.
Причём снятие инкремента сделано таким образом, что необходимо вручную указать от какой копии делать инкремент. Таким образом мы можем формировать как инкрементные копии от последней копии, так и дифференциальные копии от полной копии, выстраивая таким образом ваши сценарии резервного копирования.

Процесса восстановления из полной резервной копии pg_basebackup не существует, это просто сервер PostgreSQL готовый к старту и чтобы восстановить резервную копию достаточно стартануть СУБД с указанием каталога: pg_ctl start -D /backup/full_copy

Процесс же восстановления из полной копии плюс набор инкрементных включает в себя сначала сборку каталога кластера и затем уже старт PostgreSQL в этом каталоге: pg_combinebackup /backup/full1 /backup/inc1 -o backup/full_combined и затем уже старт: pg_ctl start -D /backup/full_copy

Как снять инкремент:
▫️В postgresql.conf установить wal_level =replica или logical, summarize_wal = on
▫️Также указать wal_summary_keep_time в минутах (по умолчанию 10 дней) - это параметр, отвечающий за то какой глубины вы сможете снимать копии
▫️Создаём полную копию pg_basebackup -D /backup/full1 (в каталоге копии помимо самой копии появится файл backup_manifest, содержащий информацию и контрольные суммы по всем файлам)
▫️Содаём инкремент указывая от какой копии этот инкремент pg_basebackup -D /backup/inc1 -i /backup/full1/backup_manifest

Так же в 17-ой версии появился инструмент проверки резервной копии: pg_verifybackup /backup/full1, НО процедура контроля, выполняемая утилитой pg_verifybackup не включает в себя все проверки, которые будет выполнять сервер, если его запустить с этой копией данных

Помимо "ванильных" средств резервного копирования существует так же несколько вариантов платных и бесплатных ПО со своими плюсами и особенностями.
Чуть позже расскажу про pgpro_backup. так как мы и используем именно это ПО и знаем как оно работает не по наслышке.

1️⃣🔤 Неправильные подходы к отказоустойчивости кластера 1С со стороны клиентского подключения

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

Сценарий будет очень простым: есть два боевых сервера 1С, оба центральные + сервер 1С с ТНФ - Сервис лицензирования - Назначать (будем называть его Сервером лицензирования, хоть это и неправильно), хотим из них сделать отказоустойчивый кластер 1С.
Уровень отказоустойчивости в кластере = 1.

▫️Первый вариант - DNS.
Берём и прописываем IP адреса обоих Центральных серверов 1С под одним DNS-именем.
Например: Server1c - 192.168.0.1, 192.168.0.2
И соответственно в стартере 1С прописываем: Srvr="server1c";Ref="erp";

Казалось бы - всё прекрасно, и действительно - всё работает!
НО, до того момента пока "живы" оба наших Центральных сервера 1С,
Когда же выйдет из строя или просто станет недоступен по сети один из серверов, то пользователи начнут в случайном порядке получать ошибки работы в 1С (кто в ней уже был) и ошибки входа в 1С.
Так как DNS не анализирует доступность IP адресов, а просто выдаёт их по запросу в случайном порядке, а операционная система берёт первый из выданных адресов и пытается обратиться по нему, не пытаясь перебирать эти адреса.

Таким образом этот подход не является методом организации отказоустойчивого кластера 1С. Несмотря на то, что сам кластер 1С продолжает при этом работать и полностью обеспечивать отказоустойчивость, только бестолку, так как половина пользователей не может зайти в 1С...

▫️Второй вариант - разные proxy (nginx, haproxy, citrix и т.д.).
Тут в целом очень похоже на первый вариант, но немного сложнее.
Сложность в том что proxy подменяют IP адреса наших Центральных серверов 1С своим IP адресом.
И мы получаем, что клиент 1С общается с сервером 1С не по прямому IP что помимо задержек в общении может приводить вообще к неработоспособности 1С с очень "волшебными" ошибками сетевой недоступности серверов 1С.

Основная мысль в том, что не надо ничем заменять встроенную в Лучшую в мире платформу 1С отказоустойчивость!

А как же тогда правильно делать отказоустойчивость со стороны клиентского подключения?

Всё очень просто - нужно в адресе базы указать два наших центральных сервера: Srvr="server1c-1,server1c-2";Ref="erp";
При такой настройке сам клиент 1С, будет им Тонкий или Толстый клиент, либо Веб-браузер обратится сначала к server1c-1 для подключения и если он недоступен, то к server1c-2.

❗️При этом это не означает, что теперь все клиенты будут работать на server1c-1, просто сами подключения будут приниматься этим сервером и дальше уже назначаться на рабочие сервера и процессы согласно механике кластера 1С.

Напоминаю, что резервная копия канала есть в MAX.

1️⃣🔤 По предыдущему посту поступил сразу от нескольких подписчиков вопрос:

При правильной настройке кластера у пользователей при входе в базу возникает сообщение "Информационная база была перемещена или восстановлена из резервной копии"

Да, верно, так написано БСП что там сверяется имя сервера 1С и если оно изменилось, то выдаётся такое сообщение.
При этом ещё и сами регламентные операции должны быть написаны по правилам БСП, чтобы эта обработка понимала какие опасные и их нужно выключить, а какие нет.

Но мало кто замечает что снизу справа есть кнопка Ещё, а там галка "Проверять имя сервера".
❗️Так вот, при работе в кластере с несколькими центральными серверами 1С эту галку нужно снять.

Хорошо, сделали, но тогда возникает следующий вопрос: Что делать когда мы действительно восстановили базу в тестовую среду или среду разработки?
Ведь теперь у нас не будет задан такой вопрос и мы не отключим опасные регламенты!

Отвечаю: на средах разработки и тестирования, да и вообще при любом случае создания копии рабочей базы, она должна быть зарегистрирована в кластере 1С с установленной в ОБЯЗАТЕЛЬНОМ порядке галкой "Блокировка регламентных заданий включена" в свойствах базы в кластере 1С.

В 99,9% сценариев работы с копией рабочей базы регламенты не нужны.
Так как даже для проверки работы регламента достаточно просто запустить его по кнопке "Выполнить".

Ну а если всё таки вам необходимо какие-то из них включить, то сначала нужно в самой базе выключить все ненужные регламенты, оставить только нужные.
Затем из нужных надо отключить опасные, которые являются заданиями интеграции.
Проанализировать эти опасные операции, поменять все адреса на тестовые и только потом включить обратно это регламентное.
❗️И после того как вы точно уверены что с этой копии базы никакие данные никуда не полетят в ненужном направлении можно снять в свойствах базы галку "Блокировка регламентных заданий включена".

1️⃣🔤 Нужно ли менять параметры ограничения потребления оперативной памяти Рабочим сервером 1С и если нужно, то в каких случаях?

Что это за параметры:
▫️Безопасный расход памяти за один вызов (КОРП)
▫️Критический объём памяти процессов (ПРОФ)
▫️Временно допустимый объём памяти процессов (ПРОФ)
▫️Интервал превышения допустимого объём памяти (ПРОФ)

Значения по умолчанию:
▫️Безопасный расход памяти за один вызов = 0 (10% от Временно допустимого объёма памяти процессов)
▫️Критический объём памяти процессов = 0 (95% от объёма памяти в ОС)
▫️Временно допустимый объём памяти процессов = 0 (80% от объёма памяти в ОС)
▫️Интервал превышения допустимого объём памяти = 300 сек

❗️Объём памяти в ОС считывается только один раз при старте службы 1С и затем не обновляется. Это очень важно понимать в случае работы с виртуализацией - крайне не рекомендую работать с динамическим объёмом оперативной памяти ОС или менять её объём "налету" без перезапуска службы 1С.

Когда стоит оставить настройки по умолчанию?
Если у вас в Операционной системе кроме сервера 1С больше ничего не работает и соответственно не потребляет большой (более 5%) оперативной памяти ОС.

Когда стоит менять значения по умолчанию?
Если у вас есть другие потребители большого объёма оперативной памяти на этой же ОС.

Например на одной ОС у нас работают:
▫️Сервер 1С и сервер СУБД
▫️Несколько служб 1С
▫️Несколько кластеров в одной службе 1С

На какие значения менять?
Тут всё достаточно просто и сложно одновременно))

Из простого:
Лучше всего соблюсти те же пропорции параметров Критического и Временного объёма от оперативной памяти ОС для этой службы/этого кластера 1С что и по умолчанию, т.е. 80% и 95%

Из сложного:
Определить какой объём памяти ОС вы выделяете службе/кластеру 1С.

Рассмотрим на простом примере "Сервер 1С и сервер СУБД на одной ОС"
Если мы можем ограничить сервер СУБД в потреблении оперативной памяти (в случае с MS SQL), то тогда -
Память для 1С = Память ОС - Память для SQL
Допустим у нас на ОС 128ГБ, серверу СУБД мы выделили 48ГБ, тогда Память для 1С = 80ГБ

Соответственно устанавливаем:
▫️Критический объём памяти процессов = 0 (95% от объёма Память для 1С), в нашем примере это 76ГБ
▫️Временно допустимый объём памяти процессов = 0 (80% от объёма Память для 1С), в нашем примере это 64ГБ
▫️Безопасный расход памяти за один вызов = 0, я не вижу особого смысла трогать этот параметр. так как он зависит от Временно допустимого объёма памяти процессов

Если же у нас вариант, когда на одной ОС несколько служб 1С или внутри одной службы несколько кластеров 1С, то тут только вы сами можете определить какой объём оперативной памяти вы выделяете каждой службе/кластер 1С и уже от этого значения посчитать %% для Критического и Временного ограничений.

У нас остался ещё один параметр "Интервал превышения допустимого объём памяти".
Этот параметр стоит менять только если ваш сценарий использования 1С подразумевает более долгое чем на 5 минут превышение 80% оперативной памяти и при этом оно не достигает 95%, тогда смело меняйте этот параметр в бОльшую сторону.

Что будет, если "побочный" потребитель оперативной памяти есть, а мы не учли это в настройках?
❗️Возможна ситуация, полной остановки ОС или прихода OOMKiler в случае Linux, например когда кто-то запустил в 1С процедуру с огромным потреблением оперативной памяти.
Кластер 1С не сможет вовремя защитить себя и ОС от перерасхода оперативки, так как не знает что она уже кончилась считая что вся оперативка ОС была отдана ему одному.

🔤🔤🔤 Журнал транзакций в PostgreSQL и MS SQL

Во время обучения по PostgreSQL часто встречаю заблуждения по поводу лога транзакций (в PostgreSQL это Журнал предзаписи (Write-Ahead Logging) - что гораздо точнее отражает его суть.

Давайте попробуем прояснить главные отличия этого механизма у двух СУБД.

1. Как хранится журнал транзакций
MS SQL - по умолчанию хранит в одном файле на каждую базу
PostgreSQL - по умолчанию хранится в файлах по 16МБ на весь сервер

2. Нужен ли журнал транзакций для "отката" транзакции
MS SQL - да
PostgreSQL - нет

❗️Тут давайте остановимся чуть подробнее.
"Откат" транзакции в MS SQL происходит с помощью чтения Журнала транзакций с момента начала "отката" до момента начала транзакции в обратном хронологическом порядке и в базе "отыгрываются" все произведённые этой транзакцией изменения.
Соответственно, чтобы обеспечить возможность "отката" транзакции СУБД обязана сохранять весь журнал транзакций с момента её начала.
Из-за этого в MS SQL журнал может неожиданно неконтролируемо вырасти и либо занять всё место на диске либо упереться в максимальный размер файла, заданный в настройках базы.

"Откат" транзакции в PostgreSQL происходит путём смены одного бита в служебной таблице pg_xact, где для каждой транзакции есть запись со статусом committed или aborted.
Поэтому "откат" транзакции в PostgreSQL происходит мгновенно и не требует хранения журнала транзакций (WAL).
Соответственно и роста каталога с WAL по причине долгой транзакции происходить не может.

3. На что влияет операция checkpoint
MS SQL - именно эта операция делает сброс всех "изменённых" страниц с кэша в базу и ставит "метку" в файле Журнала транзакций об этом факте. Теперь журнал транзакций "левее" этой метки может быть заархивирован либо перезаписан новыми данными. (Если нет реплик)
PostgreSQL - Так же делает сброс всех "изменённых" страниц с кэша в базу и ставит "метку" в файле Журнала транзакций об этом факте. Теперь файлы в каталоге с WAL "левее" этой метки могут быть заархивированы либо удалены. (Если нет реплик)

4. Реплики и их влияние на журнал транзакций
MS SQL - будет сохранять журнал пока реплика его весь не заберёт себе. В случае если журнал прирастает быстрее чем его забирает реплика может произойти переполнение диска или максимального размера журнала транзакций и остановка сервера СУБД
PostgreSQL - будет сохранять файлы журнала предзаписи пока реплика созданная со слотом репликации не заберет себе эти файлы. Помним что файлы по 16 МБ, т.е. они и удаляться будут постоянно со скоростью, с которой реплика успевает их себе забрать.
Таким образом даже если общий объём журнала предзаписи за промежуток времени превышает объём диска по WAL, то всё равно место скорее всего не закончится.
Но, если реплика не успевает катастрофически или вообще отключилась, то у нас есть риск переполнения диска.
Для избегания этого риска в PostgreSQL есть настройка: max_slot_wal_keep_size - задаёт максимальный размер файлов WAL, который может оставаться в каталоге pg_wal для слотов репликации после выполнения контрольной точки.
Если объём файлов в каталоге превысит это значение, то слот репликации, которому нужны самые старые файлы WAL будет выключен и каталог будет очищен максимально для продолжения безопасной работы СУБД.

5. Архивирование журнала транзакций
MS SQL - заархивировать можно только журнал "левее" последнего checkpoint. Если у нас не происходит checkpoint или не работает/"завис" процесс архивирования, то сервер будет накапливать журнал и мы упрёмся или в место на диске или в ограничение размера файла журнала транзакций.
PostgreSQL - заархивировать можно любой файл WAL, кроме текущего. НО если у вас по какой-то причине процесс архивирования не работает или "завис", то сервер будет копить файлы WAL и мы придём опять к ситуации окончания места на диске.

Понимание этих основных отличий работы СУБД с журналами транзакций (предзаписи) поможет в понимании механизмов и разборе ситуаций с окончанием места на дисках СУБД.

❗️Место на дисках - САМАЯ ЧАСТАЯ проблема остановки или неадекватного поведения продуктивных серверов как СУБД так и 1С!

🔤🔤🔤 OOMKiller - страшный сон Администратора баз данных.

Попробуем выяснить основные причины, неочевидные особенности работы Лучшей в мире платформы 1С и возможно ли с этим что-то сделать…
OOMKiller –система защиты Linux от перерасхода памяти.
Срабатывает, убивая самый «толстый» по памяти процесс в Операционной системе при приближении расхода памяти к 95%

Итак, в чём же вообще проблема?

В том, что неожиданно падает сервер PostgreSQL и по системным логам мы понимаем что он пал жертвой убийства со стороны OOMKiller.
Основной причиной такого поведения PostgreSQL является ошибка планировщика в том, где делать сортировку результата запроса.
Ошибка планировщика чаще всего возникает из-за отсутствия актуальной статистики по базе – это корневая причина

В итоге, при планировании запроса, планировщик уверен что сортировку можно произвести в памяти, так как по его прикидкам она влезет в параметр work_mem (например 256MB), так как получит на вход небольшое количество строк для сортировки и их размер тоже будет небольшим (например 100 строк, размером по 30КБ каждая). Эти данные планировщик получает из статистики.

Начав выполнение запроса СУБД уже не может ослушаться этой декларации планировщика и выполняет сортировку в памяти.
НО вместо предполагаемых 100 строк по 30КБ, что спокойно вмещается в 256МБ нам для сортировки прилетело 1,5млн строк по 30КБ, что уже занимает 42ГБ!
В итоге в процессе сортировки такого объёма в памяти, эта самая память или совсем закончится или её расход приблизится к уровню сработки OOMKiller-а.

Ситуацию усугубляется следующим:
❗️Убивать процессы нельзя! Это приведет к перезапуску всего PostgreSQL!
▫️work_mem устанавливается на каждое соединение. Т.е. у нас может сложится ситуация когда сразу несколько пользователей 1С сделают запрос к СУБД на такого рода сортировку…
▫️ Каждое соединение в PostgreSQL работает в отдельном процессе и при этом процесс не умеет худеть по памяти, он просто убивается как становится никому не нужным.
▫️ Платформа 1С удерживает idle соединения при необходимости (например в нём создавалась временная таблица и её можно будет переиспользовать) . Т.е. у нас может сложится ситуация, когда запрос выполнился, заняв 20ГБ RAM, при этом соединение удерживается и используется для других запросов, которым столько RAM не нужно.

Методы борьбы с этими негативными моментами:
❗️Убивать процессы нельзя! Это приведет к перезапуску всего PostgreSQL! А значит увидев что процесс работает (не idle) наш единственный шанс корректно завершить этот запрос, это отменить его выполнение на сервере 1С вычислив его по номеру соединения с СУБД.
▫️Необходимо содержать статистику в максимально актуальном состоянии. Настраивая агрессивный autovacuum, устанавливая нестандартные значения сработки autovacuum на больших таблицах, проводить vacuum analyze как регламентную операцию и т.д.
▫️Уменьшить work_mem, отслеживая как это повлияет и на план и на работу дисков
▫️Настроить OOMKiller. Чтобы он не убивал, а замораживал процесс OOMPolicy=continue, но это опасно, так как в итоге вся память может быть поглощена и работы вообще остановится.
▫️Отдельный пункт для борьбы с толстыми idle.
Мы можем вычислить ТОП-3 процессов, потребляющих память

ps -eo pmem,vsize,pid,cmd | sort -k 1 -nr | head -3

и увидеть такую картину:

6.6 12095572 2380533 postgres: postgres erp 10.27.24.1(64722) idle
6.6 12015844 2380844 postgres: postgres erp 10.27.24.1(64837) idle
6.4 12091534 2380682 postgres: postgres erp 10.27.24.1(64735) SELECT

Видим что в топе процессы с idle и только 1 с select.
В PostgreSQL есть параметр idle_session_timeout, по умолчанию 0.
Но мы можем выставить его в 3 сек, подождать 7 сек и обратно убрать в 0.

ALTER SYSTEM SET idle_session_timeout = 3000;
'select pg_reload_conf();
'ALTER SYSTEM RESET idle_session_timeout;

Таким образом мы корректно прервём соединения с 1С и СУБд сама корректно завершит наши объевшиеся процессы.
Негативный побочный эффект – временные таблицы платформе 1С придётся создать заново, но по сравнению с перезапуском СУБД это допустимо

1️⃣🔤 Почему может не формироваться Технологический журнал 1С?

ТехЖурнал лучшей в мире платформы 1С (ТЖ) - это реальное отражение работы 1С с объективными цифрами и данными.

Он давно стал одним из основных инструментов в работе Экспертов, а уж при работе с КОРП клиентами по линии РКЛ это вообще незаменимая вещь!

При этом достаточно часто встречаемся с ситуацией, когда ТЖ "не хочет" формироваться и начинаются танцы с бубнами...

Ниже опишу основные причины этих танцев:

▫️Права на каталог сбора ТЖ.
Проблема проявляется когда есть процессы 1С, работающие из под разных пользователей операционной системы.
Например:
- Служба агента кластера (ragent, rmngr, rphost) 1С работает из под v81cuser, а служба Удаленного сервера администрирования (ras) работает под другим пользователем ras1c.
- Процессы кластера 1С (ragent, rmngr, rphost) работают под разными пользователями, каждый под своим
- Вместе с кластером 1С установлен также web-сервер с модулем публикации 1С, который тоже работает под своим пользователем

В итоге после настройки сбора ТЖ каталог будет создан с правами того пользователя чей процесс первым увидит и «осознает» новую или изменившуюся настройку, а остальным туда доступ на изменение будет закрыт. И мы получим, например, что у нас пишется ТЖ только процесса ras.

Рецепт: Необходимо заранее создать все каталоги размещения файлов ТЖ ( например log location="C:\TJ\RKL") и выдать им права на изменение всем пользователям всех процессов системы, которые могут писать ТЖ.

Ну и если уж совсем ничего не помогает, то создайте заранее каталог (C:\TJ), дайте на него все права всем и потом настройте сбор ТЖ в этот каталог.

▫️В файле conf.cfg текущей версии платформы прописали ConfLocation

Тогда система будет искать файл настройки ТЖ (logcfg.xml) именно в этом каталоге, а не каталогах по умолчанию %PROGRAMFILES%\1cv8\conf, /opt/1cv8/conf

Рецепт: либо расположить файл logcfg.xml в каталоге указанном в ConfLocation либо убрать эту строку из файла conf.cfg

▫️И наверное самое неочевидное – в файле logcfg.xml есть более одного тега log location и в одном из них указан несуществующий диск в системе Windows либо примонтированный каталог Linux

Тогда рандомно будет то записываться ТЖ, то нет, то от одних процессов, то от других.

Рецепт: во всех тегах log location файла logcfg.xml должны быть указаны существующие в операционной системе диски Windows либо примонтированный каталог Linux

▫️В каталоге сбора ТЖ находятся посторонние файлы

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

🔤🔤🔤 8.5.1.1150 Толстый клиент

Новая мини-рубрика - срочно в канал!)))
В ней буду освещать критичные на мой взгляд ошибки, которые ещё не зарегистрированы.

Вот и пришло время обновиться на 8.5...

И поймали ошибку на скриншоте

Условие ошибки:
В конфигурации должен быть добавлен хотя бы один Элемент стиля
Подключаемся к ней на платформе 8.5.1.1150 в клиент-серверном режиме (в файловом всё работает)
Запускаем Толстый клиент
Авторизация 1С

❗️При этом конфигуратор запускается

Рецепты:
1. Не обновляться на 8.5, если используете Толстые клиенты
2. Перейти на прозрачную авторизацию AD, если давно собирались, но никак не находили для этого время
3. Указать логин и пароль в параметрах запуска, если это позволяет ваш сценарий

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