Міграція бази даних в 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, пам’яттю, сховищем і журналом, станом реплікації та резервування, завданнями, інтеграціями, сигналами безпеки й зверненнями до підтримки. Порівнюйте і з цілями, і з початковим рівнем джерела.

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

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

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

Коли корисна незалежна перевірка міграції

Незалежна перевірка корисна, коли джерело погано описане, ціль змінює рушій або операційну модель, час простою жорстко обмежений, транзакції бізнесу охоплюють кілька систем, якість даних невідома, потрібні докази відповідності або попередні репетиції дали непояснені розбіжності. Вона також доречна до вибору цілі переважно за ліцензією чи калькулятором постачальника.

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

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

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