Перенос локальных рабочих нагрузок MySQL в Базу данных Azure для MySQL — оценка

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — отдельный сервер База данных Azure для MySQL — гибкий сервер

Необходимые компоненты

Пример варианта использования

Обзор

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

Ограничения

База данных Azure для MySQL — это полностью поддерживаемая версия MySQL Community Edition, работающая в качестве платформы как услуга. Однако при первоначальной оценке необходимо ознакомиться с некоторыми ограничениями.

Ниже перечислены некоторые из наиболее важных:

• Поддержка подсистемы хранилища только для InnoDB и Memory.

• Ограниченная поддержка Privilege (DBA, SUPER, DEFINER).

• Отключенные инструкции для манипулирования данными (SELECT ... INTO OUTFILE, LOAD DATA INFILE).

• Автоматическая миграция базы данных (с 5.6 в 5.7, с 5.7 в 8.0).

• При использовании определяемых пользователем функций сервера MySQL единственным жизнеспособным вариантом размещения является размещенная в Azure виртуальная машина, так как не существует возможности отправить so или dll компонент в База данных Azure для MySQL.

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

Версии MySQL

MySQL имеет богатую историю начиная с 1995 года. С тех пор система MySQL превратилась в широко используемую систему управления базами данных. Служба "База данных Azure для MySQL" была запущена для поддержки MySQL версии 5.6 и продолжала работу до версии 5.7 и недавно — 8.0. Последние сведения о поддержке версии Базы данных Azure для MySQL см. в статье Поддерживаемые версии сервера Базы данных Azure для MySQL. В разделе "Управление после миграции" мы рассмотрим, как обновления (например, с 5.7.20 на 5.7.21) применяются к экземплярам MySQL в Azure.

Навыки работы с исходной версией MySQL являются обязательным условием. Приложения, использующие систему, могут использовать объекты базы данных и функции, относящиеся к этой версии. Миграция базы данных в более раннюю версию может привести к проблемам совместимости и потере функциональности. Кроме того, рекомендуется тщательно протестировать данные и экземпляр приложения перед переходом на более новую версию, так как новые возможности могут нарушить работу приложения.

Примеры, которые могут повлиять на путь миграции и версию:

• 5.6: столбец "МЕТКА ВРЕМЕНИ" для правильного хранения (миллисекунды и полнотекстовый поиск).

• 5.7: поддержка собственного типа данных JSON.

• 8.0: поддержка для хранилища документов NoSQL, атомарных и устойчивых к сбоям табличных функций DDL и JSON.

  Примечание.

  С февраля 2021 г. прекращается общая поддержка MySQL 5.6. Рабочие нагрузки MySQL необходимо перенести в MySQL версии 5.7 или более поздней версии.

Чтобы проверить версию сервера MySQL, выполните следующее:

SHOW VARIABLES LIKE "%version%";

Подсистемы хранилища базы данных

База данных Azure для MySQL поддерживает только подсистемы хранилища базы данных InnoDB и Memory. Другие подсистемы хранилища, например MyISAM, необходимо перенести в поддерживаемую подсистему хранилища. Различия между MyISAM и InnoDB заключаются в функциональных возможностях и выходных данных производительности. Таблицы более высокого уровня и структура схемы обычно не изменяются между подсистемами, но типы столбцов индекса и таблицы могут изменяться по причинам хранения и производительности. Хотя известно, что InnoDB имеет большие размеры файлов данных, эти сведения о хранилище управляются в службе "База данных Azure для MySQL".

Миграция из MyISAM в InnoDB

Базу данных и таблицы MyISAM необходимо преобразовать в таблицы InnoDB. После преобразования приложения необходимо протестировать на совместимость и производительность. В большинстве случаев для тестирования требуется повторное создание таблицы и изменение целевой подсистемы хранилища с помощью инструкций DDL. Маловероятно, что это изменение необходимо выполнить во время миграции, так как она происходит во время создания схемы в целевом объекте Azure. Дополнительные сведения см. в документации по преобразованию таблиц для разработчиков на веб-сайте MySQL.

Чтобы найти полезные сведения о таблице, используйте следующий запрос:

    SELECT
        tab.table_schema,
        tab.table_name,
        tab.engine as engine_type,
        tab.auto_increment,
        tab.table_rows,
        tab.create_time,
        tab.update_time,
        tco.constraint_type
    FROM information_schema.tables tab
    LEFT JOIN information_schema.table_constraints tco
        ON (tab.table_schema = tco.table_schema
            AND tab.table_name = tco.table_name
            )
    WHERE
        tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
        AND tab.table_type = 'BASE TABLE';

Чтобы преобразовать таблицу из MyISAM в InnoDB, выполните следующую команду:

ALTER TABLE {table\_name} ENGINE=InnoDB;

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

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

Данные и объекты базы данных

Данные — это один из компонентов миграции базы данных. Объекты, поддерживающие базу данных, необходимо перенести и проверить, чтобы обеспечить надежную работу приложений.

Ниже приведен список элементов для инвентаризации до и после миграции:

• таблицы (схема);

• первичные ключи, внешние ключи;

• Индексы

• Функции

• Процедуры

• Триггеры

• Представления

Определяемые пользователем функции

MySQL позволяет использовать функции, вызывающие внешний код. К сожалению, рабочие нагрузки данных, использующие определяемые пользователем функции (UDF) с внешним кодом, невозможно перенести в Базу данных Azure для MySQL. Это обусловлено тем, что на сервере Azure не удается передать код, необходимый для работы функции MySQL, или DLL-код.

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

SELECT * FROM mysql.func;

Системы устройств

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

Кроме того, перемещение данных через Интернет может быть медленнее, чем использование выделенных каналов в Azure. Поэтому при перемещении большого объема данных (гигабайты, терабайты и петабайты) рекомендуется настроить подключение ExpressRoute между исходной сетью и сетью Azure.

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

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

Поставщики облачных служб

Миграция баз данных из поставщиков облачных служб, таких как Amazon Web Services (AWS), может потребовать дополнительного шага конфигурации сети для доступа к экземплярам MySQL, размещенным в облаке. Средства миграции, такие как Службы миграции данных, требуют доступа из внешних диапазонов IP-адресов и могут быть заблокированы в противном случае.

Локально

Как и в случае с поставщиками облачных служб, если рабочая нагрузка данных MySQL находится за брандмауэрами или другими уровнями безопасности сети, необходимо создать путь между локальным экземпляром и Базой данных Azure для MySQL.

Инструменты

Для оценки рабочих нагрузок и окружений данных MySQL можно использовать множество средств и методов. Каждый инструмент предоставляет отличающийся набор функций и возможностей оценки и миграции. В рамках этого руководства мы рассмотрим наиболее часто используемые средства для оценки рабочих нагрузок данных MySQL.

Миграция Azure

Хотя Миграция Azure не поддерживает прямую миграцию рабочих нагрузок базы данных MySQL, ее можно использовать, когда администраторы не уверены, какие пользователи и приложения используют эти данные (размещенные на виртуальной или аппаратной машине). Анализ зависимостей можно выполнить, установив и запустив агент мониторинга на компьютере, на котором размещена рабочая нагрузка MySQL. Агент собирает данные в течение заданного периода, например месяца. Данные зависимостей можно проанализировать, чтобы найти неизвестные соединения с базой данных. С помощью данных подключения можно определить владельцев приложений, которые должны получать уведомления о состоянии ожидания миграции.

Помимо анализа зависимостей приложений и данных о подключении пользователей, службу "Миграция Azure" также можно использовать для анализа Hyper-V, VMware или физических серверов с целью предоставления вариантов использования рабочих нагрузок базы данных, чтобы помочь определить правильную целевую среду.

Telgraf для Linux

