Миграция данных MySQL в База данных Azure для MySQL — согласованный моментальный снимок MySQL
Последовательный моментальный снимок MySQL — это новая функция, которая позволяет пользователям создавать согласованные моментальные снимки сервера MySQL без потери целостности данных в источнике из-за текущих операций CRUD (создание, чтение, обновление и удаление). Согласованность транзакций достигается без необходимости задать исходному серверу режим только для чтения с помощью этой функции. Кроме того, существует несколько параметров согласованности данных, представленных пользователю: включение согласованного моментального снимка с блокировкой чтения (GA), включение согласованного моментального снимка без блокировки (предварительная версия), только для чтения исходного сервера и нет. При выборе параметра "Нет" не применяются дополнительные меры, чтобы обеспечить согласованность данных. Оба варианта — включение согласованного моментального снимка с помощью блокировки чтения (GA), включение согласованного моментального снимка без поддержки блокировки при миграции через Интернет. Мы настоятельно рекомендуем выбрать параметр "Включить согласованный моментальный снимок без блокировок" для поддержания согласованности транзакций.
Включение согласованного моментального снимка без блокировок (предварительная версия)
При включении этого параметра после начальной загрузки будет происходить этап выверки. Это гарантирует, что данные, записанные в целевой объект, транзакционно согласованы с исходным сервером из определенной позиции в двоичном журнале.
С этой функцией мы не берем блокировку чтения на сервере. Вместо этого мы считываем таблицы в разные точки времени, сохраняя отслеживание разных позиций binlog каждой таблицы. Это помогает примирить таблицы в конце начальной нагрузки, выполняя репликацию в режиме перехвата, чтобы получить согласованный моментальный снимок.
Ключевые функции согласованного моментального снимка без блокировок:
- Возможность поддерживать большие серверы рабочей нагрузки или серверы с длительными транзакциями без необходимости блокировки чтения.
- Устойчивость при выполнении миграции даже в случае сбоев, вызванных временными перебоями сети или сервера, что приводит к потере всех предварительно созданных подключений.
Включение согласованного моментального снимка с помощью блокировки чтения (GA)
Если этот параметр включен, служба очищает все таблицы на исходном сервере с блокировкой чтения , чтобы получить моментальный снимок на момент времени. Эта очистка выполняется, так как глобальная блокировка является более надежной, чем попытка заблокировать отдельные базы данных или таблицы. В результате, даже если вы не переносите все базы данных на сервере, они заблокированы в рамках настройки процесса миграции. Служба миграции инициирует повторяемое чтение и объединяет текущее состояние таблицы с содержимым журнала отмены для моментального снимка. Моментальный снимок создается после получения широкой блокировки сервера в течение нескольких секунд и создания нескольких подключений для миграции. После создания всех подключений, используемых для миграции, выдается блокировка таблицы.
Повторяемые операции чтения поддерживают доступ к журналам отмены во время миграции, что увеличивает объем хранилища, необходимого для источника из-за длительных подключений. Длительный перенос с несколькими изменениями таблицы приводит к обширному журналу журналов отмены, который необходимо воспроизвести, а также может увеличить требования к вычислениям и нагрузку на исходном сервере.
Создание только для чтения исходного сервера
При выборе этого параметра сохраняется целостность данных целевой базы данных по мере переноса источника путем предотвращения операций записи и удаления на исходном сервере во время миграции. Когда исходный сервер читается только как часть процесса миграции, выбор применяется ко всем базам данных исходного сервера независимо от того, выбран ли он для миграции.
При чтении исходного сервера пользователи не могут изменять данные, отрисовка базы данных недоступна для любых операций обновления. Однако если этот параметр не включен, во время миграции может возникнуть возможность обновления данных. В результате перенос данных может быть несогласованным, так как моментальные снимки базы данных будут считываться в разные моменты времени.
Необходимые условия для включения согласованного моментального снимка с блокировкой чтения
Чтобы успешно выполнить миграцию с поддержкой согласованного моментального снимка с включенным блокировкой чтения:
Убедитесь, что пользователь, который пытается очистить таблицы с блокировкой чтения, имеет разрешение RELOAD или FLUSH.
Используйте клиентское средство mysql, чтобы определить, включена ли log_bin на исходном сервере. Журнал bin не всегда включен по умолчанию и должен быть проверен, чтобы узнать, включена ли она перед началом миграции. Клиентское средство mysql используется для определения того, включена ли log_bin в источнике, выполнив команду : SHOW VARIABLES LIKE 'log_bin';
Примечание.
При использовании одного сервера База данных Azure для MySQL, который поддерживает до 4TB, этот параметр по умолчанию не включен. Однако если вы повышаете уровень реплики чтения для исходного сервера, а затем удаляете реплику чтения, параметр имеет значение ON.
- Настройте параметр binlog_expire_logs_seconds на исходном сервере, чтобы убедиться, что файлы binlog не очищаются до фиксации реплики изменений. После успешного перехода можно сбросить значение.
Известные проблемы и ограничения для включения согласованного моментального снимка без блокировки
- Таблицы с внешними ключами с каскадным или заданным значением NULL для предложения удаления или обновления не поддерживаются.
- Во время начальной загрузки изменения DDL не должны возникать.
Известные проблемы и ограничения для включения согласованного моментального снимка с блокировкой чтения
Известные проблемы и ограничения, связанные с согласованной резервной копией, падают широко в две категории: блокировки и повторные попытки.
Примечание.
Служба миграции выполняет запрос START TRANSACTION WITH CONSISTENT SNAPSHOT для всех рабочих потоков, чтобы получить моментальный снимок сервера. Но это поддерживается только InnoDB. Дополнительные сведения см. здесь.
Блокировки
Как правило, это простой процесс получения блокировки, который должен занять от нескольких секунд до нескольких минут. Однако в некоторых сценариях попытки получить блокировку на исходном сервере могут завершиться ошибкой.
Наличие длительных запросов может привести к ненужным простоям, так как DMS может заблокировать подмножество таблиц, а затем время ожидания последнего числа доступных. Перед началом миграции проверьте наличие длительных операций, выполнив команду SHOW PROCESSLIST .
Если исходный сервер испытывает много обновлений записи во время запроса блокировки, блокировка не может быть легко получена и может завершиться ошибкой после ожидания блокировки. Это происходит в случае задач пакетной обработки в таблицах, которые при выполнении могут привести к отказу запроса на блокировку. Как упоминалось ранее, запрошенная блокировка является одной глобальной блокировкой для всего сервера, поэтому даже если выполняется обработка одной таблицы или базы данных, запрос на блокировку должен ожидать завершения текущей задачи.
Другое ограничение связано с миграцией с исходного сервера AWS RDS. RDS не поддерживает таблицы очистки с блокировкой чтения и запрос LOCK TABLE выполняется на выбранных таблицах под капотом. Так как таблицы блокируются по отдельности, процесс блокировки может быть менее надежным, и блокировки могут занять больше времени для получения.
Повторы
Миграция обрабатывает временные проблемы подключения и дополнительные подключения обычно подготавливаются заранее для этой цели. Мы рассмотрим параметры миграции, особенно количество параллельных операций чтения в источнике и применяем фактор (обычно ~1,5) и создадим столько подключений, сколько вперед. Таким образом служба обеспечивает параллельное выполнение операций. В любой момент времени, если возникает потеря подключения или служба не может получить блокировку, служба использует избыточные подключения, подготовленные для повторной миграции. Если все подготовленные подключения исчерпаны, что приводит к потере синхронизации на момент времени, миграция должна быть перезапущена с самого начала. В случае успеха и сбоя все действия очистки выполняются этой автономной службой миграции, и пользователю не нужно выполнять никаких явных действий по очистке.