Каким образом можно обеспечить конвертацию базы из файл серверного варианта к клиент серверному

Обновлено: 01.07.2024

В статье я расскажу о том, зачем и как мы реализовали архивирование баз данных в dt в режиме онлайн без отключения сеансов пользователей.

Большинству компаний, у которых есть собственный IT отдел, сервера и статичный перечень рабочих баз, вполне может хватать и стандартных средств онлайн архивации средствами выбранного ими SQL сервера. В этом случае возникает только одно неудобство: Чтобы развернуть такую базу хотя бы в копию, нужен работающий SQL сервер, желательно не тот, где развернута рабочая база, также нужны навыки работы с SQL сервером. В общем, этот вариант, замечательный для IT службы, не очень удобен для программистов 1С, которые для разработки очень часто разворачивают файловые варианты баз.

В силу ориентированности нашего датацентра на партнеров (программистов 1С), которые находятся в нашем облаке и особенностей реализации самого облака мы реализовали такую возможность. Итак что для этого понадобилось и как работает архивирование онлайн.

Мы рассматривали несколько вариантов реализации бекапов в онлайн.

Один из рассмотренных вариантов — это воспользоваться средствами самого SQL, pgdump или pg_basebackup. Например:

Создадим дамп базы данных по имени, в файл

Создадим новую базу base-backup

Зальем наш дамп базы из файла в созданную только что базу

Но этот вариант и другие, которые требуют копирования большого количества данных, мы сразу забраковали по следующим причинам:
Если база большого размера, то

  1. Процесс дампа значительно нагружает систему.
  2. Нужно довольно много дорогостоящего места на дисках, где распологаются SQL сервера.
  3. В наших кластерах, где сотни информационных баз, использование значительных ресурсов для бекапов очень расточительно.

И мы разработали следующий алгоритм бекапов, который полностью нас устроил:

Postgresql в среде виртуализации.

Среда виртуализауции построена на базе системы linux.

Файловая система среды виртуализации поддерживает снапшоты и работает по COW технологии

1. Сервера PostgreSQL развернуты на файловой системе с поддержкой COW (CopyOnWrite). В вашем случае это может быть вtrfs или zfs. (Зависит от предпочтений linux или freebsd).

В нашем случае откомпилированный под freebsd postgresql на zfs показал лучшую производительность, чем под linux.

Это дает возможность сделать мгновенный снимок блочного устройства практически с нулевыми затратами.

Поэтому на первом шаге мы выполняем SQL команду в нужной нам базе:

Таким образом сбрасывая на диск все завершенные транзации PostgreSQL

И сразу после этого создаем снапшот системы, например:

У нас процесс автоматизирован, поэтому время между CHECKPOINT и снапшотом составляет доли секунды. Таким образом мы получаем клон файловой системы PostgreSQL на момент времени.

2. На следующем шаге мы должны превратить наш диск в vm qemu, lxc или jail freebsd.

Поскольку диск уже существует, то нам остается только сгенерировать конфигурационный файл для нашей машины, что также делается практически мгновенно, если процесс автоматизирован. Если вы используете KVM виртуализацию, не забудьте поместить новую виртуальную машину или в изолированную виртуальную сеть или vlan, поскольку после старта у нее будет такой же адрес как и у оргинального postgresql.

3. Далее процесс уже вполне понятен. На сервере 1С мы создаем новую базу и указываем новый postgresql сервер. (Программно можно через RAS ). Чтобы снизить нагрузку на оборудование и сделать процесс бекапа наименее заметным для пользователей, лучше всего для целей бекапов держать отдельный сервер 1С на отдельном оборудовании, на котором не работают пользователи.

4. Подключаемся конфигуратором и выгружаем базу в dt.

5. Уничтожаем созданную базу на сервере 1С, виртуальную машину Postgresql и затем созданный клон и снапшот.

Рекомендации по организации резервного копирования информационной базы

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

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

В зависимости от варианта работы 1С:Предприятия (файловый или клиент-серверный), можно рекомендовать следующие способы создания резервной копии информационной базы:

При использовании файлового варианта 1С:Предприятия 8 можно организовать процесс создания резервной копии информационной базы путем простого копирования файла 1CV8.1CD в отдельный каталог или с использованием программного обеспечения для резервного копирования и восстановления данных. Следует учитывать, что для обеспечения целостности и согласованности данных во время создания резервной копии, работа пользователей с информационной базой должна быть запрещена, однако время, необходимое на создание резервной копии существенно меньше, чем при использовании выгрузки информационной базы в файл. При использовании клиент-серверного варианта 1С:Предприятия 8 появляется возможность создания резервной копии информационной базы средствами СУБД. Например, SQL Server позволяет выполнять резервное копирование данных в то время, когда база данных находится в многопользовательском режиме и доступна для всех пользователей.

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

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

Кроме этого положительным моментом является то, что при использовании перечисленных способов, можно применять различные специализированные программные средства для создания резервных копий.

Резервное копирование базы 1С:Предприятия может осуществляться несколькими способами, самый универсальный — это выгрузка информационной базы в режиме Конфигуратора.

Резервное копирование штатными средствами 1С:Предприятия, загрузка/выгрузка информационной базы в файл

Достоинства данного способа:

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

Недостатки данного способа:

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

Выполнение данного способа с помощью Effector saver: Архивирование средствами 1С:Предприятие 8

Прямое копирование базы данных 1С:Предприятия

Достоинства данного способа:

Недостатки данного способа:

  • перед выполнением резервного копирования, для обеспечения целостности и согласованности данных, рекомендуется завершить работу с 1С.

Выполнение данного способа с помощью Effector saver: Архивирование произвольных данных

Резервное копирование информационной базы средствами СУБД

В случае клиент-серверного варианта работы 1С:Предприятия рекомендуется создавать резервные копии информационной базы средствами СУБД (MS SQL, PostgreSQL).

Достоинства данного способа:

  • возможность резервного копирования без монопольного режима. Перед запуском резервного копирования не требуется завершать работу всех пользователей в системе;
  • быстрый процесс создания резервной копии;
  • быстро развертывается резервная копия.

Недостатки данного способа:

  • большой размер выходного файла;
  • для MS SQL невозможно создать устройство резервного копирования, расположенное на сетевом диске, поскольку видны только локальные, физически подключенные диски.

Выполнение данного способа с помощью Effector saver: Архивирование произвольных данных

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

С рекомендациями 1С по организации резервного копирования информационной базы Вы можете ознакомиться по данной ссылке: Рекомендации по организации резервного копирования информационной базы

Здравствуйте.
Очень странная ситуация. Есть куча обработок по загрузке из всяких файлов. Работали эти обработки в файл-серверной базе нормально. Перенесли базу в клиент-серверный вариант и они перестали видеть загружаемый файл. Т.е. ошибка чтения по причине Возникла ошибка при чтении данных :
>: Ошибка при вызове метода контекста (ОткрытьФайл): Каталог не обнаружен 'F:\ллл\NEVA_2018_04_24_2018_04_24 .xml'
И еще не попадаю отладчиком во все серверные процедуры.

(0) пипец
как можно со стажем 8 лет не знать про учетную запись, от которой запущен rphost и про ключ отладки в строке запуска службы

И ничего странного. Стандартные грабли, на которые наступают все, кто не понимает разницу между файл-серверным и клиент-серверным режимами работы. Особенно то, что в клиент-серверном варианте далеко не весь код выполняется на компе пользователя.
Разумеется. Ведь наверняка сервер 1С запущен без нужного для этого ключика.
Вы хоть что-нить читали про особенности этих режимов и о действиях, которые надо выполнить при переходе с одного на другой?

А у меня таблица значений в процедуре. Не могу на клиенте читать. А на сервере не получится?

Страшно.
Гагарин в современной реальности бы в космос не долетел.

(4) сетевой путь укажи, абсолютный, который одинаков будет на клиентской машине и на сервере

Жаль конечно. Придется все обработки на новый фасончик переписывать.

(6)А теперь получилось. Не с того имени заходили.
Всем спасибо.

(9) лучше все-таки переписать все обработки на новый фасончик. А то так и будете по граблям ходить)

(13) Некошерно по-старинке всё на клиенте делать в клиент-серверной базе.

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

(14) Иногда на клиенте поработать с файлом вообще единственный способ, а иногда это более приемлемо, т.к. тащить файл на сервер может быть затратнее

Или тут в ветке не про это терки, а про выбор пути к файлу и далее передача кода на сервер, который этот путь не видит? )

Ситуация очень простая. Нужно в базу загрузить информацию из файла. Например хмл. На форме пользователь выбирает этот файл кнопкой выбора и нажимает Прочитать. Выбирается файл, естественно, на клиенте. А потом надо его открыть и начать читать. Т.к. таблицы значений на клиенте отсутствуют, то открываю я этот файл НаСервере, читаю и записываю в таблицу значений. Конечно вместо ТЗ можно было бы использовать табличные части обработки (если их завести предварительно), но тогда нужно кучу обработок переделывать. Вот и все.

Читаем на клиенте файл в строку и отправляем эту строку на сервер,а уже на сервере из строки собираем xml файл
только вот если файл ну уж очень большой,то как ни крути,его сначала придется загрузить в память
есть,конечно,вариант чтения на клиенте,но после каждого тега же на сервер не побежишь

(0) Если у учетной записи, под которой запущен сервер 1С, права на эту папку?

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

Файловый вариант 1С: плюсы и минусы

file-server-1c

Наиболее простой и дешевый вариант развертывания платформы 1С:Предприятие 8 — файловый вариант. Многие ошибаются, рассказывая, что он не подходит для работы в сети несколькими пользователями. Отнюдь, этот вариант работы может быть использован как для работы одним пользователем без сетевых версий, так и для совместного использования до 5 клиентов. Для настройки работы файлового варианта 1С можно использовать простой компьютер, на котором "расшарен" каталог (открыт доступ к общей папке), в котором собственно и находится один единственный файл с базой данных. Естественно, этот компьютер должен быть постоянно включен, чтобы пользователи имели доступ к базе. Второй не очень приятный момент — это полный доступ всех работающих с программой пользователей к этой общей папке, т. е. каждый из них может не только работать с 1С, но и имеет возможность скопировать эту базу себе на компьютер (флешку, съемный диск и т. д.) или просто удалить. Отсюда напрашивается вывод о невозможности контроля сохранности данных в большой компании. И конечно же, нельзя не сказать, что при использовании файлового варианта развертывания 1С, все вычисления и операции производятся на компьютере клиентов, поэтому рабочие станции должны иметь хороший запас вычислительной мощности: мощный процессор и достаточный объем оперативной памяти. А это по нынешнему курсу доллара, не каждый себе может позволить, учитывая, к тому же, что с выходом каждой новой версии программы требования к аппаратной части становятся только выше.

Подключение узлов сети для работы в файл-серверном варианте 1С

Существенным же плюсом можно считать практически нулевые затраты на серверную часть — ей может служить простой мощный компьютер, на котором, например, работает главный бухгалтер с хорошим жестким диском и сетевой картой пропускной способностью 1ГБит/с. Даже обычные (не серверные) операционные системы обеспечат до 5 подключений клиентов 1С. Также достаточно просто осуществляется и резервное копирование, которое, кстати, в последних версиях может быть настроено штатными средствами самой 1С.

Клиентские подключения к файловой 1С

Схема подключения узлов сети при файл-серверном способе подключения 1с с веб-сервером

Для работы пользователей с файл-серверным вариантом 1С:Предприятие возможны 2 варианта: "толстый клиент" и веб-клиент. Первый вариант — самый простой, именно он используется в локальных версиях и не достоин большого внимания. А вот при использовании веб-клиента необходимость в установке программного обеспечения практически отсутствует. Для работы в этом режиме потребуется только совместимый веб-браузер, который можно запустить практически на любой платформе и даже на планшете через 3G-Интернет. Конечно, придется немного усложнить настройку, т. к. потребуется веб-сервер, помимо файлового, зато это принесет массу плюсов:

  • работа на любом устройстве и любой операционной системе (MacOS, Linux, Windows, планшет с Android и т.д);
  • работа из любого места, где есть Интернет (конечно при соответствующей настройке);
  • отсутствует необходимость установки и обновления программного обеспечения на рабочих станциях.

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

Общие моменты развертывания файл-серверной 1С

Нельзя обойти и вопрос лицензирования: для подключения каждого клиента в не зависимости от типа подключения, помимо самой программы, необходимо приобрести клиентскую лицензию на доступ одновременно работающего пользователя. Это может быть как аппаратный ключ (USB-токен), так и программный ПИН-код.

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

Читайте также: