Миграция базы данных в Azure: оценка, переключение и возврат

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

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

Способ миграции выбирайте после изучения пары «источник — цель». Если бизнес допускает достаточное окно простоя, автономная копия может быть безопаснее и проще. Репликация во время работы сокращает окончательный перерыв, но добавляет требования к связности, журналированию, отставанию, согласованности, наблюдению и обработке неудачного переключения. «Почти без простоя» — свойство всего плана, а не флажок в средстве миграции.

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

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

Соберите показательные данные о быстродействии за разные циклы бизнеса. Записывайте использование CPU, памяти, пропускную способность хранилища и журнала, IOPS, задержку, соединения, одновременность, ожидания, блокировки, долгие запросы, временные данные, частоту транзакций, окна пакетной работы и пиковый рост. Одни настройки подталкивают к избыточному размеру, а один тихий день — к недостаточному. Явно указывайте период наблюдения и отсутствующие сведения.

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

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

Выбирайте цель в Azure по соответствию и границе ответственности

Выбирайте цель по требуемому поведению движка и объёму эксплуатационной ответственности, который команда способна поддерживать. Для систем на SQL Server служба Azure SQL Database предоставляет в значительной мере управляемую границу базы данных; Azure SQL Managed Instance сохраняет больше совместимости на уровне экземпляра; SQL Server on Azure Virtual Machines оставляет контроль операционной системы и экземпляра, но требует больше администрирования. Движки с открытым кодом имеют собственные управляемые цели и ограничения в Azure. Это не взаимозаменяемые ценовые уровни.

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

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

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

Превратите выявленные несовместимости в план исправлений

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

Для каждого исправления определите ответственного, способ реализации, проверку и срок. Одни объекты можно преобразовать; другим место в коде приложения, платформе заданий или отдельной службе. Сохраняйте правила бизнеса, а не механически воспроизводите устаревший механизм. При смене движка проверьте создаваемый SQL, сопоставления ORM, семантику транзакций, работу дат и чисел, идентификаторы, постраничный вывод, коды ошибок и одновременность.

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

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

Проектируйте перенос данных как управляемый процесс

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

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

Спроектируйте связность и идентификацию до репетиции. Ограничьте права необходимыми операциями, защитите учётные данные, проверьте DNS и сертификаты, учтите межсетевые экраны и частные конечные точки и обеспечьте наблюдение за потоком миграции. Шифруйте данные при передаче и хранении в соответствии с их классом. Не переносите чувствительные производственные данные в неконтролируемые испытательные среды.

Сделайте процесс пригодным для повторного запуска. Делите большой перенос на части или контрольные точки, если средство это поддерживает; записывайте состояние объектов и продвижение в строках или байтах; определите правила повтора, предельное время и передачу сбоев ответственным. Повторный запуск частично завершённого преобразования не должен дублировать, пропускать или портить данные. Храните журнал, связывающий результаты средства, исправления, проверки и согласования.

Почти непрерывная работа зависит от дисциплины переключения

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

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

Учтите каждого, кто записывает данные. Веб-приложения очевидны, но часто забывают обработчики, запланированные задания, ETL, средства отчётности, интеграции, администраторов и мобильные программы с накопленными действиями. Решите, отклонять, накапливать, приостанавливать или впоследствии согласовывать записи во время перехода. Не полагайтесь на неформальную просьбу «ничего не менять».

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

Докажите быстродействие, целостность и возможность возврата

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

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

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

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

Оптимизируйте только после стабилизации новой основы

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

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

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

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

Когда полезна независимая проверка миграции

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

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

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

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