Найкращий спосіб перенести величезну базу даних SQL Server із невеликим простоєм через мережу

Визначення проблеми

Наш сервер баз даних потрібно перенести в інший центр обробки даних. Він працює на Microsoft SQL Server 2012 Enterprise (64-бітний) і містить дві бази даних розміром близько 2 ТБ та 1 ТБ.

Ідеально для цього мало часу простою.

Навантаження

Ці бази використовуються для веб-сайту .NET і постійно оновлюються.

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

Цей перемикач в ідеалі буде здійснено лише шляхом зміни записів DNS, щоб вказати на новий сервер БД, переконуючись, що БД не оновлюється.

Крім того, час, зайнятий цією операцією, насправді не має значення, поки перехід з одного сервера на інший (час простою) залишається низьким.

Розглянуті підходи

• Резервне копіювання і відновлення

  Це було зроблено в минулому, але це вимагало великого простою, хоча це робилося через внутрішню мережу, так ефективніше, ніж через Інтернет

• Доставка журналу

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

  Це також здається досить ефективним з точки зору використання ресурсів і не вплине на ефективність роботи майстра.

  Я можу помилитися з таким підходом, тому сміливо виправляйте мене.

• Дзеркальне відображення бази даних

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

• Інші варіанти?

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

Обмеження

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

Версії SQL Server будуть однаковими (64-розрядні Microsoft SQL Server 2012 Enterprise).

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

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

Пряме резервне копіювання та відновлення очевидно поза. Я також не вважав би реплікацію будь-якого типу.

Дзеркальне відображення баз даних налаштовується досить просто, але вимагає підключення в режимі реального часу між двома серверами, налаштування партнерів та кінцевих точок тощо. Групи доступності можуть бути варіантом, але крім ускладнень у мережі, ви також повинні мати обидва сервери як члени одного WSFC - це означає, що вони повинні бути в одному домені. Це не типова установка (або навіть може бути змушена працювати тимчасово) для переміщення центру обробки даних.

Моє голосування було б за доставку журналу. Приємно в тому, що ви можете використовувати резервні копії та резервні копії журналів, які ви вже робите (так?), І не обов'язково мати зв'язок у режимі реального часу між двома базами даних - їм не потрібно знати про кожну інше, вам не потрібно встановлювати кінцеві точки для дзеркального відображення, партнерів, безпеки тощо. Вам просто потрібен спосіб перенести файли зі старого сервера до місця, де вони можуть бути відновлені на новому сервері. Ви можете заздалегідь зробити повне резервне копіювання, перенести його на новий сервер, відновити його, а потім застосувати (можливо, що відрізняється та) додаткові резервні копії журналу з цієї точки аж до моменту перерізання. Процес насправді досить простий, і в Інтернеті є багато підручників щодо доставки журналів, якщо у вас виникли труднощі.

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

Нещодавно я перемістив 15 ТБ через 6 баз даних за допомогою дзеркального відображення. Дуже просто і прекрасно працював за пару секунд часу відмови.

Зміни:

У мене було два нових віртуалізованих SQL-сервери. Бази даних надходили з трьох серверів, які вони просто переросли і впливали на ефективність менших баз даних, розміщених на них.

Процес був дуже простим.

1. Зачекайте завершення повних резервних копій у вихідні
2. Відновлення без відновлення на нових серверах
3. Після відновлення завершіть паузу
4. Виконайте одне додаткове відновлення до останньої резервної копії журналу з оригіналів, не залишаючи відновлення
5. Почніть дзеркальне відображення через усі шість
6. Відновити резервні копії

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

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

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

Спасибі