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

2024-12-18

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

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

Перенос локальной среды MySQL в База данных Azure для MySQL: базовые показатели производительности

Создание резервной копии базы данных

Разумным шагом перед обновлением или миграцией данных будет экспорт базы данных через MySQL Workbench или вручную с помощью команды mysqldump.

С отключением или без отключения

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

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

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

Примечание.

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

Смещение данных

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

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

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

Выполнение миграции

Создание резервной копии базы данных
Создание и проверка целевой зоны в Azure
Настройка параметров исходного сервера
Настройка параметров целевого сервера
Экспорт объектов базы данных (схема, пользователи и т. д.)
Экспорт данных
Импорт объектов базы данных
Импорт данных
Проверка
Сброс параметров целевого сервера
Перенос одного или нескольких приложений

Типичный процесс

Независимо от выбранного метода, некоторые действия будут всегда одинаковыми:

обновление до поддерживаемой версии Azure MySQL;
инвентаризация объектов базы данных;
экспорт пользователей и разрешений.

Миграция в последнюю версию MySQL

В компании WWI база данных Conference работает в версии 5.5, поэтому ее нужно обновить. Руководитель попросил выполнять обновление до последней версии MySQL (сейчас это 8.0).

Есть два способа обновления до версии 8.0:

на месте;
Экспорт и импорт

При принятии решения об обновлении следует запустить средство проверки обновления и выявить любые возможные конфликты. Например, при обновлении до MySQL Server 8.0 это средство проверяет следующие конфликты:

имена объектов базы данных, конфликтующие с резервными словами в MySQL 8.0;
использование кодировки utf8mb3;
использование атрибутов типа ZEROFILL и отображаемой длины;
имена таблиц, конфликтующие с системными таблицами в версии 8.0;
использование временного типа;
имена ограничений внешнего ключа длиннее 64 символов.

Если средство проверки обновления не обнаружит никаких проблем, вы можете спокойно выполнять обновление на месте путем простой замены двоичных файлов MySQL. Для баз данных с обнаруженными проблемами потребуется выполнять экспорт и устранять такие проблемы.

Сценарий WWI

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

Объекты базы данных

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

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

DELIMITER //
CREATE PROCEDURE `Migration_PerformInventory`(IN schemaName CHAR(64))
BEGIN

        DECLARE finished INTEGER DEFAULT 0;
          DECLARE tableName varchar(100) DEFAULT "";

        #get all tables
            DECLARE curTableNames
                CURSOR FOR
                    SELECT TABLE_NAME FROM information_schema.tables where TABL
E_SCHEMA = schemaName;

            -- declare NOT FOUND handler
            DECLARE CONTINUE HANDLER
                FOR NOT FOUND SET finished = 1;

            DROP TABLE IF EXISTS MIG_INVENTORY;

                CREATE TABLE MIG_INVENTORY
                (
                      REPORT_TYPE VARCHAR(1000),
                      OBJECT_NAME VARCHAR(1000),
                  PARENT_OBJECT_NAME VARCHAR (1000),
                      OBJECT_TYPE VARCHAR(1000),
                      COUNT INT
                )
                ROW_FORMAT=DYNAMIC,
                ENGINE='InnoDB';
              INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                     'OBJECTCOUNT', 'TABLES', 'TABLES', COUNT(*)
              FROM
                     information_schema.tables
                where
                     TABLE_SCHEMA = schemaName;
                #### Constraints
              INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                      'OBJECTCOUNT', 'STATISTICS', 'STATISTICS', COUNT(*)
                FROM
                      information_schema.STATISTICS
                WHERE
                      TABLE_SCHEMA = schemaName;
                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                      'OBJECTCOUNT', 'VIEWS', 'VIEWS', COUNT(*)
                FROM
                      information_schema.VIEWS
                WHERE
                      ROUTINE_TYPE = 'FUNCTION' and
                      ROUTINE_SCHEMA = schemaName;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                      'OBJECTCOUNT', 'PROCEDURES', 'PROCEDURES', COUNT(*)
                FROM
                      information_schema.ROUTINES
                WHERE
                      ROUTINE_TYPE = 'PROCEDURE' and
                      ROUTINE_SCHEMA = schemaName;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                       'OBJECTCOUNT', 'EVENTS', 'EVENTS', COUNT(*)
                FROM
                       information_schema.EVENTS
                WHERE
                       EVENT_SCHEMA = schemaName;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                       'OBJECTCOUNT', 'USER DEFINED FUNCTIONS', 'USER DEFINED FUNCTIONS'
        , COUNT(*)
                FROM
                        mysql.func;

                INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
                SELECT
                        'OBJECTCOUNT', 'USERS', 'USERS', COUNT(*)
                FROM
                        mysql.user
                WHERE
                        user <> '' order by user;

                OPEN curTableNames;

                getTableName: LOOP
                        FETCH curTableNames INTO tableName;
                        IF finished = 1 THEN
                              LEAVE getTableName;
                        END IF;

                   SET @s = CONCAT('SELECT COUNT(*) into @TableCount FROM ', schemaName,
'.', tableName);
        #SELECT @s;
            PREPARE stmt FROM @s;
        EXECUTE stmt;
        INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)

                SELECT
                    'TABLECOUNT', tableName, 'TABLECOUNT', @TableCount;
        DEALLOCATE PREPARE stmt;

     END LOOP getTableName;
     CLOSE curTableNames;

   SELECT * FROM MIG_INVENTORY;
END //

DELIMITER ;

CALL Migration_PerformInventory('reg_app');

При вызове этой процедуры в исходной базе данных отображается примерно следующий результат (усеченные данные).

Снимок экрана: усеченные выходные данные.

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

Снимок экрана: функции базы данных.

Пользователи и разрешения

Для успешной миграции необходимо перенести пользователей и разрешения в целевую среду.

Экспортируйте всех пользователей и предоставления разрешений для них с помощью следующего скрипта PowerShell.

$username = "yourusername";
$password = "yourpassword";
mysql -u$username -p$password --skip-column-names -A -e"SELECT CONCAT('SHOW G
RANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user<>''" > Show
Grants.sql;

$lines = get-content "ShowGrants.sql"

foreach ($line in $lines)
{
mysql -u$username -p$password --skip-column-names -A -e"$line" >> AllGrants.sql
}

Создайте новый скрипт PowerShell с помощью PowerShell ISE (см. документацию по настройке).
Задайте имя пользователя для корневого имени пользователя и пароль для пароля корневого пользователя

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

$username = "yourusername";
$password = "yourpassword";
$server = "serverDNSname";
$lines = get-content "AllGrants.sql"

foreach ($line in $lines)
{
mysql -u$username -p$password -h$server --ssl-ca=c:\temp\BaltimoreCyberTrus
tRoot.crt.cer --skip-column-names -A -e"$line"
}

Вы также можете создавать пользователей в Базе данных Azure для MySQL с помощью PowerShell: /azure/mysql/howto-create-users

Выполнение миграции

Завершив подготовку всех базовых компонентов для миграции, вы можете начинать перенос данных. Мы уже упоминали несколько средств и методов. Для WWI они будут использовать путь MySQL Workbench для экспорта данных, а затем импортировать его в База данных Azure для MySQL.

Контрольный список по переносу данных

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

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

Перенос локальной среды MySQL в База данных Azure для MySQL: миграция данных с помощью MySQL Workbench

Поделиться через

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

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

Создание резервной копии базы данных

С отключением или без отключения

Смещение данных

Рекомендации по повышению производительности

Экспорт (Export)

Импорт

Выполнение миграции

Типичный процесс

Миграция в последнюю версию MySQL

Сценарий WWI

Объекты базы данных

Пользователи и разрешения

Выполнение миграции

Контрольный список по переносу данных

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

Обратная связь

Дополнительные ресурсы