Як ви оновлюєте свою виробничу кодову базу / схему бази даних, не викликаючи простоїв?

42

Які існують методи оновлення схеми бази / бази даних коду виробничого сервера, не викликаючи простоїв?

deployment

1

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

— Ден МакГрат

@ Дан МакГрат: який, припустимо, у вас може бути час простою, я працюю в системі, яка (як правило) знижується лише 4 рази на рік (чверть відключення) і максимум 15 хвилин щоразу (за цей час трафік в черзі). .. Зміни в базі даних ретельно вивчаються :)

— Матьє М.

2

Це було б чудовим питанням для dba.stackexchange.com , який за кілька годин переходить у загальнодоступну бета-версію.

— Ларрі Коулман

20

Як правило, веб-сайти, над якими я працював, мали такі вимоги, що стоять поза балансовими навантаженнями або мали окремі місця відмови. У цьому прикладі я припускаю, що у вас є один балансир навантаження, 2 веб-сервери (A&B) та 2 сервери баз даних (M&N - зазвичай сервери БД підключаються через логшинг - принаймні в світі SQL Server ).

Відключити веб-сервер від балансира навантаження (тому весь надходить трафік йде на B).
Доставка журналів припинена (спочатку оновиться сервер DB M).
Оновлення веб-сервера A. Наведіть конфігурацію на сервер DB.
Перевірте і переконайтеся, що оновлення спрацювало (зазвичай люди прямо потрапляють на IP-адресу).
Встановіть балансир завантаження таким чином, щоб існуючі сеанси продовжували переходити до B. Нові сеанси переходять до А.
Зачекайте, коли всі сеанси на B закінчуться (може бути півгодини або більше, зазвичай ми спостерігаємо за трафіком і заплановано перерву на 1 годину).
Оновлення B і N.
Перевірте і переконайтеся, що оновлення спрацювало.
Налаштуйте доставку журналу ще раз і протестуйте, чи він працює.
Встановіть балансир навантаження на регулярний режим роботи.

У дуже складних веб-додатках те, що описано як кроки 1-5, може тривати всю ніч і бути електронною таблицею Excel на 50 сторінок із часом та номерами екстрених служб. У таких ситуаціях оновлення половини системи планується на 18:00 до 6 ранку, залишаючи систему доступною для користувачів. Обробка оновлень для сайту DR зазвичай планується на наступну ніч - просто сподіваюся, що нічого не порушиться в перший день.

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

— Тангурена
джерело

7

Як ви пропонуєте об'єднати нові дані з DB M і DB N? Вони будуть мати нові, оновлені та видалені записи, яких інші не мають.

— шістдесят футів

@Tangurena, ти можеш відповісти на вищезазначений коментар?

— сино

9

Для типових баз даних (наприклад, Oracle) можливо змінити схему бази даних, одночасно виконуючи запити паралельно. Однак воно вимагає певного планування вперед.

Вони є деякими обмеженнями щодо змін, які слід застосувати:

він повинен працювати з існуючим кодом, це означає, що код повинен мати справу зі старою та новою версіями схеми
він не повинен спричиняти таке навантаження на БД, що транзакції припиняться (я дивлюся на вас CREATE INDEX)
він не повинен нести втрату даних (ви не можете скидати та заново створювати таблицю)

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

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

Прості поради щодо планування вперед: завжди вказуйте назви стовпців у ваших запитах БД (не використовуйте SELECT * FROM). Таким чином у вас не буде нових стовпців, що відображаються в старих запитах.

— Матьє М.
джерело

1

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

— Морг.

@Morg .: Не дуже. Для безпеки вам потрібно використовувати змінні змінні, що в рамках, який я використовую (принаймні), вимагає надання змінних для запису, і повинно бути рівно стільки змінних, скільки є вихідні стовпці, таким чином, select *означає, що код порушується, якщо a додається новий стовпець (відсутня змінна для запису в нього). Звичайно, це може бути результатом використання сильно набраної мови.

— Матьє М.

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

— Морг.

@Morg .: Я не бачу, наскільки select *надійніше та безпечніше. Якщо раніше select one, two from ...ви були, то ви тільки використовували oneта two; якщо thirdдодано в таблицю, то ви не використовуєте для цього (тут), тому немає ніяких причин для її отримання. І якщо вам доведеться раптом його використовувати, ви модифікуєте код, так що ви також можете змінити запит у цьому пункті!

— Матьє М.

@Morg .: Ну, здається, ми говоримо один про одного, ймовірно, тому, що наш досвід відрізняється. Я працюю над продуктами, де продуктивність є найважливішою властивістю, і це означає, що selectпотрібно бути максимально вибірковим (і покритим індексом), інакше я тостую (навіть до обов'язкового приєднання). Прошу пробачення, але підхід, який ви описуєте, був цілком невдалим для цих продуктів.

— Матьє М.

5

Не всі системи можуть, вона повинна бути налаштована таким чином, що підтримує її.

Наприклад, одна з наших основних систем, яку я допоміг оновити кілька років тому, повинна бути доступною 24/7. Він складався з декількох рівнів, включаючи чистий рівень зв'язку між шаром користувальницького інтерфейсу за межами сайту та бізнес-шаром. Завдяки способу кодування комунікаційного рівня будь-які майбутні зміни схеми Business Layer або DB можуть бути реалізовані без реального відключення. У гіршому випадку, користувач зазнає паузи на 10-30 секунд, коли зміни набрали чинності.

Якщо зміни були суто кодовими змінами на бізнес-шарі, їх можна було б встановити в чергу і «запустити» з лише затримкою в мілісекунди.

Це могло зробити це тому, що:

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

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

— Ден МакГрат
джерело

1

Ось інша перспектива - від світу вбудованих систем баз даних та вбудованих систем. Вбудовані системи включають різноманітне мережеве / телекомунікаційне інфраструктурне обладнання, і в цій царині вони часто говорять про 99,999% (п'ять 9с) часу роботи.

Ми (McObject) є постачальником сімейства вбудованих системних баз даних eXtremeDB, включаючи високу доступність eXtremeDB.

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

З високою доступністю eXtremeDB існує MASTER екземпляр вашої програми (який може бути одним або декількома процесами) та один або кілька REPLICA-екземплярів вашої програми. Коли репліка встановлює з'єднання з ведучим, вона отримує копію бази даних master через процес, який називається "початкова синхронізація". Це можна зробити, поки головна програма продовжує свою роботу. Щойно синхронізований, він отримує транзакції майстра шляхом реплікації. Таким чином, у репліки завжди є поточні дані і вона може переймати (через процес, який називається відмовою) у випадку відмови майстра.

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

На практиці це означає, що ви можете створити нову версію свого додатка (з новими / скинутими таблицями, новими / скинутими / зміненими полями, новими / випалими індексами), прикріпити цю нову версію вашої програми до майстра, а потім викликати це новіша репліка, щоб стати новим магістром (тобто змусити відмовитись від нової репліки, щоб вона стала майстром, а старий майстер відключився). Voila, ви перенесли свою програму з версії N на N + 1, не порушуючи доступність вашої системи. Тепер можна перейти до оновлення старого майстра та будь-яких інших реплік до версії N + 1.