1cv8clst lst и 1cv8clsto lst что за файлы
Внимание!
Введение
В этом уроке мы научимся использовать обновлятор для однократного (или регулярного по расписанию) сокращения журнала регистрации в одной или группе баз.
При этом я покажу как сохранять и архивировать сокращаемую часть журнала на отдельный диск.
Пакетные скрипты
Все операции мы будем проводить на закладке обновлятора "Скрипты":
Если вы ещё не работали с пакетными скриптами в обновляторе, советую бегло пробежаться по их возможностям: ссылка.
Оговорка
Всю следующую практическую часть мы будем делать на примере одной базы и запускать этот скрипт вручную.
Но в реальных задачах ничего не помешает нам запускать скрипт для любого количества баз (в том числе параллельно) и сохранять этот скрипт в расписание с уведомлением на почту - обо всё этом здесь.
Простейший вариант скрипта
За сокращение журнала регистрации (для любых типов баз: файловых и серверных) отвечает ключ ReduceEventLogSize в пакетном режиме конфигуратора.
В качестве параметра он принимает новую (левую) границу журнала регистрации в формате ГГГГ-ММ-ДД.
И если мы, например, хотим сократить все записи в журнале регистрации до 1 января 2018 года, то простейший вариант скрипта будет таким:
Добавляем сохранение удаляемой части в архив
Но этого мало. Мы хотим не просто сокращать журнал регистрации (который обычно занимает непростительно много места на системном диске), но ещё и сохранять сокращаемую часть на другом диске (и желательно в сжатом архиватором виде). Чтобы в случае чего к ней можно было обратиться через меню "Файл-Открыть " в конфигураторе.
Предположим, что общим местом хранения архивов журналов регистрации (для всех баз) является папка "x:\Backups\1C\EventLogs".
Этот путь уже должен существовать.
Модифицируем наш скрипт, чтобы сокращаемая часть писалась в эту папку с правильным именем:
Сжимаем сокращаемую часть архиватором
Для этого файл выгрузки сокращаемой части упакуем архиватором 7z (он идёт вместе с обновлятором), а затем удалим сам файл.
Скрипт будет таким:
Всегда сокращаем журнал на текущую дату
У нас получился универсальный скрипт, который уже можно выполнять для группы баз и ставить в планировщик.
Если бы не дата, которая жёстко прописана в скрипте, что делает бессмысленным многократный запуск этого скрипта в неизменном виде.
Давайте изменим скрипт так, чтобы при его запуске всегда подставлялась текущая дата. Это позволит нам поставить скрипт в планировщик на запуск, скажем раз в месяц, и забыть о ручном сокращении журнала регистрации раз и навсегда.
Задача получить текущую дату в скрипте в формате ГГГГ-ММ-ДД не такая простая, если рассматривать универсальное решение для всех случаев жизни.
Но для случая, когда представление даты на компьютере имеет вид ДД.ММ.ГГГГ (обычно это так по умолчанию), вытащить нужные числа и поставить их в нужном порядке можно вот так:
Обратите внимание, что мы здесь просто вытаскиваем по индексу и длине нужные части из даты, которая первоначально имеет вид ДД.ММ.ГГГГ, то есть переводим строку в формате ДД.ММ.ГГГГ в формат ГГГГ-ММ-ДД.
В итоге получим вот такой скрипт:
Удаляем неиспользуемые страницы из журнала регистрации
Вы удивитесь, но несмотря на все вышеописанные процедуры, размер файла в котором журнал физически хранится в формате sqllite не уменьшится совершенно.
То есть если он был 10 гигабайт до процедуры сокращения записей, то 10 гигабайт и останется.
Всё дело в том, что, после удаления записей из журнала регистрации, физически данные с диска не удаляются, а лишь помечаются как удаленные. Это сделано для повышения производительности.
За сжатие журнала регистрации отвечает команда Vacuum, она позволяет удалить все неиспользуемые страницы и дефрагментировать данные.
Выполнение этой команды требует остановки сервера 1с (если речь о серверной базе), чтобы получить монопольный доступ к файлу журнала регистрации.
Поэтому я рекомендую сделать эту операцию (если файл журнала регистрации уже сейчас очень сильно вырос) один раз и в дальнейшем регулярно выполнять сокращение через ключ конфигуратора ReduceEventLogSize (мы его рассмотрели выше). Это позволит удерживать размер журнала регистрации примерно на одном уровне.
Подготовительные работы
Качаем и распаковываем вот этот пункт:
Там 3 утилиты, из которых нам нужна sqlite3.exe.
Альтернативное место для скачивания этой же утилиты - мой сайт (я подписал её своей электронной подписью).
Распакуем эту утилиту, например, в папку "x:\work" и соответственно будем обращаться к ней из скриптов как "x:\work\sqlite3.exe".
Vacuum для файловых баз
Для файловых баз выполним команду Vacuum через новый пакетный скрипт обновлятора, полагая что журнал регистрации хранится в папке с базой в "1Cv8Log\1Cv8.lgd".
Ещё раз напомню, что команду Vacuum имеет смысл выполнять уже после сокращения журнала регистрации при помощи описанного выше ключа конфигуратора ReduceEventLogSize.
Vacuum для серверных баз
С серверными базами всё несколько сложнее, в том смысле что полной автоматизации выполнения команды Vacuum для избранных баз простым пакетным скриптом не достичь.
Не достичь хотя бы потому, что невозможно автоматически определять путь к журналу регистрации серверной базы. Это нужно делать разбором файла настроек сервера 1с (1CV8Clst.lst), который тоже ещё надо правильно обнаружить. Все эти возможности выходят за рамки пакетного скрипта.
Но так как мы изначально планируем сделать Vacuum только после первого сокращения журнала регистрации, то полной автоматизации нам здесь и не надо.
Я опишу лишь примерный порядок действий:
1. Находим папку с настройками кластера 1с. Обычно это что-то типа: "c:\Program Files\1cv8\srvinfo\reg_1541".
Например, так (указанный внутри скрипт пишется и запускается в командном файле vacuum.cmd без обновлятора):
Перед его выполнением нужно остановить службу сервера 1с.
А что если нам требуется определить какой папке соответствует какая база? Для этого открываем файл 1CV8Clst.lst в корне reg_1541 и из него находим, что, например, папке 0deaa216-26dd-4ae0-9483-51a85b38c093 соответствует база test:
То есть мы можем выполнить vacuum как для всех баз на сервере, так и для избранных.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Итак, у вас количество баз давно перевалило за десяток. Все эти базы раскиданы по кластерам. К тому же и версии платформы 1С у этих баз разные. Ну а вы, к несчастью - администратор всего этого хозяйства. К несчастью, потому что вы администратор 1С. А это необычный администратор. Случается так, что вы не имеете прав локального администратора, а консоль сервера приложений на вашем рабочем месте не установлена. Но не беда, поставить ее вам готовы уже завтра-послезавтра.
И вот вам поставили консоль, и вы даже подключили сервера. Но. не все сервера рады показать вам списки своих баз. Вспоминаете вы, что версии-то у них разные.
Решаете вы и эту проблему. И теперь есть возможность запускать консоли разных версий и видеть соответствующие списки баз. Можно выдохнуть и открыть-таки настройки требуемой базы, чтобы понять в какой же базе SQL она лежит, разрешены ли в ней регламентные задания ну или что там еще вы хотели посмотреть изначально.
Но тут очередная беда подстерегает вас. Вы ведь не знаете заветную пару логин/ пароль администратора этой базы. И труды ваши были напрасны.
Актуальные задачи
Эту занимательную историю можно продолжать бесконечно. Для кого-то она покажется надуманной, а кто-то сможет дополнить ее еще новыми трудовыми этапами. Но все, кто сталкивался с поддержкой и обслуживанием различных кластеров с большим количеством баз рано или поздно озадачиваются вопросом получения сводной информацией о текущем состоянии всего этого зоопарка.
Полезно увидеть информацию о базах в разрезе кластеров, баз данных для понимания загруженности серверов; отобрать базы с "не выключенными" регламентными заданиями, базы с блокировкой подключений и пр. Вобщем посмотреть на это хозяйство сверху и принять.
Пример решения
Вся эта информация хранится в файликах 1CV8Clst.lst или 1CV8Reg.lst на серверах 1с в каталогах ". srvinfo". Подробней можно посмотреть на сайте ИТС здесь или здесь.
Путь к папкам "program files" можно получить из реестра (Shell.RegRead("HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramFilesDir (x86)") и Shell.RegRead("HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionProgramW6432Dir")).
В зависимости от версии 1С, srvinfo может лежать либо в папке 1cv82 либо в 1cv8.
Доступ к этим файлам имеет, например пользователь, под которым запускается сервис сервера 1с. Т.е даже в случае отсутствия взаимопонимания с праведными администраторами есть возможность получить доступ к этим файликам из самой 1с, выполняя код на сервере. Тут стоит, однако оговориться, что выполнение кода на сервере не всегда гарантирует нам доступ к файлам с настройками. Если у кластера несколько рабочих серверов, то не факт, что серверный вызов будет на центральный сервер, где хранятся соответствующие настройки.
Соответственно имея ввиду вышесказанное можно написать обработку, которая найдет эти файлики, распарсит их и выведет всю необходимую информацию вам в виде отчета.
Так и родилась данная обработка.
Ограничения обработки
Данная обработка работает только на управляемых формах и на версиях 1C от 8.3.x.x
Режим использования синхронных вызовов расширений и внешних компонент: Использовать или Использовать с предупреждениями
Для возможности анализировать настройки удаленных серверов (по списку серверов) должен быть доступ к соответствующим папкам с настройками, а так же доступ к созданию объекта winmgmts и выполнению сценариев WSH, для компьютеров из указываемого списка либо под правами локального пользователя, либо под правами пользователя сервера приложений базы, из которой запускается обработка
Функционал обработки
Обработка анализирует файлы настроек кластеров различных версий 1С (8.2, 8.3)
Показывает несоответствие структуры каталога кластера и настроек конфигурационного файла (т.е. ситуации, когда фактически существует каталог, не связанный с базами кластера или наоборот, нет каталога для конкретной базы, прописаной в конфигурационном файле)
Бонусом вы получаете универсальные алгоритмы, которые можно использовать при дальнейшей разработке
- программное формирование меню
- программное формирование отчета на базе СКД с внешним источником данных для управляемых форм.
- открытие сайта, почтового клиента, чтение ключей реестра Windows и пр.
P.S.
Если Ваш файл с настройками вдруг не распознался , Вы можете прислать мне этот файл с указанием релиза платформы кластера 1С, данные которого содержит этот файл, и я постараюсь :) добавить формат файла в обработку.
- Добавлены проверки ошибок чтения файлов настроек для возможности продолжать работу в ситуациях, когда файлы по каким-то причинам стали не доступны.
- Добавлен код для помещения обработки в качестве внешней обработки при наличии БСП.
- Добавлен вывод новых полей в отчет СКД, в том числе поле ЕстьРазличиевИмениБазы1С_И_СУБД для дополнительной аналитики.
Полностью история изменений доступна по кнопке "О программе" меню "Информация".
Начиная с редакции 8.3.13.х у платформы 1С появился механизм управления потреблением ресурсов кластера серверов. В свете последних новостей нужно сделать оговорку: Доступно только для лицензии КОРП. Но пока это время не наступило можно попробовать бесплатно.
Постановка задачи:
Честно говоря, сейчас все вопросы использования 1С, как администрирования, там и обычной работы отлично освещены в ИТС, с картинками и примерами.
Иногда даже полнее чем в сторонних публикациях, чего стоят например чек-листы по настройке серверов в продакте.
Поэтому эту статью можно рассматривать как иллюстрацию (дополнение к) официальной документации по механизму управления потреблением ресурсов платформы 1С:Предприятие 8.3.13 и следующих разумеется.
А так же возможные сценарии использования, если в комментариях появятся дельные варианты, я думаю это всем пойдет на пользу.
Многие побоялись ее (платформу) устанавливать, из суеверных соображений или из соображений практичности. Для них будет интересно.
Решение:
Как я уже писал ранее, каждое тестирование облачных платформ использовалось еще и для прояснения некоторых вопросов, возникающих у меня.
Не стало исключением и 1С в облачной платформе Microsoft. В Azure все в ажуре? (спасибо Microsoft за просто громадную сумму выделенную на тестовый период)
В нем попробовал на зуб, как работает механизм управления потреблением ресурсов.
Тестовый контур и порядок работы:
Как работает механизм вкратце:
В консоли управления кластером добавлены два новых раздела: счетчики потребления ресурсов и ограничения потребления ресурсов.
Информация, накопленная счетчиками, может отображаться в консоли кластера (каких либо программных способов доступа к ней или созданию объектов из встроенного языка, пока не обнаружил, будет один лайфхак в конце статьи), а может еще и использоваться механизмом ограничения потребления ресурсов.
Замеры производятся либо в плавающем интервале заданной длительности (когда счетчик настроен на анализ показателей за интервал времени, то срабатывание ограничений будет действовать пока показатели счетчика не станут меньше контрольных), либо за серверный вызов.
Собираемая информация условно поделена на три вида:
- Время (Серверные вызовы, Процессорное время, Время вызовов СУБД, Время вызовов сервисов)
- Объем данных в байтах (Объем оперативной памяти, занятой сеансом, Объем данных, прочитанных с диска, Объем данных, записанных на диск, Объем данных, которые были переданы и получены при работе с СУБД)
- Количественные показатели (Количество серверных вызовов, Количество активных сеансов, Общее количество сеансов за интервал измерения)
Создаваемый счетчик позволяет собирать любые из этих показателей в любой комбинации.
При этом возможна фильтрация (на равенство или на неравенство) по имени информационной базы, имени пользователя, по значениям разделителей областей данных, по идентификатору приложения, использующего сеанс. Также в различных комбинациях.
Ограничение потребления ресурсов опирается на данные одного конкретного счетчика и при превышении любого из контролируемых показателей может выполнить четыре действия:
- записать событие в технологический журнал и не делать ничего,
- завершить серверный вызов,
- завершить сеанс,
- понизить приоритет потока.
На этом теория заканчивается, все более подробно описано в ИТС.
Стоят верблюд-сын и верблюд-отец.
Сын: Папа, а зачем нам на спине нужен горб?
Отец: В горбу, сынок мы накапливаем воду и когда идем по пустыне нас не мучает жажда.
С: Папа, а зачем нам такие копыта?
О: Это чтобы ходить по песку и ноги не проваливались.
С: А зачем нам такие большие и жесткие губы?
О: Это чтобы в пустыне можно было есть колючки
С: Тогда папа объясни мне, на хрена нам весь этот тюнинг в Саратовском зоопарке.
© анекдот.ру
Откуда мотивация понятно - для работы во фреше, а также на крупных внедрениях необходимо как то упорядочивать работу пользователей.
В MS SQL есть похожий механизм, честно говоря думал, что 1С к нему подцепится. Но он насколько я помню в редакции Enterprise.
Опять же если свести воедино информацию всех счетчиков, можно сделать подобие биллинга и выставлять счет по реально потребленным ресурсам.
По большому счету, если проследить все последние изменения платформы, все они нацелены на поддержку облачных и немаленьких решений.
И последние редакции содержат столько наворотов, что использовать их все в одной обычной группе компаний просто не реально.
Если так пойдет и дальше, то нужна будет еще одна версия платформы между базовой и обычной - для среднего бизнеса.
С другой стороны некоторые вещи и в обычной работе не помешают, поскольку в каждом среднем коллективе есть уникумы, запускающие отчеты с начала веков или отрывающие десяток сессий с разных мест.
Отсюда и .
Первый тест: ограничение количества активных сеансов для пользователя (для затравки):
Второй тест: понижение приоритета потока для пользователя информационной базы:
В ИТС это понятие не расшифровывается.
"понизить приоритет потока, который исполняет текущий серверный вызов" на сколько (во сколько) раз непонятно.
На глаз замедление заметно, как измерить это замедление для разных пользователей работающих в одной базе, чтобы получить количественные результаты я не придумал.
Этот вариант использования наверное самый востребованный.
Если сделаете такой для главного бухгалтера в дни отчетности - он вас прославит в веках.
А сделать легко: фильтр по имени пользователя, тип отбора - все кроме выбранных, вид ограничения - понижение приоритета потока.
Вжух, и все менеджеры работают медленно, а бухгалтерия быстро.
Третий тест: понижение приоритета потока для информационной базы целиком:
В нем как раз измерить количественно замедление получилось, но результаты - неоднозначные.
Для этого были запущены две одинаковые базы 1С, одна с применением ограничения "Понижение приоритета потока"
Для верности добавил еще подсчет серверных вызовов, вызовов СУБД и процессорного времени, потому что сомневался, что может считаться активной сессией, при таком фильтре, одна на пользователя или на всю базу
А так наверняка, что единичку они превысят. Дробные значения у меня консоль не приняла (точнее приняла, но при следующем открытии сбросила в ноль).
И на этих базах запущены тесты производительности из прошлых статей.
Их результаты в виде таблицы:
Тест/Конфигурация ВМ | 1C | ||||||
gilev.ru | APDEX | fragster.ru (Результат на поток) | |||||
Временные таблицы | Справочники | Регистры сведений | Регистры накопления | Регистры бухгалтерии | |||
Без ограничения | 16,72 | 0,989 | 2 016,16 | 290,21 | 290,21 | 237,69 | 238,52 |
С ограничением процессорного времени | 1,67 | 0,806 | 1 361,26 | 185,09 | 138,72 | 129,22 | 130,85 |
Единственное отличие - запускал тесты в обратном порядке.
Сначала APDEX с количеством 10 пользователей в базе.
Тренер утешает проигравшего боксера:
- А все-таки в третьем раунде ты своего противника здорово напугал.
- Чем это?
- Ему показалось, что он тебя убил.
© анекдот.ру
И на закуску тест с gilev.ru. С ним вообще вышел полный оверкиль. Я уже думал, что все зависло.
Пробовал несколько раз. Чистил кеши, перезагружал базу. Похоже новый механизм от 1С прибивает его начисто.
Позволю себе высказать предположение, что понижение приоритета нелинейное, чем активнее "нарушитель" использует процессор сервера, тем активнее 1С его притормаживает.
Поэтому APDEX пострадал не сильно, более агрессивный тест дал большее замедление, а тест Гилева, который упирается в сервер напрямую, замедлился совсем.
К тому же первые два теста "размазывают" нагрузку по нескольким сессиям, а тест Гилева идет под одним.
Впрочем возможно дело и в реализации самих тестов.
Продавцам зонтов надо молиться на дождливое лето.
Продавцам сандалий надо молиться на сухое лето.
Продавцам пива надо молиться на жаркое лето.
А продавцам водки некогда молиться, им надо продавать!
© анекдот.р
Тест четвертый: нереализованный:
Наверное при вдумчивом подходе, можно снять базовую линию нагрузки сервера по процессорному времени и настроить ограничение для выходящих за нее.
С другой стороны, у всех систем есть выраженная в той или иной степени сезонность (для бухгалтерии это дни сдачи отчетности, для кадровиков - выплаты заработной платы, оперативный учет тоже привязан обычно к времени года).
Больше вариантов у меня не набралось. Это не значит, что их нет вообще. Может как раз для кого то критично количество байт переданных СУБД или количество серверных вызовов и они будут срубать пользователей за это.
Собственно для это и существуют комментарии к публикации, чтобы все желающие могли высказаться по существу.
За лучший вариант - небольшое вознаграждение.
Как все это работает:
Все настройки созданных счетчиков и ограничений хранятся в файле реестра кластера 1CV8Clst.lst (1CV8Clsto.lst) расположенном в каталоге данных рабочего сервера, отмеченного как центральный.
Все результаты счетчиков записываются в текстовый файл rescntsrv.lst находящемся там же.
Формат совпадает.
Таким образом можно разбирать замеры счетчиков и передавать их в тот же Zabbix не настраивая технологический журнал.
Преимущество перед технологическим журналом в том что файл не разрастается, а старые события вытесняются новыми в пределах плавающего окна заданного в процессе настройки счетчика(ов).
Безусловно при определенной сноровке можно и ТЖ привести к подобному виду.
Итог:
Достаточно интересный механизм уже на сегодняшний день и наверняка он будет дорабатываться и обрастать новыми возможностями.
А они ограничены только вашей фантазией.
На сегодняшний день не хватает документации, из-за этого сложно выстроить варианты применения.
Очень хорошо, что в платформу добавляются новые возможности, облегчающие жизнь DBA.
Жалко, что скоро эти возможности будут доступны только обладателям лицензии КОРП.
Желающие что-то подтвердить, опровергнуть или еще раз уточнить для себя, не вижу что вас может остановить.
Ссылки на использованные публикации.
Не верю, что мне приходится писать для пользователей этого сайта, но как оказалось нужно.
Если вы не представляете: что такое 1С Предприятие, файл и зачем вам нужна эта кухня.
Все файлы из интернет считаете зараженными вирусом.
Если физиологические, моральные, религиозные или другие причины не позволяют вам заполнять справочники, документы, настраивать отчеты 1С и запускать обработки.
А платить вы за это не будете так как программист с десятилетним стажем.
Закройте эту страницу не продолжая чтения дальше.
Для адекватных людей:
Если у вас есть конкретные замечания или предложения по улучшению - пишите.
Вы уже успели заметить, что обновлятор по умолчанию архивирует серверные базы 1с в формате dt.
При этом выгрузка в dt имеет ряд серьёзных недостатков:
- не рекомендуется фирмой "1С" (ссылка)
- требует монопольного доступа
- требует много времени
- требует много ресурсов сервера
- нет никаких гарантий, что в такую выгрузку попадают абсолютно все данные при малейшем повреждении базы
- зачастую приводит к ошибкам сервера 1с
Именно поэтому я рекомендую при первой возможности отказаться от выгрузки в dt в пользу архивации средствами СУБД.
Обновлятор умеет одинаково хорошо работать как с MS SQL Server, так и с набирающей обороты PostgreSQL.
При этом не важно на какой ОС работает сервер с установленной СУБД. Это может быть как Windows, так и любой дистрибутив Linux (CentOS, Debian, Ubuntu, ГосЛинукс, Altlinux, Rosa, МСВСфера, Red Hat).
Как включить архивацию базы средствами СУБД
1. Зайдите в свойства базы и перейдите на закладку "Архивация" и установите опцию "Включить sql архив":
Выполните необходимые настройки. При этом я не рекомендую устанавливать опцию "Дополнительно делать dt выгрузку" по причинам озвученным во введении этой статьи.
2. Далее перейдите на закладку "Общее" и укажите там сервер СУБД, если он ещё не указан:
Как восстановить созданный sql-архив через обновлятор?
Вы всегда можете восстановить базу из её резервной sql-копии. Для этого нажмите на базе правой кнопкой и выберите следующий пункт:
Варианты восстановления из резервной копии
При (ручном или автоматическом) восстановлении серверной базы 1с из sql-копии вам будет предложено указать опции восстановления:
Вариант "ничего не делать с базой в кластере"
В этом случае резервная копия будет развернута в ту же самую базу на кластере 1с.
К плюсам этого варианта восстановления можно отнести то, что сохраняется старый журнал регистрации.
Но в то же время могут быть проблемы с кэшем сервера 1с, если метаданные исходной и восстановленной базы отличаются друг от друга (ведь восстановление мы делаем на уровне сервера СУБД, а кластер 1с ничего не знает об этом).
Одним из проявлений таких проблем могут быть ошибки при выполнении кода конфигурации, когда платформа 1с ругается на какой-нибудь неизвестный ей объект метаданных (например, реквизит справочника), а при проверке он оказывается на месте.
Поэтому рекомендуется или восстанавливать таким способом резервные копии, которые были созданы непосредственно перед проблемной операцией, либо делать перезапуск кластера 1с (чтобы сбросить его кэш) сразу после восстановления базы из резервной копии.
На тот случай, если мы не можем выполнить перезапуск кластера сразу после восстановления из резервной копии (а он желателен), рекомендуется установить галку "оставить базу заблокированной", чтобы никто не смог с ней работать пока мы не выполним перезапуск кластера.
Но если мы оставили базу заблокированной после восстановления, то следует внимательно отнестись к процедуре её разблокировки. Это можно сделать прямо из обновлятора (пункт 6.08 из меню операций), но обратите внимание, что в этом случае регламентные задачи нужно будет разблокировать отдельно (если это требуется) через пункт 6.14.
Вариант "пересоздать базу в кластере с теми же параметрами"
В этом случае резервная копия будет восстановлена в ту же самую базу в кластере 1с, но эта база (в кластере) на определенных этапах будет удалена и добавлена вновь с теми же самыми параметрами.
Это позволит избежать проблем с кэшем сервера 1с, описанным в предыдущем варианте (см. выше), без перезапуска кластера, но в то же время разорвётся связь текущей базы с её предыдущим журналом регистрации.
И если речь идёт о восстановлении резервной копии в чистую, только что созданную базу, журнал регистрации которой пуст или не существенен для нас, то проблем нет. Но если мы восстанавливаем резервную копию в уже существующую рабочую базу - журнал регистрации обычно требуется сохранить.
Полная автоматизация восстановления журнала регистрации, к сожалению, не возможна при работающем кластере 1с, это придётся (при необходимости) сделать в ручном режиме.
Инструкция для переноса журнал регистрации из старой базы (выполняется до восстановления базы из резервной копии):
Но что если мы спохватились уже после того как выполнили восстановление из резервной копии и база в кластере 1с была удалена и добавлена вновь (то есть её идентификатор уже изменился). Как узнать папку, в которой хранится журнал регистрации старой базы?
Если вы обнаружили это сразу после восстановления базы, то есть шанс найти её старый идентификатор в файле 1CV8Clsto.lst, который является копией 1CV8Clst.lst (до его последнего изменения) и лежит там же. Получается, что перед каждым изменением настроек кластера 1с (которое приводит к изменению файла 1CV8Clst.lst), этот файл перед изменением копируется в 1CV8Clsto.lst.
Если же база уже исчезла из 1CV8Clsto.lst, то её старый идентификатор просто так уже не найти. И ничего не остаётся кроме как по очереди исследовать журналы регистрации всех подпапок из "c:\Program Files\1cv8\srvinfo\reg_1541\*\1Cv8Log" и уже по содержимому журналов регистрации устанавливать тот, что относился к нужной базе. Журналы можно просматривать или восстанавливая их в чистую (файловую) базу или же при помощи утилиты DB Browser for SQLite (если речь о новом формате хранения).
Вскоре в обновлятор будет добавлена возможность отслеживать расположение журналов регистрации (и фиксировать в отчётах при выполнении операций) для серверных баз.
Нюансы для MS SQL Server
Настройте права учетной записи sql-сервера
Прошу вас очень подробно ознакомиться с этим пунктом, особенно если ваш sql-сервер находится на другой машине (соответствующая галка в настройках сервера СУБД). Здесь много нюансов, на которые нужно обратить внимание.
Прежде всего обратите внимание на то, что служба sql-сервера работает от имени некоторой учётной записи.
И когда обновлятор просит sql-сервер сделать выгрузку в основную папку архивов для этой базы, то запись идёт от имени учётной записи sql-сервера.
Поэтому у этой учётной записи должны быть соответствующие права на основную папку архивов, а в некоторых случаях и на временную папку обновлятора.
Права на временную папку обновлятора (по умолчанию это папка 'Data\Temp' внутри обновлятора) могут понадобиться, когда архив сначала записывается во временную папку, а уже затем переносится в основную папку архивов. Такое поведение возможно, если вы настроили запись архивов в конечную папку от имени определенного пользователя для защиты созданных архивов от шифровальщиков.
Если sql-сервер находится на другой машине.
В этом случае не забудьте поставить галку "Сервер находится на другом компьютере" в настройках сервера СУБД.
. а также выполнить следующие требования.
В качестве основной папки для архивов базы должен выступать полный сетевой путь до общей папки (шары), доступной как для sql-сервера (вернее его учётной записи), так и для компьютера на котором запущен обновлятор.
Эта общая папка должна быть подключена в обновляторе здесь.
При этом использование сетевых дисков недопустимо, ведь в сеансе sql-сервера на другом компьютере никто не будет подключать этот же сетевой диск (если вы только сами не позаботились об этом специальными средствами). Указывать нужно полный сетевой путь.
Права на запись в эту шару (как на уровне сетевой папки, так и на уровне ограничений безопасности NTFS) должны быть настроены так, чтобы учетная запись, под которой работает обновлятор была в состоянии изменять и удалять файлы в этой шаре и её подпапках.
Не сломается ли разностное копирование на sql-сервере?
Начиная с версии от 3 июля 2018 года обновлятор помечает создаваемые sql-копии как copy-only.
Подробнее о резервных копиях этого вида можно прочитать здесь.
Такие копии являются изолированными от обычной последовательности резервных копий SQL Server.
Это сделано для того, чтобы резервные копии, создаваемые обновлятором (которые он сам же и чистит) не ломали цепочку резервных копий, которые возможно создаются другими способами и могут включать в себя разностное копирование.
Итак, резервные sql-копии, которые создаёт обновлятор (начиная с 3 июля 2018 года) помечаются как copy-only, а значит не нарушают возможную цепочку архивов, которые могут включать в себя разностные копии.
Это значит, что когда вы создаёте разностную копию базы, sql-сервер в качестве опорной точки (базы) никогда не возьмёт копию, созданную обновлятором, так как она copy-only. Вместо этого он обратиться к предыдущей полной копии базы, которая создавалась не как copy-only.
Всё это позволяет создавать sql-копии через обновлятор (перед опасными операциями с базой), не боясь испортить основную схему резервного копирования.
Этапы восстановления из резервной копии (ms sql)
Для базы 1с на MS SQL восстановление из резервной копии происходит в 4 шага.
Шаг 1 (ms sql)
Обновлятор принудительно завершает все соединения (в том числе для администрирования) с базой в кластере 1с.
Шаг 2 (ms sql)
Этот шаг выполняется только, если в параметрах восстановления выбран вариант "пересоздать базу в кластере с теми же параметрами".
На этом шаге обновлятор удаляет базу из кластера 1с (без удаления соответствующей ей базе на сервере СУБД), чтобы затем (после восстановления базы на сервере СУБД из резервной копии) создать её вновь с теми же параметрами.
Шаг 3 (ms sql)
Обновлятор загружает резервную копию в соответствующую базу на сервере СУБД.
Шаг 4 (ms sql)
Этот шаг выполняется только, если в параметрах восстановления выбран вариант "пересоздать базу в кластере с теми же параметрами".
На этом шаге обновлятор вновь создаёт базу в кластере 1с с теми же параметрами и связывает её с соответствующей базой на сервере СУБД.
Нюансы для PostgreSQL
Выбор дистрибутива
Для того, чтобы обновлятор смог работать с базами 1с на PostgreSQL в настройках сервера СУБД необходимо указать путь к папке bin установленного PostgreSQL:
Дистрибутив PostgreSQL, который мы указываем в обновляторе:
- должен быть для Windows
- источники дистрибутива
При этом нам не важно на какой ОС стоит сервер СУБД.
Вот пример рабочего окружения:
- рабочая СУБД установлена на сервере с CentOS 7: дистрибутив PostgreSQL 9.6.9 (версия для CentOS 7)
- обновлятор установлен на Windows; на этой же машине установлен PostgreSQL 9.6.9 (версия для Windows), который указан в настройках обновлятора
Важно. От указанного в настройках PostgreSQL обновлятору нужные лишь его утилиты (например, pg_dump и psql).
Сам же сервер PostgreSQL на компьютере обновлятора работать не обязан, если только этот компьютер сам не является сервером СУБД.
Чтобы отключить работу сервера СУБД после его установки, зайдите в оснастку "Службы" и отключите там запуск службы PostgreSQL, например, "postgresql-1с-9.6".
Откройте файл настроек postgresql.conf на сервере СУБД и впишите туда (вместо имеющейся) строчку:
Этапы восстановления из резервной копии (postgres)
Для базы 1с на PostgreSQL восстановление из резервной копии происходит в 10 шагов. Такое большое количество шагов обусловлено требованием отказоустойчивости к выполнению операции, чтобы учесть все возможные варианты ошибок. Чтобы не получилось так, что после операции восстановления пользователь вообще остался без рабочей базы.
Шаг 1 (postgres)
Обновлятор получает список существующих баз на сервере СУБД. Он делает это, чтобы убедиться в отсутствии временных баз, которые могли остаться после прошлых операций восстановления из резервной копии.
Шаг 2 (postgres)
Обновлятор создаёт пустую временную базу на сервере СУБД, формируя её имя следующим образом: %ИмяРабочейБазы%_temp_base_for_restoring_by_updater_1c
Шаг 3 (postgres)
Обновлятор загружает резервную копию в созданную на предыдущем шаге пустую временную базу.
Шаг 4 (postgres)
Обновлятор принудительно завершает все соединения с базой (в том числе для администрирования) в кластере 1с.
Шаг 5 (postgres)
Здесь возможны два варианта
Если вы выбрали вариант восстановления "ничего не делать с базой в кластере", то обновлятор на этом шаге устанавливает в кластере 1с для нашей базы свойство 'Имя базы данных' в пустое значение. Это нужно, чтобы кластер 1с перестал использовать соответствующую базу на сервере СУБД.
Если же вы выбрали вариант восстановления "пересоздать базу в кластере с теми же параметрами", то на этом шаге обновлятор удаляет базу из кластера 1с (без удаления соответствующей ей базы на сервере СУБД).
Шаг 6 (postgres)
Обновлятор ожидает 10 секунд, чтобы кластер 1с перестал использовать рабочую базу на сервере СУБД.
Шаг 7 (postgres)
Обновлятор переименовывает рабочую базу на сервере СУБД в другое имя, формируя его следующим образом: %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c
Шаг 8 (postgres)
Обновлятор переименовывает временную базу %ИмяРабочейБазы%_temp_base_for_restoring_by_updater_1c в рабочую базу %ИмяРабочейБазы%
Шаг 9 (postgres)
Здесь также возможны два варианта.
Если вы выбрали вариант восстановления "ничего не делать с базой в кластере", то обновлятор на этом шаге вновь настраивает нашу базу в кластере 1с на рабочую базу %ИмяРабочейБазы% на сервере СУБД.
Если же вы выбрали вариант восстановления "пересоздать базу в кластере с теми же параметрами", то обновлятор на этом шаге вновь создаёт базу в кластере 1с и связывает её с рабочей базой %ИмяРабочейБазы% на сервере СУБД.
Шаг 10 (postgres)
Обновлятор удаляет исходную рабочую базу %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c с сервера СУБД, так как она нам больше не нужна.
Этот шаг можно отменить, установив галку 'Не удалять рабочую базу при восстановлении' в свойствах базы:
Эту галку имеет смысл устанавливать, если вы хотите лично контролировать результаты восстановления резервной копии и только затем самому удалять исходную рабочую базу %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c.
Что из себя представляет созданная резервная копия
Обновлятор создаёт резервную копию PostgreSQL следующей командой:
С подробной документацией и ключами к команде pg_dump можно ознакомиться здесь.
Формат plain выбран по следующим причинам:
- на выходе получается обычный sql файл, который, при его выполнении в чистой базе, воссоздаёт исходную базу
- все другие форматы являются теми же самыми sql файлами, но пожатыми специальным образом для специальных целей; обновлятору это ни к чему, так как он сам умеет сжимать получившийся архив, если вы устанавливаете соответствующую галку в свойствах базы
- формат plain является предпочтительным при проблемах с восстановлением базы из архива или повреждением самого архивного файла, так как его легко прочитать и отредактировать
- формирование архива в формате plain требует меньше ресурсов сервера СУБД
Чтобы восстановить резервную копию в формате plain не нужно использовать утилиту pg_restore. Она предназначена для других форматов архивов и фактически сначала разархивирует резервную копию в plain формат, а затем выполняет её в базе через psql.
Вам нужно сразу выполнять (через утилиту psql) резервную копию в формате plain в чистой базе из шаблона template0 (это должна быть чистая база в субд, созданная не через 1с).
Обновлятор умеет это делать автоматически.
Если же хотите сделать это вручную, то создайте чистую базу (через тот же pgAdmin из шаблона template0), а затем выполните вот этот скрипт для восстановления резервной копии в эту базу:
Как разрешить (или запретить) восстановление резервной копии в НЕ пустую базу
Для PostgreSQL, обновлятор, по умолчанию, запрещает восстановление резервной копии СУБД в не пустую базу 1с.
База считается не пустой, если в конфигурации есть хотя бы один справочник или документ или регистр или план счетов . и так далее. Обновлятор проверят это программно, подключившись к базе через внешнее соединение.
Это сделано в целях безопасности, чтобы по неопытности пользователь не смог затереть рабочую базу.
Если же нужно разрешить восстановление архива прямо в рабочую базу, зайдите в свойства базы и поставьте галку "Разрешать восстановление в не пустую базу":
Как изменить формат архива?
По умолчанию обновлятор выгружает резервную копию в формате plain.
При необходимости вы можете изменить формат на custom:
В этом случае восстанавливать такой архив нужно будет при помощи утилиты pg_restore (если вы делаете восстановление через обновлятор он определит тип архива и правильный способ восстановления сам).
Подробнее про форматы архивов вы можете почитать в документации к утилите pg_dump.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Вывод в windows-проводнике названия баз в каталоге кластера 1С и каталогов локального кэша и настроек пользователя. Используется создание файла desktop.ini, который автоматически размещается в подкаталогах кластера 1С. Теперь станет немного проще определить прямо в windows-проводнике, что, к примеру, каталог fd531400-428c-41c0-954f-b910bb5cc552 это именно база ERP.
Возможно, существует много обработок которые анализируют файл 1CV8Clst.lst, выводят из него данные в человеческом, позволяют удалить каталоги несуществующих баз, предоставляют другие сервисные возможности и т.д. Да что там говорить, я и сам когда-то в качестве развлечения тоже делал различные варианты парсера этого файла.
Однако что интересно, я не смог найти на Инфостарте упоминания файла desktop.ini или уникального идентификатора .
После успешного тестирования этой идеи я решил создать обработку, которая максимально упростила бы этот процесс и привнесла в него возможности произвольной настройки. В итоге получилось следующее:
- выбираем место выполнения кода (клиент или сервер).
- выбираем или указываем каталог кластера 1С (с учётом контекста; помним что выполнение возможно на клиенте и на сервере). Например каталог "C:\Test" при работе с сервера и "\\Server1C\C$\Test" при работе с клиента это суть одно и то же, вопрос только в авторизации доступа.
- нажимаем "Создать desktip.ini". После этого:
- проверяется доступ к каталогу.
- считывается и парсится файл 1CV8Clst.lst.
- считываются подкаталоги кластера.
- в каждом подкаталоге создаётся файл desktop.ini, формирующийся по заданному шаблону, используя данные из 1CV8Clst.lst и любой код на языке 1С.
- теперь в windows-проводнике каталога кластера можно отобразить колонки, заполненные нашими данными. Данные могут появиться не мгновенно, но в пределах десятка секунд.
Информации о desktop.ini довольно мало, и иное его использование (кроме задания тех свойств про которые я упоминал) у меня не получилось. Даже свойство "Комментарий" почему-то не работает, не говоря уже о более экзотических вариантах типа установки индивидуальной иконки для папки (хотя описано и такое, и ещё куча прочих). Однако лёгкая возможность настройки произвольного шаблона создания файла даёт возможность поэкспериментировать самостоятельно.
Читайте также: