56
«ИнтернетПоддержкаПользователейОшибкаДоступаКИнтернету»).
При запуске конфигурации 1С предлагает соединиться с сервером 1С и
при наличии соединения устанавливает настройку в хранилище общих
настроек. Для выключение данной функции необходимо сбросить
настройки автоподключения к интернет-поддержке с помощью
создания внешней обработки;
Обработка «Панель функций», при закрытии записывает значение
параметра «ТекущаяСтраницаПанелиФункций» регистра сведений
«НастройкиПользователей». Для выключение данной функции
необходимо отключить настройку
«ОткрыватьПриЗапускеПанельФункций» для пользователя, добавить
специальную роль ReadOnly. Выполнение кода будет производиться
только в том случае, если роль не соответствует заданной.
Для начала проверим возможность работы информационной базы 1С с
использованием AlwaysOn SQL 2019 и осуществим процедуру проверки
отработки отказа. После проведём исследование работы реплики ReadOnly.
Для корректного проведения процедуры проверки нам будет достаточно
привести две базы данных.
В качестве информационной базы 1С воспользуемся типовую
конфигурацию «1С:Предприятие». Для начала необходимо провести
подготовительную работу и выполнение настройки серверов, баз данных и
групп доступности. Итак, создаем на сервере ServerSQL2 базу данных Dbtest2,
после выполнения первого шага необходимо на этом же сервере создать
группу доступности AG_test2, где будет находиться эта же база данных,
рисунок 6:
57
Рисунок 6. Обозреватель объектов Microsoft SQL Server
Таким же образом проводим манипуляции с базой данных Dbtest1 на
сервере ServerSQL1. Далее на сервере приложений «Server1C» регистрируем
две информационные базы, рисунок 7 и 8:
Рисунок 7. Параметры информационной базы IBTest2
58
Рисунок 8. Параметры информационной базы IBTest1
При подключении с клиентского компьютера с помощью 1С:
Предприятия к обеим информационным базам запускаем в обоих сеансах 1С:
Предприятие создание какого-либо долго обрабатываемого отчета, и не
дожидаясь окончания его создания пробуем смоделировать отказ сервера в
группе доступности AGtest2, показано на рисунке 9:
Рисунок 9. Окно отработки отказа сервера
59
При выборе опции “Отработка отказа” система выдаёт предупреждение,
информирующее нас об ошибке в информационной базе (рисунок 10), которая
находится в группе доступности, в которой моделировался отказ:
Рисунок 10. Окно ошибки выполнении операции с информационной
базой
При этом вторая база данных остаётся в рабочем состоянии. Заново
запускаем ту базу данных, при работе с которой была выдана ошибка, после
перезапуска программа работает корректно. Можем заметить, что основной
репликой в этой группе доступности становится сервер ServerSQL1.
Скорее всего, если мы будем изменять, а не производить чтение,
например, проводить документ, то результат скорее всего откатится в
транзакции по ошибке. То есть отказоустойчивость не распространяется на
выполняющиеся запросы.
Теперь выполним работу с базой ReadOnly. Чтобы подключиться из 1С
к данной базе данных нужно сделать несколько вещей: довести до ума
конфигурацию 1С так, чтобы не производилась запись в базу данных во время
работы, и настроить подключение информационной базы.
Что относится к подключению к базе SQL, то тут все намного легче. Так
как 1С:Предприятие не использует новый синтаксис строки подключения к
MSSQL 2019, придётся прописать подключение к базе данных в режиме
ReadOnly напрямую (рисунок 11):
60
Рисунок 11. Окно подключения в режиме ReadOnly
Достаточно часто специалисты осуществляют резервное копирование с
помощью выгрузки информационной базы в dt-файл, что абсолютно
неправильно. Выгрузка необходима для переноса информационных баз
данных между разными средами, например, при смене системы управления
баз данных, но не для резервных копий.
Так же одно из неверных решений для резервного копирования – это
копирование файлов базы данных MS SQL Server (mdf и ldf), что тоже неверно.
В приведённых случаях нет возможности произвести копирование, не
прерывая работы сотрудников. Полученная резервная копия, учитывая сжатие
занимать большое количество места на жёстких дисках, а это увеличивает
стоимость хранения данных, к тому же нет возможности восстановить
состояние системы на необходимый момент времени.
Далее мы рассмотрим способ, который позволит выполнить резервное
копирование, не прерывая работу сотрудников, создавать резервные копии
меньшего размера и тратить меньше времени.
Рассмотрим требуемый минимум информации, которого будет хватать
для настройки резервного копирование, поддерживаемое большинством ИС.
Так же разберём способы, с помощью которых станет возможным
61
организовать восстановление системы почти на любой момент времени, в том
числе и на момент сбоя.
При работе с Microsoft SQL Server 2019 используется три основных типа
резервных копий: полная резервная копия, разностная резервная копия и
журнал транзакций.
Полная резервная копия создаёт полную копию базы данных,
включающую в себя файл данных, а также файл журнала транзакций. Это один
из самых простых и понятных типов резервного копирования. Обычно полное
резервное копирование выполняется примерно 1 раз в неделю. Чем больше
база данных, тем дольше выполняется копирование и тем больше размер
резервной копии.
Предположим, рассматриваемая база данных занимает 50 ГБ дискового
пространства. Каждый день, даже в выходные, база данных увеличивается на
5 ГБ. Для упрощения расчётов считаем, что старые данные не изменяются, а
только записываются новые. В нашем случае резервное копирование
проводится два раза в неделю, в субботу и во вторник ночью, создаётся полная
резервная копия без сжатия.
Не стоит забывать, что в резервную копию так же попадают данные,
которые были на момент окончания процесса копирования. Даже в том случае
если при создании резервной копии в базе данных что-то было изменено, то
данное изменение в создаваемую резервную копию все равно попадет. Также
учитываем, что в копию включается лишь то изменение, которое успело
полностью завершиться до окончания формирования резервной копии.
Можно не учитывать в какой момент времени началась транзакция,
важно, чтобы она успела закончиться до того, как сформируется резервная
копия.
Если во время процесса создания резервной копии произойдёт сбой, то
для восстановления базы данных необходимо загрузить лишь один из файлов
полной копии и восстановить базу данных на начало субботы, либо на начало
вторника.
62
В случае если сбой произойдёт между копиями, созданными в субботы
и вторник, то данные будут утеряны. Из этого следует вывод, что присутствует
интервал потери данных длиной трое суток, что для нас недопустимо большой
срок.
Можно рассмотреть создание полных резервных копий ежедневно, но
данный вариант можно применить только в том случае, когда размер всех баз
данных занимает относительно немного места на дисковом массиве и в нашем
распоряжении достаточно дискового пространства. Рассмотрим вариант,
когда базы данных очень большие. К сожалению, это может вызывать целый
ряд проблем:
Размер полной резервной копии сопоставим с размером базы (без
использования возможности сжатия), для этого необходимо большое
количество дискового пространства для его хранения.
Создание полной резервной копии занимает достаточно много времени.
Создание полной резервной копии сильнее нагружает оборудование.
Дифференциальная резервная копия используется для избегания
сталкивания с вышеописанными проблемами. В данном случае в резервные
копии будут помещены только те данные, которые были изменены с момента
последнего полного резервного копирования. Если сделать несколько
разностных резервных копий, то более поздние копии будут включать в себя
данные предыдущих.
Так же, как и полное резервное копирование, разностное копирование
сохраняет данные тех транзакций, которые успешно завершились пока
формировалась сама резервная копий.
За счет того, что разностные копии хранят только измененные данные,
они занимают гораздо меньше места и создаются намного быстрее полных
копий.
Без наличия полной резервной копии, создание разностной копии
бессмысленно, так как в разностной копии хранится дельта данных. Для
применения дельты, необходима опорная точка, которой и является полная
63
резервная копия.
При использовании разностного резервного копирования интервал
потери данных сократился до одного дня. Если сбой резервного копирования
произойдёт в вечернее время , то все данные, изменённые или добавленные за
этот рабочий день, будут утеряны.
С помощью резервной копии журнала транзакций появляется
возможность делать копии каждые несколько минут. Данный вид резервного
копирования позволяет производить резервное копирование журнала
транзакций (резервное копирование лога), также создается резервная копия не
самих данных, а копия журнала транзакций. Такое резервное копирование
будет осуществляться быстрее и занимает гораздо меньше места на дисковом
пространстве.
Файл резервной копии журнала транзакций не содержит сами данные, а
обладает информацией о том, какие изменения были осуществлены в базе
данных.
Обладая этой информацией, открывается возможность восстановить
состояние базы данных на необходимый момент времени. Журнал не
содержит ненужную для восстановления данных информацию.
Резервное копирование лога возможно только в том случае, если у базы
данных установлен полный режим восстановления. Во всех базах данных 1С
по умолчанию установлен полный режим восстановления, это значит, что
доступно резервное копирование лога.
Используя полную модель восстановления, увеличение размера
резервной копии журнала транзакций зависит напрямую от изменённых
данных. При осуществлении резервного копирования журнала, он
уменьшается в размере. За счет этого размер резервной копии лога
уменьшается, за счёт чего на его создание тратится меньше времени.
Резервная копия журнала транзакций обладает информацией о том какие
были изменены данные с момента последнего резервного копирования
журнала транзакций, а не с момента создания полной резервной или
64
разностной резервной копии. Например, если делать резервное копирование
журнала каждый час, то его размер будет примерно одинаков, т.к. резервное
копирование журнала за второй час не будет включать в себя данные за первый
час, а это значит, что размер резервное копирование будет минимальным.
Имея резервные копировании логов и полную резервную копированию
базы данных, имеется возможность восстановить состояние системы на
необходимый момент времени.
Последовательность восстановления резервного копирования журнала
очень важна.
Когда речь идет о резервном копировании лога, появляется такое
понятие как цепочка журналов транзакций.
Цепочка журналов транзакций – это непрерывная последовательность
резервных копий журнала транзакций. Необходимо чтобы резервные копии
журнала следовали друг за другом строго следовать друг за другом. Если в
данной цепочке не будет хотя бы одной копии журнала, то цепочка копий
журнала прервется, это означает, что данные из копии можно будет
восстановить только до места обрыва цепочки резервных копий журнала.
Цепочка резервных копий журналов начинается с полной резервной
копии базы данных. Обычно новая цепочка журналов начинается, только
когда создается первая резервная копия базы данных или после переключения
модели восстановления с простой на полную или на модель с неполным
протоколированием.
Существующая цепочка журналов прерывается, если выбрана
перезапись существующих наборов резервных копий в момент создания
полного резервного копирования.
Для того, чтобы обладать возможностью восстановления базы данных
на момент сбоя, необходима неповрежденная цепочка резервных копий
журналов. Непрерывная последовательность резервных копий журналов
должна следовать до точки сбоя.
Следует понимать, что сам по себе резервное копирование лога
65
бесполезен. Имея только резервные копии журнала, не представляется
возможным восстановление базы данных, для этого нужен хотя бы одна
полная резервная копия, при этом цепочка журналов транзакций от полного
резервного копирования до последнего резервного копирования журнала
должна быть непрерывной.
Несмотря на выполнение резервного копирования лога каждые 20
минут, внесённые за несколько минут до сбоя данные, все равно будут
утеряны.
Резервная копия заключительного фрагмента журнала – это создание
резервной копии лога базы уже после сбоя. В пример можно привести так
ситуацию, как вышедший из строя диск, на котором хранились необходимые
данные. В резервную копию конечного фрагмента входят данные журнала,
которые не были включены в предыдущую резервную копию лога.
В случае сбоя, если журнал не пострадал, можно восстановить
необходимые данные на момент сбоя. Это означает, что данные не будут
утеряны, кроме транзакций, если они были открыты на момент сбоя – по ним
будет сделан откат.
В том случае, если в результате сбоя файл журнала был поврежден, то
данные восстановлению подлежать не будут. В этом случае необходимо
восстановить последнюю резервную копию логов. Исходя из этого лучше
всего хранить данные на дублированном носителе, а в рамках Организации на
резервном сервере.
Для восстановления базы данных на время, максимально близкое к
моменту сбоя, нужно выполнить некоторые действия:
восстановить полный резервное копирование, ближайший по времени к
моменту сбоя;
сделать резервную копию заключительного фрагмента журнала;
восстановить поочередно резервную копию логов с момента
разностного резервного копирования до момента сбоя;
восстановить разностный резервное копирование, ближайший по