Рабочие нагрузки Linux могут использовать Microsoft Monitoring Agent (MMA) для сбора данных на виртуальных и физических компьютерах. Кроме того, рекомендуется использовать агент Telegraf и его широкий массив подключаемых модулей для сбора метрик производительности.

Уровни службы

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

В настоящее время — три уровня:

• Базовый. Рабочие нагрузки с невысокими вычислительными потребностями и производительностью операций ввода-вывода.

• Уровень Общего назначения. Предназначен для большинства рабочих нагрузок для бизнеса, которым требуются сбалансированные вычислительные ресурсы и память с масштабируемой пропускной способностью операций ввода-вывода.

• Уровень Оптимизировано для памяти. Предназначен для рабочих нагрузок базы данных с высоким уровнем производительности, требующих обработки в памяти для ускоренной обработки транзакций и повышенного параллелизма.

На решение об уровне могут повлиять требования RTO и RPO рабочей нагрузки данных. Если для рабочей нагрузки данных требуется более 4 ТБ хранилища, необходимо выполнить дополнительный шаг. Проверьте и выберите регион, который поддерживает использование до 16 ТБ хранилища.

Как правило, при принятии решения основное внимание уделяется объему хранилища и операциям ввода-вывода в секунду. Таким образом, для целевой системы всегда требуется как минимум столько же хранилищ, сколько есть в исходной системе. Кроме того, так как для операций ввода-вывода выделено 3 ГБ, важно сопоставить необходимое количество операций ввода-вывода с размером конечного хранилища.

Затраты

После оценки всех рабочих нагрузок данных WWI MySQL в WWI определено, что потребуется как минимум 4 виртуальных ядра и 20 ГБ памяти, а также как минимум 100 ГБ дискового пространства с емкостью 450 операций ввода-вывода в секунду. С учетом 450 операций ввода-вывода в секунду и метода, которым База данных Azure для MySQL их распределяет, необходимо выделить не менее 150 ГБ памяти. Кроме того, требуется до 100 % от подготовленного хранилища сервера в качестве хранилища резервных копий и одной реплики чтения. Не предполагается исходящий трафик более чем 5 ГБ.

С помощью калькулятора цен для Базы данных Azure для MySQL в WWI можно было определить затраты на экземпляр Базы данных Azure для MySQL. Начиная с сентября 2020 г. совокупная стоимость владения (TCO) отображается в следующей таблице для базы данных конференций WWI.

Изучив начальные затраты, руководитель WWI подтвердил, что Azure используется в течение более 3 лет. Решено использовать 3-летние зарезервированные экземпляры для экономии около 4000 долл. США в год.

Как показано в таблице выше, резервные копии, исходящий трафик сети и любые реплики чтения должны учитываться в совокупной стоимости владения (TCO). По мере добавления дополнительных баз данных генерируемые хранилище и сетевой трафик являются единственным дополнительным фактором затрат, который следует учитывать.

Влияние на приложения

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

Выполните действия, описанные в статье о настройке подключения SSL в приложении для безопасного подключения к Базе данных Azure для MySQL, чтобы настроить приложение для поддержки этого пути строгой проверки подлинности.

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

Сценарий WWI

WWI начинает выполнять оценку, собирая сведения о соответствующем пространстве данных MySQL, как показано в таблице ниже.

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

На первом этапе WWI фокусировалась исключительно на базе данных ConferenceDB. Команде был необходим опыт миграции, чтобы выполнить миграции рабочих нагрузок обработки данных. Выбор пал на базу данных ConferenceDB из-за ее простой структуры и длительного допустимого времени простоя. После переноса базы данных группа сфокусировалась на переносе приложения в безопасную целевую зону Azure.

Контрольный список оценки

• Протестируйте успешное выполнение рабочей нагрузки в целевой системе.

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

• Ознакомьтесь с требованиями для ресурсов рабочей нагрузки данных.

• Оцените общие затраты.

• Ознакомьтесь с требованиями для простоя.

• Будьте готовы внести изменения в приложения.

Следующий шаг