Почему мы занимаемся миграцией больших баз 1С
Тема миграции информационных баз данных 1С с MS SQL на PostgreSQL – достаточно популярная и актуальная. Но миграция больших баз данных 1С представляет собой сложности и риски. О них и о многом другом я расскажу в этой статье. Также покажу наш подход к этому процессу и некоторые практические детали.
Кратко расскажу, почему я и моя команда этим занимаемся. Мы являемся первопроходцами в разработке технологий и решений по оптимизации производительности систем 1С, по кластеризации СУБД, по репликации данных, по блокировкам. Поэтому, когда встал вопрос, почему именно наша команда этим занимается, у нас нашлись и опыт, и решения, и подходы.
Что такое большая 1С
Сначала разберемся, что такое большая 1С. Как говорится, у кого-то щи постные, а у кого-то бриллианты маленькие. Так и в IT: какие-то компании считают, что 100–200 ГБ – это большая база данных, а какие-то компании считают несколько ТБ достаточно маленькой базой данных в своей линейке.
Чтобы не было путаницы, мы с командой выделили ряд признаков больших систем.
Первый признак – большое количество активных пользователей и большое количество запросов в единицу времени. Здесь есть сложность следующего вида: если компания и сам бизнес сильно завязаны на безотказной работе IT-решений, то любой сбой в них приводит к потере доходности, потере темпов роста. Поэтому отдел разработки обычно трепетно относятся к подобным системам.
Второй признак – большой размер. Здесь, конечно, возникают сложности в обслуживании, обеспечении отказоустойчивости, изменении структуры базы данных. Наверняка многие с этим сталкивались.
Третий признак – большой разработанный функционал. Это могут быть человеко-годы и даже больше. Более того, мы встречали ситуации, когда какой-то функционал разработан, разработчики давно уволились, его обходят стороной: работает – и хорошо. Какие сложности возникают при работе с развитым функционалом? Невозможно с использованием функционального тестирования протестировать все блоки. Обычно есть компромисс: тестируют только критически значимые операции.
Четвертый признак – интеграция. Подобные системы могут быть интегрированы с логистическими, финансовыми системами, с сайтом – с чем угодно. Это тоже их признак.
Большие системы могут обладать одним признаком, либо всеми сразу. Но, как правило, среди всех инсталляций большие системы – это не более одного процента.
Зачем бизнесу переходить на PostgreSQL
Кратко разберем, зачем бизнесу переходить на PostgreSQL. Мы условно разделили причины на три блока. Понятно, что их можно по-разному переформулировать.
Первая и основная причина – законодательные требования. У нас есть множество госорганизаций, множество организаций с госучастием. Даже бизнес, если он находится на критически важных направлениях, по закону должен перейти на PostgreSQL, на российское ПО.
Вторая причина – в России очень сильная инженерная школа: математики, инженеры, множество IT-вендоров, которые дорабатывают решения, создают свои инсталляции, свои релизы СУБД. Они адаптированы к российской специфике, к российским системам. Это очень хороший повод перейти на систему, которая работает лучше, чем какая-то универсальная.
Третья причина – независимость и технологический суверенитет. Все мы знаем, что в силу политических и прочих обстоятельств зависеть от зарубежного вендора, от лицензии зарубежного вендора – себе дороже. Будущее непонятно.
Хотелось бы отметить еще две причины, которые обозначены в кавычках. Для больших систем это, конечно, не является причиной: требуются затраты и на сопровождение, и на лицензии. Но теоретически есть свободное российское ПО. Особенно для маленьких систем это может быть значимо, для больших – не так.
Какие риски возникают при миграции
Представим, что вы руководитель IT-подразделения и перед вами стоит проблема миграции больших баз данных. Понятно, что, поскольку бизнес пронизан IT-технологиями, вы думаете о том, чтобы доход компании не рухнул. Но посмотрим со стороны техники.
Первое, что беспокоит, – функциональные отказы. Вы перешли на новую архитектуру, новую СУБД, и что-то перестает работать. Скорее всего, это будут не самые популярные операции, но где-то регламентные отчеты или какие-то нечастые операции могут перестать работать. И это бизнес волнует.
Второй риск – падение производительности. С этим точно все сталкиваются, особенно на старте любых проектов по миграции. Понятно, что от производительности зависит эффективность работы бизнеса. Если у вас резко уменьшится количество заказов, бизнесу придется нанимать новых менеджеров или заставлять их работать внеурочно. Все с этим сталкивались. Это большая проблема.
Третье: чем больше система, тем ближе она к работе 24/7 и тем меньше технологическое окно. Оно может измеряться, например, одним часом за две недели или даже одним часом в месяц. Это вполне реальный пример. И здесь у бизнеса появляется вопрос: успеем ли мы в это технологическое окно мигрировать? Ниже покажу организационные и технологические детали.
Четвертая причина – форс-мажор. Проект миграции выглядит как путь в один конец: вы ушли с MS SQL, пришли к PostgreSQL, это заняло три дня – и вдруг что-то происходит. Это могут быть не только функциональные сбои, но и любые другие: архитектурные, оборудование. Вдруг работа системы не может быть восстановлена в ограниченный срок, разработчикам требуется время, чтобы что-то подхватить. Этот форс-мажор тоже обязательно нужно отрабатывать.
Последний риск – специалисты 1С и PostgreSQL. Здесь проще: можно отправить на обучение, привлечь дополнительных подрядчиков, получить новые знания. Этот риск тоже нужно учитывать, но он достаточно хорошо купируется деньгами.
Миграция с MS SQL на PG: простой случай
Рассмотрим простейший случай: как происходит миграция баз данных 1С из MS SQL в PostgreSQL в обычной ситуации.
В технологическое окно отключаются пользователи, запускается стандартная для миграции данных в 1С утилита ibcmd. Это может быть многопоточный или однопоточный режим. Далее специалисты должны провести регламентные проверки: понять, все ли правильно мигрировало, возможно, подключить интеграции с внешними системами, получить базу, готовую к переключению.
После этого, просто меняя строку в настройках подключения 1С:Предприятие, пользователь мигрирует на вторую базу данных – PostgreSQL.
Для малых 1С здесь сложности нет. Все тривиально.
Миграция с MS SQL на PG: сложный случай
Рассмотрим, как дело обстоит с большими 1С. Начало здесь очень похоже на предыдущую ситуацию. Есть работающая база данных с пользователями. В технологическое окно начинается процесс конвертации.
Время на конвертацию, например, десятков ТБ не укладывается в ваше технологическое окно. Далее идут проверки. И здесь необходимо принять правильное решение, что со всем этим делать.
Как правило, есть несколько вариантов решения этой проблемы.
Первый вариант – расширить технологическое окно. Все сталкивались: оно расширяется за счет внеурочного времени, выходных дней, праздничных дней и так далее. То есть технологическое окно пытаются раздвинуть до максимума.
Второй вариант – ускорить процедуру конвертации. Так как утилита ibcmd многопоточная, за счет процессорных ядер можно попытаться поэкспериментировать и улучшить скорость. А если данные сохраняются на диск, то за счет скорости диска тоже можно что-то изменить и подстроить.
Третий вариант обычно не рассматривают: попытаться догнать базу PostgreSQL до данных MS SQL.
Как правило, первые два варианта используются очень активно. Третий вариант не рассматривается. Мы решили показать преимущества третьего варианта в дополнение к первым двум. Первые два все равно можно использовать.
Общий вопрос: можно ли учесть все риски и обеспечить переход таким способом?
Предварительный этап перед миграцией
Отдельно нужно сказать о предварительном этапе. В сам процесс конвертации и миграции этот процесс не входит, он предварительный. Но он очень важен для любых систем.
Вы заранее можете на тестовой базе замерить, сколько у вас будет продолжаться конвертация. Если есть возможность - создать автоматизированные тесты по функционалу, по нагрузке, можно сделать стресс-тестирование.
Все это предварительный этап. Он обязательный и им нужно заниматься. Но важно помнить две вещи.
Первое: для больших систем все протестировать нельзя. Это доказано на практике.
Второе: нагрузочные тесты нужны, они снимут первый пласт проблем, но всю картину целиком вы получите только в момент перехода.
Миграция с MS SQL на PG. Временная диаграмма
Теперь расскажу про наш подход.
Начало, как и везде: есть база данных MS SQL. Далее настраивается технология DBReplication. Что это за технология? Она позволяет сохранять транзакционные изменения пользователей в отдельную базу данных, чтобы потом эту очередь применить на PostgreSQL.
Далее одномоментно делается бэкап и начинается накопление очередей в репликационной базе данных.
Для чего мы делаем бэкап? Для того чтобы снять нагрузку с продуктива. Даже нагрузка на чтение может влиять на работу пользователей.
Проходит какое-то время. На выходе вы получаете сконвертированную базу PostgreSQL с копии. Далее мы проводим полное тестирование, верификацию. База данных готова, но она уже отстает по данным: пользователи уже что-то ввели, что-то изменили.
Получается две базы: начальная и конечная. Но конечная отстает.
С помощью технологии репликации можно прогнать очередь и применить ее к базе данных PostgreSQL. Таким образом, в определенный момент времени базы будут синхронны.
Что это дает пользователям? Дает очень большие преимущества. Во-первых, вся работа делается в рабочее время. Пользователи абсолютно не ощущают и в фоне не видят, что уже идет процесс конвертации. Если эта работа идет в рабочее время, эффективность очень хорошая: не надо тратить выходные, делать все нервно и судорожно.
Когда база уже готова и синхронно отстает на несколько секунд, в технологическое окно, размер которого уже не имеет значения, пусть это будет 30 минут, происходит переключение пользователей с одной базы данных на другую. Эта процедура очень быстрая.
В целом подход понятен. Давайте пройдем каждый этап, чтобы закрепить знания и отметить нюансы.
Этап 1. Конвертация и функциональное тестирование
Первое, на что нужно обратить внимание, – конвертация и функциональное тестирование.
Здесь хотелось бы сказать о проблематике доступности дискового пространства и скорости диска. Это встречается практически у каждого клиента, который делал миграцию: не хватает 100 ГБ. Лучше определять диск с запасом. И скорость его должна быть достаточно большой, чтобы успеть. Это обязательное условие.
Второе: конвертация проходит в многопоточном режиме. Значит, сервер, на котором это будет запущено, желательно должен иметь быстрые доступные ядра. Потоки параллелятся нелинейно: какие-то этапы проходят параллельно, какие-то управляющий сигнал агрегирует. Но тем не менее это может ускорить процесс.
Еще один момент – может потребоваться не одна итерация. При конвертации могут случиться ошибки не только по причине данных. Хотя и по данным такое тоже может случиться. Например, отказало оборудование, сеть – что угодно. Технология допускает, чтобы повторение было несколько раз. Так как пользователи все равно работают и не ощущают этого, в момент сбоя вы можете повторить процесс. Просто проект миграции удлинится.
Последнее, что нужно сказать, – сверка данных. Это очень важный этап. Мы сталкивались с тем, что какие-то таблицы не конвертируются: из множества строк вы получаете ноль. Какие-то таблицы конвертируются частично. Поэтому лучше подготовить проверочные скрипты. Делается это несложно: можно потаблично сверить, что все строки мигрировали.
Этапы 2-3. Репликация и синхронизация данных
Теперь рассмотрим следующий этап. Мы используем DBReplication. Но на самом деле в этой идеологии можно использовать любую технологию обмена данными. Она просто должна обладать определенными свойствами.
Первое свойство – она должна позволять сохранять транзакционные изменения пользователей в отдельной базе данных или на отдельном диске.
Второе – иметь возможность конвертировать типы, если это делается напрямую в SQL, потому что типы в PostgreSQL и типы в MS SQL немного расходятся.
Третье – обязательно сохранять транзакционную целостность и последовательность, чтобы база PostgreSQL была консистентна.
Этапы 4-6. Проверки и переключение пользователей
Перед переключением, кроме проверки целостности, обычно у клиента бывают эталонные отчеты. Можно запустить отчет, например, в MS SQL, посмотреть оборотно-сальдовую ведомость в PostgreSQL и сравнить.
Должна быть прописана маршрутная карта, и специалисты до переключения пользователей должны провести определенные проверки: нет ли проблем с данными.
В самом переключении ничего интересного нет, все строго по чек-листу.
Появляется еще один очень интересный этап. Когда базы данных синхронны и прямой мост в виде репликации уже не нужен, при перемещении пользователей мост можно оставить, но в другом направлении – чтобы база MS SQL была актуальна.
Для чего это нужно? Фактически это чем-то напоминает страховку: «КАСКО» или любой другой механизм защиты от инцидента. Получается, что пользователи будут работать в базе PostgreSQL, при этом MS SQL на некоторое время не теряет актуальность.
Защитные механизмы. Страховка при сбоях: План Б и план В
Здесь хотелось бы упомянуть три плана: А, Б и В.
План А понятен: мы перешли, пользователи «удержались», бизнес работает на новой архитектуре (Postgres). В рабочем порядке можно все оптимизировать.
План Б – когда мы столкнулись с какой-то сложностью, неразрешимой за ограниченное время, и есть возможность переехать обратно на базу MS SQL в кратчайшие сроки. После исправления ситуации или сбоя можно потом вернуться уже без длительной процедуры конвертации.
План Б, слава богу, в наших проектах на практике никогда не использовался. Но теоретически (и практически ) такой план может понадобиться - учитывая потери крупного бизнеса при сбое, и его нужно продумывать.
План В как раз использовался. Это гибридный подход. Например, в целом транзакционно все работает, пользователи удовлетворены, но есть ряд регламентных отчетов по требованию законодательства, которые либо не выполняются в PostgreSQL, либо выполняются запредельно долго. Бизнес несет из-за этого риски и убытки.
Как временное решение можно переназначить одного или нескольких пользователей в базу данных MS SQL, чтобы выполнить этот отчет, потому что данные там консистентны и актуальны.
Давайте наглядно покажем процесс. Обычная ситуация: мы перешли на Postgres. Если смотрим, как работает план Б, то получается, что у нас есть сбой в работе пользователей на PostgreSQL. Мы отключаем обратный репликационный мост, в технологическое окно пользователи мигрируют на базу MS SQL, и включается прямой мост (MS SQL - Postgres).
План В похож, но здесь нет изменений в общей работе пользователей. Просто у одного пользователя появляется дополнительный ярлык, который запускает базу данных на MS SQL, прописанную в 1С:Предприятии или конфигурации.
Теоретически технология позволяет и двустороннюю репликацию, но для проекта миграции это достаточно избыточно. Тогда пришлось бы подключать еще и конфликтологию. А изменение данных в двух базах одновременно здесь не нужно.
С чем мы столкнулись при переходах
Теперь практические вещи. С чем мы столкнулись при переходах и с чем будете сталкиваться вы.
Это, конечно, проблема производительности. Это основная проблема. Здесь нужно быть готовыми подключить все инструменты 1С, все инструменты, которые есть у вас на PostgreSQL, а мы подключаем еще PerfExpert, чтобы максимально оперативно находить бутылочные горлышки.
Как правило, после перехода нагрузка на оборудование может сразу возрасти. Если нет инструмента, который быстро определит, где узкое место, какой запрос нужно оптимизировать, здесь можно завязнуть, и проект миграции будет неуспешен.
Еще одна важная вещь – мониторинг, а именно сбор трассировок. Этого не хватает в стандартном PostgreSQL, и над этим сейчас тоже работают вендоры.
Речь о трассировке запросов, аналогичной Extended Events и Profiler в MS SQL. Вам поступает жалоба от пользователя, что что-то у него не проводится или проводится медленно, и вы не можете сопоставить это с конкретными запросами. Если у вас есть трассировка, вы это сопоставите.
Другие инструменты дают это либо постфактум, либо в агрегированном виде. Это больше похоже на рыбалку. Здесь же можно сделать четкое сопоставление. PerfExpert позволяет осуществлять трассировку вне зависимости от релизов и вендоров Postgres.
По аппаратным ресурсам есть заблуждение, что PostgreSQL потребляет меньше ресурсов, чем MS SQL. При одинаковом профиле нагрузки нужны эквивалентные ресурсы.
Но в момент старта лучше заложить запас прочности. Мы советуем в полтора раза больше, хотя были переходы и один к одному. Много неуспешных переходов было тогда, когда ресурсов давали значительно меньше: «PostgreSQL же память плохо использует» и так далее. Это не так.
Следующий момент – оптимизация запросов. Должна быть готова команда разработчиков 1С, которая подхватит задачи на переписывание и доработку кода 1С. Плюс, понятно, индексный тюнинг там, где он требуется.
Очень интересная особенность PostgreSQL – подсказки оптимизатору. В MS SQL было буквально несколько хинтов. В PostgreSQL это целая палитра: можно делать практически все, что нужно.
Настройки PostgreSQL, конечно, многообразнее, чем MS SQL. Если в MS SQL мы настраивали четыре параметра и этого было достаточно, в PostgreSQL их десятки. PostgreSQL очень хорошо можно поднастраивать через параметры памяти.
У нас даже есть отдельный блог по этой теме на Habr: https://habr.com/ru/companies/softpoint/articles/854316/. Если кому-то интересно, потом можно почитать. Это очень объемные темы по каждому параметру. Но здесь я расскажу только про параметр work_mem.
Все знают: это стандартный квант памяти, который выделяется в момент выполнения запросов на операции слияния, группировки, сортировки и прочего.
Если work_mem поставить очень маленьким, получается массовое сбрасывание на диск: памяти не хватает, вы запрос «душите» - запрос выполняется медленнее. Если поставить слишком большое значение work_mem, вы получите другую ситуацию: очень большие риски «завалить» запрос. А если у вас неправильные настройки, можно завалить и PostgreSQL.
Поэтому здесь нужно выбирать золотую середину. Обычно мы действуем от меньшего к большему. Поставили 100 МБ, оценили, сколько сбрасывания на диск. И можно идти не только настройкой, можно идти оптимизацией запроса: уменьшать расход work_mem с использованием переписывания запроса или, возможно, индексного тюнинга.
Какие задачи решались при миграции
Какие задачи решались при миграции?
Первая задача – синхронизация данных с использованием DB Replication.
Вторая – производительность. Мы используем PerfExpert. Нам удобно его использование, так как он накапливает все данные из 1С и из других источников и позволяет сделать качественный анализ.
С помощью QProcessing мы приводили запросы к длительностям, эквивалентным MS SQL.
Очень важный момент. Многие навскидку говорят, что PostgreSQL при определенных запросах работает хуже. Но это не так. Просто ИТ система 1С развивалась под MS SQL и все под это было адаптировано. Понятно, что вам необходимо адаптировать это так, чтобы оптимизатор PostgreSQL нормально все обрабатывал.
И здесь встает вопрос, особенно для клиента: «У меня оборотно-сальдовая ведомость запускалась одну минуту на миллиардах данных, а тут стала выполняться 30 минут или три часа».
Понятно, что если у вас есть статистика, как этот запрос запускался в MS SQL, и есть план выполнения, то вы понимаете дерево правильного плана, к которому нужно стремиться. Но только общими настройками PostgreSQL бывает сложно сделать так, чтобы план формировался аналогично MS SQL.
Тогда на помощь приходят подсказки PostgreSQL, когда вы можете сказать как должны соединяться таблицы, какими соединениями. И самое главное: QProcessing позволяет это сделать для определенного запроса. Он не меняет настройку в целом для всего PostgreSQL, а только для определенных видов запросов, где это нужно.
Здесь есть несколько вариантов дальнейших шагов: первый – разработчики 1С подумают и перепишут запрос, чтобы решить проблему, второй – вендор через несколько поколений разберется, и у него этот запрос будет выполнять правильный план, а третий – QProcessing (здесь и сейчас решает эту проблему для конкретного запроса). Обычно мы считаем это решение условно временным, но на самом деле оно постоянно работает и состав правил постоянно меняется: какие-то выключаются, какие-то добавляются.
Последняя задача – балансировка нагрузки. Это тоже полезная технология. Смысл ее в распределении нагрузки между серверами СУБД (одна реплика СУБД на чтение/запись, остальные только на чтение).
Это важно для решения проблемы горизонтального масштабирования СУБД. И, конечно, вместе с ней паровозиком идет отказоустойчивость.
Спасибо за внимание.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт