Миграция базы данных
В 2014 году в России обостряется активный интерес к направлению миграции баз данных. Драйвером роста послужила необходимость импортозамещения систем, которые лицензируются зарубежными производителями и попадают под санкции.
Стоит ли говорить, что в 2022 году интерес к системам баз данных и их миграции стал потребностью – как в рамках импортозамещения, так и для расширения возможностей.
В материале собрали поэтапный план миграции, рассказали о подводных камнях и ошибках, которые компании допускают при миграции с одной базы данных на другую, на примере миграции 1С на PostgreSQL с MS SQL.
Этапы миграции баз данных
1 – Развертывание и настройка операционной системы и СУБД*
2 – Перевод информационной базы на новую СУБД
3 – Функциональный аудит и адаптация к новым условиям
*СУБД – это Система Управления Базами Данных. Совокупность программно-языковых средств общего или специального назначения, позволяющих проектировать, настраивать и администрировать базы данных.
1 этап: Развертывание и настройка операционной системы и СУБД
Этап не требует сложной предварительной подготовки, так как сервера управления базами данных схожи. Однако, есть нюансы.
Модель взаимодействия операционной системы (ОС) и СУБД
Например, PostGreSQL, как целевая СУБД, работает как на Windows, так и на Linux.
Если речь идёт о миграции приложения, например, с 1С + Microsoft SQL на 1С + PostGreSQL, необходимо определиться с ОС:
– Остаться на Windows и развернуть PostGreSQL
– Переводить всё на Linux, в том числе PostGreSQL – и отказаться от Windows и Microsoft SQL
– Компромисс, где будет и Windows, и Linux и PostGreSQL.
Стратегия перевода функционала и конструкций взаимодействия вне и внутри существующего приложения
– Для работы приложения требуется оборудование. Будет ли оно эффективно на Linux? Необходимо ли что-то внедрять, убирать, менять?
Обязательна проверка наличия необходимых драйверов и возможности подключения внешнего оборудования.
– Адаптация функциональных возможностей переносимого приложения. Если не принять их во внимание и сосредоточиться только на технологических аспектах, успешно завершить миграцию и успеть в срок будет практически невозможно.
Перечень некоторых функциональных решений 1С и рекомендуемых действий:
- Внешние отчеты, обработки, документы, работа с файлами – проверить работоспособность в новой операционной системе;
- Интеграции – помимо обмена между конфигурациями 1С может потребоваться интеграция с различными отраслевыми системами;
- 1С-ЭДО, 1С-Отчетность – проверить работоспособность средств криптозащиты, а также работу сервисов, использующих УКЭП
- Клиент-банк – проверить возможность работы решений, которые поставляются банками, в новой операционной системе
- Почтовый клиент и напоминания – определить, как поддержать функциональность, либо найти альтернативное решение
- Аудит кода – проверка синтаксиса на наличие конструкций, используемых в среде Windows. Подробнее об этом аспекте говорим далее.
“Текущие внешние отчеты, обработка документов, интеграции в приложении – будут ли они работать с Linux и PostGreSQL? Например, в 1С есть электронный документооборот, 1С-Отчётность, где применяются средства криптозащиты. Клиент-банки, почтовые клиенты, напоминания, работа с файлами – и другие процессы работают в Linux и Windows по-разному”
– Черепанов Игорь Георгиевич, руководитель отдела проектов Cortel.
Для того, чтобы обеспечить новую базу данных всем функционалом исходной, необходимо владеть не только инструментами PostGreSQL, но и уметь обращаться со сторонними сервисами, а также понимать, какое ПО будет лучше решать задачи целевой СУБД. Для каждой версии инструменты будут свои.
2 этап: Перевод информационной базы на новую СУБД
1С позволяет выгрузить базу данных в конфигураторе в файл с расширением .dt, а затем загрузить его в новую СУБД. В иных случаях перенести базу напрямую не получится, необходимо пользоваться специфическими инструментами конвертации, резервного копирования и т.д.
На данном этапе ключевой аспект – наличие ошибок в исходной СУБД.
Пример
В PostGreSQL 2 года назад, например, после внесения хотя бы одного изменения в конфигурацию 1С, при сохранении базы 1С – примерно 2 ГБ, вся база сохранялась в 1 ячейку. Соответственно, возникали проблемы с резервным копированием. Приходилось делать бэкап отдельно данной ячейки, отдельно – остальных ячеек, затем их “склеивать”. Специалист, который будет заниматься миграцией, должен знать и учитывать подобные специфические аспекты.
Размещение информации в базе данных – особенности синтаксиса
В большинстве случаев, в 1С запросы написаны сервером приложения, автоматически. Если речь идёт об иных, в том числе, самописных приложениях, нюансов, на которые важно обратить внимание, чтобы избежать ошибок, достаточно много:
– Чувствительность схемы данных к регистру – в двойных кавычках;
– Уникальность имен идентификаторов индексов и внешних ключей;
– Максимальная длина идентификатора – 63 символа;
– Нюансы с типами данных — “дата/время”;
– Чувствительность к регистру поиска по строкам;
– Разница в синтаксисе SQL запросов.
Эти и другие факторы необходимо искать по всей базе данных и исправлять перед началом миграции.
Бесплатная или платная версия?
Как заявляют разработчики на сайте Postgres PRO, отличие между бесплатной и платной версией PostGresQL есть:
«Конфигурационные параметры для данных сборок автоматически выставлены так, чтобы они соответствовали ресурсам вашей машины. Такая оптимизация позволяет повысить производительность СУБД».
Соответственно, предполагается, что можно будет получить рабочий вариант корпоративной информационной системы с минимальными трудозатратами на ее настройку.
| Параметр | Postgres Pro Enterpise 14 | Postgres Pro Standard 14 | PostgreSQL 14 |
| Адаптивная оптимизация запросов | + | — | — |
| 64-битный счётчик транзакций | + | — | — |
| Сохранение планов запросов | + | — | — |
| Автоматическая компиляция и планирование запросов | + | — | — |
| Компрессия данных на уровне блоков | + | — | — |
| Оптимизированное секционирование таблиц | + | + | + |
| Пул соединений | + | + | + |
| Оптимизация планировщика и исполнителя запросов | + | + | + |
| Встроенные средства отказоустойчивости | + | — | — |
| Резервное копирование | + | + | + |
| Встроенный планировщик заданий | + | — | — |
| Автономные транзакции | + | — | — |
| Инкрементальный бэкап | + | + | — |
| Изменение параметров конфигурации в другой сессии | + | — | — |
| Мультимастер | + | — | — |
Источник: https://www.postgrespro.ru/products/postgrespro/enterprise
Необходима она или нет – зависит от требований бизнеса.
Для 1С, например, на официальном сайте можно найти бесплатную версию PostGreSQL, адаптированную под 1С. Для работы среднего предприятия будет достаточно уровня оптимизации запросов, инструментария и настроек.
Если для бизнеса важно получить максимальную производительность, то обязательно привлекать специалистов PostGreSQL для более детальной настройки в соответствии с конкретным приложением и данными. Эксперты по PostGreSQL смогут произвести как первоначальную, так и дополнительную настройку по обращению.
В большинстве случаев, ключевым аргументом при выборе коммерческой версии сборки являются проблемы при проверке требований политики импортозамещения. PostgreSQL не может входить в реестр отечественного ПО «Минцифры», поскольку зарегистрировать свободно распространяемую сборку без исключительных прав на нее, согласно правилам формирования единого реестра отечественного ПО, практически невозможно (см. п. 5, пп.а «Правил»).
“Если в 1 и 2 этапе мы всё сделали правильно, выбрали нужную сборку с сайта 1С, она проверена, развернули правильным способом, не поймав ошибок при работе со стандартными инструментами переноса и в результате тестирования не выявили проблем – скорее всего, в работе не понадобится ни помощь сертифицированного специалиста, ни специфических инструментов”
– Черепанов Игорь Георгиевич, руководитель отдела проектов Cortel.
3 этап: Функциональный аудит и адаптация к новым условиям
PostGreSQL и Microsoft SQL – это разные СУБД, поэтому наблюдение за взаимодействием базы данных и приложением в новой СУБД – обязательно.
Запустив работу на новом сервере управления базами данных, возможно провести мониторинг нагрузки, ошибок, которые возникают и могут возникнуть в перспективе.
Нагрузка на оборудование
Изменение нагрузки связано с особенностями СУБД.
Например
БД весом 20 ГБ будет показывать неплохую работоспособность при условии, что Microsoft SQL Server использует 16 ядер и 44 ГБ оперативной памяти. В PostGres той же производительности можно добиться на 4 ядрах и 8 ГБ оперативной памяти.
Это доказывает, что Microsoft SQL Server работает значительно медленнее, но не говорит о том, что он хуже. Его плюсом является универсальность настройки. В PostGreSQL таких результатов возможно добиться с помощью достаточно сложных действий специально обученных людей.
Непредвиденные ошибки
При обнаружении ошибок, тем более, указывающих на её причину в неожиданной области, необходимо обращаться за помощью к сертифицированному специалисту, для того, чтобы он как можно быстрее выявил причину и разрешил ситуацию.
Например
Причиной ошибки в работе “1С-отчетность” может быть невозможность подключения рутокена, что связано с уникальным монтированием Linux – процесс останавливается из-за ошибки с работой документа. А проблема была, как мы сказали, в оборудовании. Соответственно, в каждом конкретном случае нужно анализировать, что произошло и почему.
С чем сталкиваются компании?
Наиболее неудачный сценарий миграции – появление новой недоработанной базы данных. Это – “эффект второй системы”, описанный Фредериком Бруксом, экспертом в области теории вычислительных систем. Он увеличивает финансовую нагрузку на компанию и сложность сопровождения баз данных.
Причинами возникновения подобного исхода могут быть:
- Потеря данных. Потеря и дублирование данных о структуре базы данных и ее привязки к бизнес-процессам может стать причиной ошибок при дальнейшей модификации системы. Поэтому, при миграции необходимо обеспечить согласованность, целостность и исключить дублирование данных.
- Ошибки в копировании бизнес-логики. Помимо данных, миграции подлежит и бизнес-логика, реализуемая в исходной базе данных. Однако, её перенос без предварительного аудита может привести как к копированию старых ошибок, так и к появлению новых.
- Недостаток квалифицированных кадров. Для ускорения процесса и избежания ошибок, специалист по миграции должен владеть компетенциями как в исходной, так и в целевой СУБД. На рынке дефицит кадров, обладающих такими навыками.
- Неправильный выбор целевой архитектуры. К подобной проблеме может привести:
– Наследование неудачных решений исходной системы;
– Выбор архитектуры без учёта требований бизнеса.
Принципы, которые приведут к удачной миграции базы данных
- Понятный и конкретный план миграции базы данных. Под процесс миграции выделена специальная рабочая группа, которая знает особенности и функционал как исходной, так и целевой базы.
- Определение бизнес-задач. Описание конкретного функционала и задач целевой базы.
- Комплексный аудит исходной базы на наличие ошибок в коде и архитектуре.
- Защита и обслуживание. База данных – один из самых уязвимых объектов для кибератак. На рынке существуют различные инструменты, позволяющие сделать перенос данных безопасным, например, системы обнаружения вторжений, средства анализа защищенности данных и сетевые экраны.
- Сделать резервную копию данных перед стартом миграции. Это обеспечит “подушку безопасности” на случай, если что-то пойдёт не по плану.
- Непрерывный мониторинг процесса миграции и состояния новой базы данных.