Введение
В статье рассматривается проблема обновления платформы 1С для особо крупных баз 1С (сотни Гб, Тб), когда требуется длительная конвертация базы 1С в формат новой платформы. Например, обновление с 1С8.2 на 1С 8.3.Описанное справедливо также и для случая, когда требуется отключить режим совместимости в конфигурации 1С.
Разбирается решение с применением технологии DBReplication, которое позволяет гарантированно и надёжно осуществить эту нетривиальную задачу.
Проблематика
Для особо крупных и/или высоконагруженных баз данных обновление платформы 1С зачастую сопряжено с рядом сложностей и рисков. Основные проблемы следующие:
- Размер базы. Размер базы 1С очень велик (сотни гигабайт, терабайты), поэтому перевод базы на новую версию 1С 8 или отключение режима совместимости занимает много часов или дней (происходит конвертация данных), а иногда эта операция и вовсе не может быть выполнена полностью типовыми средствами;
- Работа 24х7. Пользователи работают в режиме 24х7, поэтому нет технологических окон достаточной продолжительности, чтобы выполнить переход;
- Неработоспособность. После перехода, если его все же удалось выполнить, существует риск того, что какие-то функциональные блоки окажутся неработоспособными.
Типичный пример – это обновление платформы с 1С 8.2 на 1С 8.3 без режима совместимости.
Риски неработоспособности
С длительностью конвертации проблематика в целом понятна, не будем ней заостряться. А вот с рисками неработоспособности кому-то ситуация может быть не очевидна, поэтому немного поясним. Дело в том, что зачастую обновление платформы 1Ссопряжено с множеством изменений в самых разных аспектах функционирования 1С. При конвертации непосредственно самой конфигурации1С эти изменения проверяются и учитываются автоматически. Однако вне зоны действия этих проверок остаются такие вещи как внешние обработки, динамически формируемый программный код и т.п. Адаптацию этих элементов системы приходится выполнять вручную. Именно они и представляют зону риска, т.к. включается человеческий фактор, что-то может быть упущено на этапе подготовке к переходу. Конечно, скорее всего упущения, если и будут, то коснутся какого-то некритичного функционала, и могут быть достаточно оперативно исправлены. Тем не менее, нельзя не указать этот фактор в рассматриваемой здесь задаче.
Пример к рассмотрению
Рассмотрим на примере.
Допустим, у нас имеется большая (1 Тб) высоконагруженная БД 1С 8.2, пользователи (несколько сотен или тысяч) работают в режиме 24х7 или близко к тому. Изадача заключается в том, чтобы осуществить переход на платформу 1С 8.3 без режима совместимости.
Допустим также, что на стенде пробная конвертация базы типовыми средствами успешно проходит до конца (акцентируем: для огромных баз это далеко не всегда удаётся), но весь процесс длится непрерывно 5 суток. А максимальное технологическое окно с отключением пользователей, которое может позволить бизнес – это 6 часов в выходные 1 раз в месяц. Останавливать базу на 5 суток возможности нет категорически.
Таким образом, задача кажется неразрешимой:
- Конвертировать непосредственно продуктивную бд нет возможности из-за неприемлемой длительности.
- Конвертировать копию базы бессмысленно, т.к. за 5 суток накопится гигантское количество расхождений с продуктивной бд, которые синхронизировать имеющимися средствами крайне сложно, или вовсе невозможно, тем более с учетом изменения структуры бд.
Решение: клон БД 1С + Репликация
Решение всё же есть. Мы предлагаем следующую методику с применением технологии DBREPLICATION.
Укрупнено план мероприятий следующий.
- Разворачивается копия базы 1С, назовем её «Новая бд». Настраивается быстрый обмен посредством DB REPLICATION между парой баз: «Старая БД»->«Новая БД». Изначально обе базы на исходной платформе 1С 8.2.
- Пользователи работают в Старой БД, а в Новую возможность входа для них закрывается.
- В Новой БД запускается процесс конвертации данных на новую платформу 1С.
- Если того требует ситуация, мы с помощью специальных приемов и программных средств ускоряем процесс конвертации. Эффект ускорения в зависимости от специфики БД лежит в широком диапазоне: в одних случаях это десятки процентов, а в других ускорить удаётся в десятки раз! Чуть подробнее об этом ниже.
- Пока происходит конвертация Новой БД, сколько бы она ни длилась, все изменения данных из Старой БД накапливаются в очереди обмена в служебной базе Дистрибутор (эта специальная база, входящая в состав программного комплекса DB REPLICATION).
- После завершения конвертации Новой БД все скопившиеся изменения, а также все новые изменения, автоматически оперативно доставляются в неё посредством DB REPLICATION. Тем самым Новая БД синхронизируется со Старой БД.
- Важно отметить, что при переходе между версиями платформы 1С изменения структуры БД могут быть очень существенными. Тем более при переходе с 1С 8.2 на 8.3.Поэтому обмен данными между базами 1С на разных платформах является весьма нетривиальной задачей. Но мы умеем это делать, и в рассматриваемой методике предполагается реализация специального интеграционного модуля под конкретную комбинацию платформ (в том числе8.2 <-> 8.3).
- В назначенное время осуществляется переключение пользователей:
- Пользователи и прочие механизмы переключаются в Новую БД (платформа 1С 8.3);
- Одновременно переключается в обратную сторону направление быстрого обмена DB REPLICATION: «Новая БД» -> «Старая БД». Тем самым Старая БД поддерживается в синхронном состоянии. Цель сохранения Старой БД - подстраховка, подробнее об это ниже.
- Через некоторое время, когда все риски сняты и потребность в Старой БД отпала, она просто удаляется, а DB REPLICATION деинсталлируется.
Подзадачи в составе методики
Выделим три основные технические задачи, реализуемые в рамках этой методики:
- Обеспечить высокоскоростную синхронизацию данных между Старой и Новой БД с помощью DB REPLICATION.
- Обеспечить при обмене автоматическую конвертацию данных из формата Строй базы в Новую и наоборот.
- При необходимости обеспечить ускорение первоначальной конвертации базы в новую платформу 1С.
Далее рассмотрим эти подзадачи.
Зачем скоростной обмен, какова роль DB REPLICATION?
- Конвертация БД без простоя системы. Наличие скоростного обмена позволяет выполнить первоначальную конвертацию базы в новую платформу не на оригинале базы, в которой работают пользователи, а на копии. Не требуется длительное технологическое окно с отключением пользователей. Конвертация копии может длиться сколь угодно долго, пользователи всё это время будут работать как обычно, нет простоя системы.
- Возможность оперативного возврата на старую бд. Уже после того как пользователи переключились в сконвертированную Новую базу, Старая база остаётся синхронной (близко к онлайн). Если в процессе работы пользователей на новой платформе 1С возникают критические проблемы, которые не удается оперативно решить «на горячую» (функциональные сбои, повышенная нагрузка, резкое падение отклика от системы и пр.), то можно оперативно, без простоя системы и без потери данных переключить всех пользователей обратно в Старую базу на прежней платформе 1С. При этом уже введённые пользователями данные утрачены не будут, т.к. DBREPLICATION их своевременно передаёт между базами. Затем можно принять меры по устранению проблемы и повторить попытку переключения пользователей в Новую базу.
Зачем конвертация данных при обмене между базами?
Проговорим еще раз: в этом параграфе речь о конвертации в процессе быстрого обмена между базами. Не путать с первоначальной конвертацией всей базы данных!
Программный комплекс DB REPLICATION в основе своей предназначен для обмена данными между базами с одинаковой структурой (гомогенная система). Поэтому, чтобы работал обмен между базами разных платформ 1С, необходимо реализовывать специальный интеграционный модуль, который обеспечил бы преобразование данных между форматами баз.
Сложность конвертации колеблется в широких пределах в зависимости от комбинации начальной и конечной версии платформы 1С. Как правило, сложность тем выше, чем дальше отстоят друг от друга начальная и конечная версия платформы 1С. В любом случае мы умеем решать эту задачу и выполняем её в рамках общего проекта.
Зачем требуется ускорение первоначальной конвертации?
Первоначальная конвертация особо крупных баз в новую платформу 1С штатными средствами может длится от нескольких десятков часов до нескольких дней. А зачастую эту операцию вообще не удается выполнить до конца.
Отсюда вытекают причины, по которым требуется ускорение этой операции:
- Либо требуется радикально сократить длительность конвертации, чтобы уменьшить тот объём изменений, который накопится за время конвертации и потребует синхронизации;
- Либо требуется добиться того, чтобы конвертация стала возможной в принципе.
Останавливаться подробно на методике ускорения не станем, этот вопрос лежит за рамками настоящей статьи. Если очень коротко, то ускорение достигается за счет 2х основных средств:
- Модификация особо крупных таблиц с применением операторов «ALTERTABLE» вместо типовой полной переливки данных (INSERT);
- Параллельные вычисления: многопоточная параллельная обработки данных.
Плюс ряд дополнительных менее значимых средств.
Краткие выводы
Предложенное решение с применением DBREPLICATION позволяет для особо крупных баз 1С:
- Основное, принципиальное:
- надёжно реализовать задачу обновления платформы 1С (в частности переход на 1С 8.3) в тех случаях, когда это не удаётся сделать типовыми средствами и/или иными средствами;
- устранить или свести к минимуму стресс и риски, сопровождающие обновление платформы 1С.
- И в частности:
- наше решение предоставляет подстраховку - возможность оперативного отхода назад на исходную версию платформы 1С без потери введенных данных и без простоя системы;
- в случае первой неудачи попытку перехода можно повторять многократно;
- сократить общую длительность первоначальной конвертации базы 1С в новую платформу.
Дополнительно о продукте DBREPLICATION – http://repltech.ru/reshenia/replikatsiya-informatsionnykh-baz/
Другие статьи по применению DBREPLICATION - http://repltech.ru/articles/
