Привет, Хабр!

Меня зовут Андрей Жуйков, и в этой статье я хочу рассказать вам историю абсолютно практического содержания. Без теоретических рассуждений и без лозунгов про импортозамещение. Это реальный кейс о том, как мы перевели несколько наших корпоративных 1С с Microsoft SQL Server на Digital Q.DataBase.

Да, мы так же, как и многие другие компании в России, используем в своей компании 1С. И она всегда у нас стояла на Windows и Microsoft SQL Server. Однако, по мере того, как все большее число наших внутренних информационных систем было переведено с Windows на Linux, встал вопрос о том, чтобы и тот сервер, на котором много лет жили базы данных нашей корпоративной 1С, тоже работал под управлением Linux.

Разумеется, 1С умеет работать на Linux, равно как и с СУБД PostgreSQL, все форки которой, включая наш собственный, прекрасно работают под Linux. И вариант перевести базы данных нашей корпоративной 1C под PostgreSQL на Linux самым что ни на есть традиционным способом тоже рассматривался. Но на пути к этим действиям мы обнаружили весьма неприятное препятствие.

Исторически так сложилось, что сразу несколько наших внутренних систем имели доступ к базам 1С, взаимодействовали с ними напрямую или использовали db-линки, «подселяя» собственные хранимые процедуры в базы 1С. Да, делать так не принято, однако в этой жизни такое встречается, причем не только у нас, а много где еще. Да и некоторые наши конфигурации активно использовали хранимые процедуры. Имея в штате несколько сотен T-SQL-программистов и всего лишь несколько 1С-ников, было бы странно не использовать возможность размещать в базе данных корпоративной системы хранимую бизнес-логику. И хотя все это осталось в далеком прошлом (наши новые корпоративные системы построены на микросервисах и не имеют никакого отношения к нашей 1С), наследие в виде нескольких тысяч «хранимок» и прямого подключения к этим базам еще из четырех корпоративных систем осталось и по сей день.

Это и стало камнем преткновения, ведь чтобы просто перейти на Linux и PostgreSQL, пришлось бы потратить немало времени и сил: разбирать все, что было «накручено» вокруг 1С за предыдущие годы, вносить изменения в четыре смежные системы, а потом еще и тщательно все это тестировать. Но мы не захотели совмещать несколько таких крупных изменений в одном этапе.

В итоге, было принято решение воспользоваться способностью нашего собственного форка PostgreSQL понимать и исполнять запросы в диалекте Microsoft SQL Server, «прикидываться» им на транспортном (сетевом) уровне, исполнять хранимую логику, написанную на T-SQL. Да, Digital Q.DataBase все это умеет – она может «изображать» из себя MS SQL, а также Oracle и PostgreSQL, якобы установленные на одном сервере. На самом деле это одна СУБД, просто мультидиалектная, своего рода полиглот в мире SQL-диалектов, предназначенная для легкой замены иностранных СУБД.

Своей «квест» мы начали с тестового стенда. Создали при помощи нашего «Мастера переноса БД» копию базы 1С в Digital Q.DataBase, подняли отдельный контур, добавили ее как уже существующую информационную базу и просто указали новый сервер СУБД.

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

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

Далее мы протестировали ежедневные рабочие операции: сформировали отчеты, проверили регистры, просмотрели данные учета, создали и провели документы.

Все операции выполнялись штатно, без ошибок и без заметных временных задержек.

Все выглядело точно так же, как и при работе системы на MS SQL. Никаких дополнительных настроек на стороне клиента не потребовалось, будто мы ничего и не меняли.

И что еще более важно, те внешние информационные взаимодействия и «подселенные» в базу 1С «хранимки» на T-SQL, которые не давали нам перейти на Linux и PostgreSQL, после переноса данных на Digital Q.DataBase сохранились в работоспособном состоянии. Чтобы еще раз убедиться в этом, мы дополнительно протестировали поведение системы под повседневной и стрессовой нагрузкой.

Уточню, что в рамках пилотного проекта на Linux и PostgreSQL были переведены две информационные базы: бухгалтерский контур и конфигурация для учета оборудования. Обе базы были переведены по одинаковой схеме и протестированы отдельно. И в том, и в другом случае тесты завершились успешно.

После тестирования мы подготовили промышленное переключение. Базы были сконвертированы еще раз, чтобы «подхватить» последние изменения, накопившиеся за время функционального тестирования.

Чтобы базы в Digital Q.DataBase и впредь оставались идентичными оригинальным, была настроена синхронизация изменений посредством нашего же продукта Digital Q.CDC.

В определенный момент система была полностью переключена на новый стенд, а сервер с MS SQL был выведен из эксплуатации.

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

Сегодня наша корпоративная 1С продолжает работать, как и прежде, но «под капотом» теперь – Digital Q.DataBase.

Если вам интересны детали архитектуры, нюансы работы движка T-SQL в Digital Q.DataBase или настройка Digital Q.CDC для репликации «на лету» изменений из MS SQL в Digital Q.DataBase, которая и позволила нам переключить пользователей прямо в разгар рабочего дня, готов обсудить это отдельно.

Буду рад вашим вопросам в комментариях.