Миграция базы данных MySQL

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

Процедуру применяют при модернизации и восстановлении IT-инфраструктуры. Она же востребована при внедрении новых разработок в действующую систему. Или для объединения нескольких разрозненных программ (слияние фирм, филиалов и пр.). В этом материале мы рассмотрим все варианты миграции базы данных MySQL (справедливо и для других систем), чтобы сформировать понимание, какие преимущества она дает, как проходит процесс и как подготовиться к переносу информации.

Общие термины

• Данные (Data) – формат хранения информации в электронном виде (файлы, каталоги) на локальных и/или облачных носителях.
• Информационная система, ИС – программа, предназначенная для хранения, обработки и поиска данных. В эту же категорию включают ресурсы, используемые в качестве служебных, нужных для работоспособности ИТ-инфраструктуры.
• База данных, БД (Database, DB) – набор данных, принадлежащих конкретному предприятию, отделу или даже проекту. Сюда входит информация, внесенная пользователями, таблицы, прочие объекты, которые автоматически сформированы на базе первого. Также в БД хранят отчеты, графические, мультимедийные, текстовые файлы, служебные отметки, напоминания и пр.
• Система управления БД, СУБД (Database Management System, DBMS) – программный продукт, созданный специально для редактирования и управления базами данных.
• Схема БД (Database Schema) – структура БД на языке, поддерживаемом конкретной СУБД. Включает как типовые объекты вроде таблиц и связей внутри них, так и представления, индексы, иную пользовательскую информацию.
• Таблица (Table) – структурированный способ отображения значений, хранящихся в БД. Включает столбцы и строки, имеющие определенное назначение.
• Миграция данных (Data Migration) – термин имеет двойное назначение. 1. Массовый перенос из источника в принимающую базу. По завершении изначальную систему обычно прекращают использовать как рабочий вариант. 2. Преобразование БД с изменением базы, с повышением или понижением (апгрейд или даунгрейд, db_upgrade или db_downgrade).
• Система-источник (историческая система) – база данных, откуда предстоит копировать коммерческую и служебную информацию.
• Система-приемник – БД, куда информация будет перенесена в процессе переноса.
• Исходные данные – информация, полученная из исторической системы. Например, в универсальном виде в файле Excel (расширение XLS).
• Трансформация данных – конвертация исходной структуры в формат принимающей БД в соответствии с ее типовым шаблоном хранения информации.
• Данные для загрузки – информация, подготовленная к загрузке в целевую БД.
• Шаблоны данных для загрузки – описание структуры хранения информации, в которой предстоит загружать информацию в систему-приемник.
• Версия БД – текущее или предыдущее состояние структуры базы с определенным номером, с привязкой к конкретному релизу программы (обычно они являются неразрывным целым).

Причины миграции баз данных

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

Технологии, используемые в IT-инфраструктуре, совершенствуются постоянно. Минимум раз в пару лет на рынок выходят новые продукты, кардинально отличающиеся от предыдущих. Последнее отчасти усложняет обслуживание, увеличивает стоимость содержания ИТ, вносит определенные ограничения, что и приводит к необходимости модернизации с миграцией БД. Разработчики дополнительно «стимулируют» такой подход постепенным прекращением поддержки старых продуктов.

Государство поддерживает модернизацию преимущественно по программе импортозамещения. Она работает с 2014 года, но в 2022 году ситуацию подстегнул уход с российского рынка целого ряда зарубежных разработчиков. Госсектор и иные предприятия с критической для страны инфраструктурой обязали перейти на отечественные программы. А это неизбежная миграция с сохранением загруженной в БД информации.

Приведем краткий перечень, когда необходима миграция:

1. Запуск нового сайта.
2. Необходимость увеличения уровня безопасности ИТ-инфраструктуры.
3. Импортозамещение программных продуктов, включая СУБД.
4. Стремление к сокращению затрат на сопровождение ИС.
5. Внедрение принципиально новых технологий.

Типы миграции данных

Выбор варианта миграции базы данных MySQL зависит от текущих бизнес-задач. Примеры:

1. Перенос информации – данные, хранящиеся в базе-источнике, преобразуют в иной, поддерживаемый базой-приемником. Сюда входит оцифровка бумажных документов для перевода архивов в цифровой вид, применение алгоритмов шифрования.
2. Внедрение новых программ – переход на современные релизы программ с сохранением предыдущих настроек, на принципиально новые программы с переносом из старого софта.
3. Миграция баз данных – перемещение БД с сохранением консистентности. Например, при переносе локальной IT-инфраструктуры в облачную среду, при импортозамещении согласно действующим нормативным актам.
4. Миграция релизов – обновление структуры БД до актуальной версии, чтобы она соответствовала как программе, так и инструментам сторонних сервисов. Процедура проводится в обратном порядке, с понижением номера релиза.

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

Типовые процессы при миграции БД

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

Что понадобится при миграции всей БД

Процесс условно делят на два этапа – подготовку и непосредственно миграцию, что также предполагает работу в несколько шагов.

Организационная часть

1. Определить стратегию. Важно заранее выбрать технологию, при помощи которой пройдут работы по миграции базы данных MySQL. В этап входит определение правил открытия доступа сотрудникам, имеющим отношение процедуре. Каждый участник обязан понимать, что от него требуется. Также желательно внести в стратегию тестирование системы по завершении переноса, чтобы выявить ошибки и исправить их до того, когда они начнут создавать проблемы.
2. Собрать рабочую группу. В нее включают специалистов, знакомых с функционированием «старой» системы (исторической) и новой программы. Мониторинг лучше поручать отдельным сотрудникам. Последнее обязательно даже при полной автоматизации процедуры переноса.
3. Составить план. В него включают объем переносимой информации, дату ее переноса, тестирования, итогового внедрения нового софта. Это не исключает возможности корректировки плана исходя из результатов миграции, возникающих ошибок, появления иных вводных.
4. Перечислить данные, подлежащие миграции. Что хочется скопировать? Классификаторы, остатки, обороты, транзакционную и справочную информацию.
5. Обговорить способы, критерии проверки качества. Важно проверить целостность и корректность перенесенных данных, отсутствие необоснованных дублей, наличие полной согласованности, связей, предусмотренных структурой базы-приемника.
6. Определить способ отката БД. При серьезных ошибках придется временно вернуться к старой БД, чтобы избежать простоев. Механику возврата рекомендуется обсудить заранее.

Технологическая часть

1. Подготовить шаблоны загрузки данных, загрузчик файлов. Они включают описание полей, подлежащих загрузке, правила загрузки таблицы на основании структуры базы-приемника. В них же указывают, как преобразовывать данные, если миграция происходит не «один в один».
2. Выявить источники данных. На этом этапе определяют, какая информация будет переноситься, где и в каких базах, в каком формате она расположена. Продумывать список источников надо тщательно, чтобы избежать утраты важной информации.
3. Выгрузить исходные данные. Скорость выгрузки зависит от объема информации, иногда от ее типа, от того, требуется ли преобразование, возникают ли ошибки чтения, приводящие к повтору считывания. На практике часто делают тестовые выгрузки небольшой части БД для предварительной оценки.
4. Сравнить данные. Этап обязательный, его результаты гарантируют идентичность информации в БД-источнике и файле-выгрузке. Он займет время, примерно равное третьему шагу. В зависимости от задач одновременно нормализуют поля-таблицы, удаляют дубли и т.д.
5. Подготовить правила трансформации. Включает написание скриптов, которые автоматически, по заранее созданным шаблонам, преобразуют структуру в заданный формат.
6. Загрузить данные в базу-приемник. Предполагает серию тестовых и итоговую миграцию или сразу «основную», если пользователь уверен в качестве. Например, когда процедура проводится во второй и более раз одними и теми же инструментами.
7. Выверить данные. На последнем шаге обязательно сверяют базу-источник и базу-приемник, чтобы исключить несоответствие даже отдельно взятых полей. Часто повторно нормализуют для исправления вероятных недочетов, для уменьшения объема БД, исключения дублей и пр.

Особенности процесса версионной миграции данных MySQL

Миграцию версий БД используют при разработке софта, новых релизов существующих программ. Процедура позволяет избежать рассинхронизации, если отдельные модули создавали разные программисты. Или при создании нового релиза в несколько этапов, с периодическим откатом к прежним подверсиям. Основная идея версионной миграции заключается в задании правила – любой SQL-запрос выполняется только один раз, т.к. одни изменения часто зависят от других.

При переносе возникают «нетипичные» ошибки. Например, часть пользователей предполагает, что нулевые строки допустимо удалять, но они иногда являются частью обязательной структуры БД. Поэтому лучше сразу же предусмотреть правило хранения «нулевых» строковых полей:

1. Независимо от текущего значения тип поля задать Nullable.
2. Заменить все пустые строки обрабатываемой БД на NULL.
3. Скорректировать код так, чтобы программа без ошибок реагировала на считывание NULL.

Важно учитывать, что при обновлении только приложения без БД рано или поздно появится ошибка вставки значения NULL в поле Not Nullable. На практике используют несколько методов версионной миграции – инкрементных, идемпотентных изменений, уподобления структуры базы данных исходному коду и пр. Есть готовые инструменты для переноса: Migrator.NET, ECM7.Migrator, Active Record Migrations или еще с десяток аналогов. Независимо от выбора, везде придерживаются следующих принципов:

1. Важно, чтобы любая версия БД обновлялась до любой из существующих.
2. То же относится к набору SQL-запросов, за счет которых происходит миграция.
3. Рекомендуется иметь возможность в любой момент создать БД с нуля и актуальными данными.
4. Желательно при слиянии веток свести к минимуму ручное редактирование файлов.
5. Откат к одной из предыдущих релизов столь же простой, как и апгрейд.

Подготовка к составлению плана миграции БД

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

Предварительно рекомендуется провести аудит, определить текущее качество, их формат, политику конфиденциальности. В план входит и мониторинг вероятных изменений, к которым иногда приводит миграция. Такой подход позволяет определить потенциальные проблемы, скорректировать работы исходя из реальных вводных.

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

Пример переноса БД

Перед началом миграции желательно убедиться, что система-приемник поддерживает ту версию БД, которую предстоит переносить. Также необходимо заранее предоставить доступ к исходному и целевому объектам. В процессе поможет информация из официального руководства «Помощник по миграции SQL Server для MySQL».

Подготовка к миграции

Если текущие условия позволяют беспрепятственно провести миграцию, проводят оценку базы данных и связанных объектов на предмет готовности к переносу. Процедура возможна за счет использования инструмента SSMA. Последовательность действий следующая:

1.     Откройте программное обеспечение SSMA для MySQL.
2.     Выберите пункт меню «Создать проект» в разделе «Файл».
3.     Внесите его название, где будет располагаться, укажите целевой объект.
4.     Параметр «Перенести» поставьте в значение SQL Server.
5.     Через окно «Подключение к MySQL» подключитесь к серверу MySQL.
6.     Выберите БД, подлежащую миграции.
7.     Щелкните правой кнопкой мышки на «Обозревателе метаданных MySQL».
8.     Выберите вкладку «Создание отчета» (правый верхний угол).

В результате будет сформирован отчет, содержащий статистику преобразований, возникающих ошибках или предупреждениях. Система сохранит этот файл в папке SSMAProjects, расположенной в системном каталоге текущего пользователя. При просмотре в Excel пользователь увидит перечень объектов MySQL и действий, которые предстоит преобразовывать при переносе.

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

1.     Выберите «Параметры проекта» в пункте меню Сервис.
2.     Перейдите на вкладку «Сопоставление типов».
3.     Проведите сопоставление выбрав таблицу в «Обозревателе метаданных MySQL».

Теперь перейдем к преобразованию объектов БД. Их необходимо взять из MySQL, «превратить» в аналог для SQL Server и загрузить в метаданные SSMA для MySQL. После этого можно просмотреть содержимое через «Обозреватель метаданных SQL Server». Продукт SSMA выводит сообщения об ошибках (поле «Вывод»), из содержимого которых легко судить, требуется ли преобразование БД для успешного проведения миграции. Если процедура нужна, выполните действия:

1.     Откройте «Подключение к SQL Server».
2.     Введите учетные данные для соединения с ним.
3.     Укажите целевую или новую базу данных.
4.     Кликните «Подключить».
5.     В области «Обозревателя метаданных MySQL» при помощи правой кнопки мыши выберите пункт «Преобразовать схему».
6.     По завершении сравните полученные данные с исходными, чтобы убедиться в отсутствии проблем, рекомендаций.

Если требуются исправления, сохраните проект в автономном режиме командой «Файл> Сохранить проект».

Миграция

При отсутствии ошибок и рекомендаций переходите непосредственно к миграции. На практике используют два варианта: на стороне клиента и на стороне сервера. В первом случае в диалоговом окне «Параметры проекта» следует выбрать «Подсистема переноса данных на стороне клиента». Во втором – «Подсистема переноса данных на стороне сервера».

Если целевая база – это SQL Express Edition, доступен только первый способ миграции

При задействовании сервера предварительно понадобится установить пакет расширений SSMA для MySQL на экземпляр SQL Server, на нем же запустить службу агента SQL Server. Перенос данных осуществляется при помощи последовательности действий:

1. Опубликуйте схему. Кликните правой кнопкой на «Обозревателе метаданных SQL Server». Там выберите «Синхронизировать с базой данных». Результат – БД MySQL будет опубликована внутри экземпляра SQL Server.
2. Сверьте исходный и целевой проект. Там же, где и «Синхронизировать…», выберите «Перенести данные». Поставьте галочки возле всех пунктов, чтобы перенести все таблицы.
3. Изучите отчет о переносе информации. Подключитесь к экземпляру SQL Server при помощи утилиты SQL Server Management Studio и проверьте, как прошла миграция БД.

Все, процедура переноса информации завершена.

Вариант миграции с применением консольных команд

Процедура включает два этапа – создание дампа базы данных и ее развертывание уже на облачном ресурсе, где планируется разместить систему. Перед началом работ желательно убедиться, что локальная машина и удаленный хост поддерживают используемую версию MySQL. Полноценность миграции между различными релизами БД не гарантирована.

Создадим SQL-дамп

Выполним задачу при помощи утилиты mysqldump:

mysqldump --user=<user_name> \
   --password=<password> \
   --host=<host> \
   --port=<port> \
   --set-gtid-purged=off \
   --no-tablespaces \
 <database_name> > dump.sql

В приведенном перечне команд необходимо указать свои данные:

1.     <user_name> – пользователь БД.
2.     <password> – пароль пользователя.
3.     <host> – IP-адрес хоста.
4.     <port> – порт, через который будет подключение.
5.     --set-gtid-purget=off – репликация не использует глобальные идентификаторы GTID.
6.     --notablespaces – дамп служебной информации будет исключен, он особо не нужен.
7.     <database_name> – имя БД.

Восстановим базу данных из созданного дампа

Помощь в восстановлении SQL-дампа окажет утилита mysql:

mysql --user=<user_name> \
   --password=<password> \
   --host=<host> \
   --port=6033 <database_name> < dump.sql

Здесь вносим следующие данные:

1.     <user_name> – имя пользователя БД.
2.     <password> – его пароль.
3.     <host> – IP-адрес хоста.
4.     <database_name> – имя БД.

При использовании SSL перечень команд будет выглядеть так:

mysql --user=<user_name> \
   --password=<password> \
   --host=<host> \
   --port=6033 \
   --ssl-ca=~/.mysql/root.crt \
   --ssl-mode=required <database_name> < dump.sql

Выводы

Миграция – управляемый процесс. При качественном планировании задача будет реализована без проблем. В противоположной ситуации возможны ошибки, потеря данных. Поэтому подход к переносу столь же важен, как работа с финансовыми документами. Повреждение или утрата информации вполне способна привести к убыткам. Зато последовательное исполнение (с подготовкой, составлением шаблонов и т.д.) обычно сразу дает положительный результат.

В своем официальном канале Timeweb Cloud собрали комьюнити из специалистов, которые говорят про IT-тренды, делятся полезными инструкциями и даже приглашают к себе работать.