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

Безперервна доставка або постійне розгортання інфраструктури та коду порівняно просто, порівняно із спробами однакових підходів до баз даних, зокрема RDBMS. Код та інфраструктура не змінюватимуться та не змінюватимуться після завершення розгортання. Однак до баз даних будуть додані нові дані, що дають дані, якщо не схема, яка є властивою для зміни компонентами.

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

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

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

Прамод Садаладж та Скотт Амблер написали книгу Refactoring Databases: Evolutionary Design Database, яка є неймовірно твердим букварем до теми БД в CD / команді CD.

Виклики

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

На одній з компаній, в якій я працював, попереднє вікно з необробленими даними становило приблизно 6 місяців і з'їло 10 ТБ. Потім дані були оброблені у форматі RDBMS, який коштував 6 ТБ корисних даних, що склало близько 10 років даних, що підлягають звітності. Справа в тому, що в масштабах подібні практики просто не практичні. Зберігання дорого - мабуть, найбільший обчислювальний витрата. Це забезпечує декілька цікавих проблем:

1. Резервні копії - плагіни innodb чудові і всі, але час резервного копіювання на стільки даних просто не такий практичний
2. Часи відновлення - для великих наборів даних - особливо якщо вам потрібна реплікація, щоб наздогнати після відновлення, повернення в робочий стан може зайняти дні або навіть тижні
3. Створення / висівання нових екземплярів. Часто робота, яку ви можете виконувати в програмі dev / test, включає завдання ETL (Extract, Transform and Load) на своєму наборі даних. Вони повинні бути підтверджені за допомогою тестувань з контролю якості, але це потрібно зробити неруйнівним чином, щоб зберегти вихідний набір даних про виробництво. Перебуваючи в катастрофі, ви, можливо, будете готові боротися з тривалим часом відновлення, розуміючи, що резервні копії - це страховий поліс, а намір уникнути їх, робочий процес розвитку DevOps вимагає, щоб ви, по суті, змогли відновити або регулярно копіювати свої дані (можливо, кілька разів на день)
4. Ємність - переміщення навколо такої кількості даних у масштабі, який я щойно описав, може бути дуже інтенсивним введення-виведення. Не тільки вам потрібно вирішувати проблеми, описані в 1-3, але це потрібно робити таким чином, щоб не викликати відключення або уповільнення продуктивності ваших виробничих систем.

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

Визначення вимог

Як результат, вам потрібно визначити кілька вимог:

1. RTO - RTO або час відновлення для резервного копіювання є одним з найважливіших драйверів рішень для резервного копіювання бази даних. Хоча спочатку це може здатися нерелевантним для більшості інших проблем, воно стає надзвичайно актуальним, коли ви запитуєте "Що робити, якщо я використовував своє резервне рішення для створення чи висіву нових екземплярів?". Я розповім про деякі прийоми цього в наступному розділі.
2. RPO - RPO або пункт Restore Point для резервного копіювання визначає A) наскільки далеко ви зможете відновити (хвилини, години, дні, тижні, місяці або роки) B) Інтервал резервного копіювання на різних рівнях і C) як детально ви можете відновити . Наприклад, для баз даних електронної пошти часто шукають резервні копії рівня повідомлень - відновлення конкретної електронної пошти. Так само ви можете виявити, що дані за кілька днів є абсолютно марними - тому немає сенсу відновити рік назад.
3. Розмір вашого набору даних - Це важливо, оскільки для бази даних 1МБ ваш RTO може бути досягнутий за допомогою більшості резервних продуктів та рішень. Однак у базі даних 10TB ви побачите, що резервне копіювання на рівні рядків на стрічці LTO 3, ймовірно , не досягне вашої RTO і може заважати вашому RPO, оскільки резервні копії починають перевищувати вікно резервного копіювання. Ви не можете точно виконати mysqldump на цьому великому наборі даних, але, ймовірно, можна піти з цього в базі даних 1MB.
4. Узгодженість бази даних - остаточна річ, яка суттєво відрізняється в постійному розгортанні, надійності сайту, масштабованості та високій доступності під час роботи з базами даних - це ваша потреба (або її відсутність) для послідовності. Існує три основні типи: негайна консистенція, узгодженість за часом (JIT) та можлива послідовність

Крім перерахованих вище головних міркувань, вам також потрібно врахувати вимоги щодо ліцензування та підтримки (відкритий чи закритий джерело; у службі підтримки, підтримка третьої сторони чи підтримка постачальників) вимоги / мова мови (роз'єми для багатьох баз даних можуть бути важливими; це ваш додаток складено? Чи маєте ви доступ до вихідного коду? Чи можете ви його перекомпілювати, чи він надається постачальником? Або він працює на інтерпретованій мові?) політичні вимоги (Чи довіряє ваша організація лише Oracle? Чи ненавидять вони оракул "Вони не довіряють MySql? Як ви ставитесь до MariaDB чи Postgres?) Та двигуна баз даних (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) Та історичних вимог чи вимог щодо сумісності (ми використовували PL / SQL протягом півтора років та нашого коду вбудований у двигун oracle! Як ми могли коли-небудь перейти на MariaDB?!?)

Все це (суттєво) впливає на доступні вам інструменти.

Деякі параметри внутрішнього управління даними

Примітка. Далі не є вичерпним, і інші користувачі SE повинні шукати додаткові пропозиції.

Не виходячи із загальних міркувань, дозвольте надати вам деякі прийоми та технології вирішення вищезазначеного. По-перше, запитайте себе, чи дійсно вам потрібно використовувати RDBMS або якщо неструктуровані дані з чимось на зразок Hadoop, CouchDB або навіть об'єктно-орієнтоване сховище (щось на кшталт swift) - це варіант.

По-друге, розглянути питання про хмарне рішення. Це передає частину цього головного болю і залишає складні проблеми висококваліфікованим (і платним) людям. Однак, за масштабами, ви можете виявити, що це дійсно їсть у вашому бюджеті (хмарні постачальники НЕ роблять прибуток на цьому, і в певному масштабі ви можете просто дозволити собі наймати цих експертів), або якщо ви працюєте в умовах конкретної безпеки або політичної політики вимоги (читайте: ми не можемо робити хмари) розглянемо гібридний NFS / FibreChannel Filer. Більшість цих файлів, таких як NetApp, Pure Storage та Tegile, підтримують техніку зйомки та клонування на основі дельти, яка може бути дуже зручною для A) здійснення резервних копій, B) Відновлення резервних копій та C) Посіву нових резервних копій.

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

Але , маючи на увазі, ці продукти дозволяють робити різні знімки під вашою базою даних. Вам потрібно буде виписати повні "таблиці блокування з блокуванням читання" на одному з екземплярів вашої бази даних (рекомендується тільки підлеглий для читання) і скинути своє бінгове положення або GTID, але для цих файлів, як тільки ви це зробите, ви зможете використовувати ці знімки для створення нових примірників вашої бази даних. Ви хочете поставити бінлоги на окремий розділ і розмістити на цих розділах лише дані вашої бази даних. Після цього ви зможете клонувати ці розділи (у NetApps це відомо як " FlexClone "

Це тому, що для кожного зчитуваного блоку філлер повинен визначати, чи містяться дані на замороженому оригінальному знімку або в дельті. Для томів / магазинів з кількома знімками це може знадобитися перевірити кілька разів. Ви можете подолати це, оновивши дані (значить, відкиньте знімок та повторно клонуйте їх періодично - що може статися природним та органічним шляхом для хорошого середовища безперервного розгортання) або шляхом постійного розподілу обсягу (відомого як "Flex Split" в термінології NetApp ), який потребує моменту, щоб назавжди вирішити дельти і створити абсолютно новий і окремий том.

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

Єдина хитрість тут полягає в тому, що це може не являти собою повноцінного резервного рішення, оскільки "резервна копія" все ще знаходиться на вашому файлі. Для цього вам може знадобитися щось, що NetApp викликає дзеркало Snap, яке буде відображати дані (використовуючи технологію стилю rsync) між файлами та навіть центрами обробки даних, або використовувати якийсь тип інтегрованого рішення для резервного копіювання, яке може створити резервну копію на стрічку одного з ваших знімків дельти флекс-клон.

Однак це має один головний недолік: усі ваші дані - dev, test та prod все ще використовують введення-вивід на тому ж файлі та накопичувачі. Щоб вирішити цю проблему, спробуйте створити екземпляр підлеглого бази даних для другого файлера, який може бути точкою висіву для вас Тестового та / або файлового розробника, або подумайте про використання контролера доставки навантажувача / програми для свого додаткового рівня для відображення запитів виробництва у вашій програмі тестування (та / або розробник) оточення. Це має додаткову перевагу від викиду трафіку виробництва у вашому середовищі QA / Test перед тим, як сприяти виробництву з питань, які можуть бути негайно помічені. Потім ви можете перевірити свої журнали на наявність помилок на основі виробничого трафіку та поведінки користувача.

Тоді це дозволить вам використовувати кілька скриптів для програмного нерестування та знищення цілих (і великих) наборів даних для використання з методологіями безперервного розгортання.

Масштабованість та висока доступність

Поки ви запитували про безперервне розгортання, DevOps цікавиться не просто постійним розгортанням - тому я збираюся включити деякі біти про надмірність, масштабованість та високу доступність.

Я згадав, JIT, негайну та можливу послідовність. Тут надходять різноманітні двигуни RDBMS. Побічна консистенція порівняно проста, просто налаштувавши кругову асинхронну реплікацію. Це може спричинити деякі зіткнення * (що робити, якщо ваш додаток рівень оновлює дані на одній стороні кластера та на іншій стороні кластера до завершення реплікації?) Для негайної послідовності подивіться на кластер Galera, який змусить синхронну реплікацію, але викликає проблеми з масштабованістю (як ви будете реплікувати на сайт відновлення після катастроф або завантажувати баланс географічно, не несучи значної затримки через затримку запису на мережевому шарі?) Ви також можете бачити, чи можете ви робити синхронну реплікацію в центрі обробки даних та асинхронну реплікацію між сайтами, але це здається найгіршим з обох світів.

Однак, як правило, більшість поеплів не потребують повністю синхронної реплікації - зазвичай це потрібно лише для дуже специфічних (і екзотичних) середовищ із високим рівнем запису, де потрібен мультимайстер із набиванням таблиці. Більшість додатків можуть вирішувати консистенцію Just-in-Time, використовуючи проксі-сервер бази даних. Наприклад, ScaleArc буде стежити за станом реплікації і відстежувати, куди щойно пішла запис (для надсилання підрядних запитів на читання, поки реплікація не наздогнає), щоб забезпечити послідовність і зовнішній вигляд Just-In-Timeузгодженості бази даних. ScaleArc можна порівняти з Postgres, MySQL, MariaDB, Oracle та MSSQL і може використовувати регулярні вирази для розміщення / розділення ваших баз даних для програм, які не можуть використовувати клавіші осколки. Він також має надійний REST API для вашого програмного забезпечення для управління конфігурацією для взаємодії - і їх команда підтримки є видатною

Так само ви можете розглянути безкоштовну альтернативу MaxScale, розроблену командою MariaDB для MariaDB. Однак у ньому відсутній графічний інтерфейс та деякі функції кешування ScaleArc.

Нарешті, тканина MySQL (і кластер MySQL лише в ОЗУ - якщо ви можете дозволити собі стільки оперативної пам’яті) - це інші потенціали - особливо з новим проксі-сервером MySQL. Це може забезпечити компонент масштабованості та надмірності для вашого оточення.

Postgres і Oracle повинні мати необхідні функції реплікації та загострення, але ScaleArc добре поєднується, якщо вам потрібен проксі.

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

Ми використовуємо Flyway в роботі для керування схемами Postgres в додатку, а Pillar - для управління схемами Кассандри. Ми знайшли найкраще, якщо програма керує власною схемою.

У нас був жахливий досвід роботи із схемами ansible управління до того, як програми керували своїми схемами.

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

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

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

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

У своїй роботі ми використовуємо liquidibase, і я за це висловлюсь дуже. Він також використовується нашим QA-інструментом QASymphony .

Ми використовуємо його у внутрішніх базах MSSQL та Oracle, а QASymphony використовує / використовує його з обома екземплярами postgres + mysql.

Щоб відповісти на це запитання в контексті середовища мейнфрейму та специфічних для баз даних DB2®, типово є 2 загальновживаних (не дешевих ...) альтернативи для вибору:

• Адміністрування об'єктів для DB2® , від BMC. Ось кілька деталей про це (цитата на пов'язаній сторінці):

  Внесення змін до об'єктів у вашій базі даних (або навіть просто виконання звичайних адміністративних завдань) може бути важкою, ризикованою роботою. Є кілька десятків завдань, які слід відслідковувати, і один пропуск може негативно вплинути на доступність та цілісність даних. Ви можете скоротити і зусилля, і ризик, за допомогою BMC Object Administration для DB2 11, колекції інструментів, які допоможуть вам:

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

• Інструмент адміністрування DB2 для z / OS від IBM.

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

  • Дозволяє користувачам швидко та легко переходити по каталогу DB2
  • Створює та виконує динамічні оператори SQL, не знаючи точного синтаксису SQL
  • Керує та відстежує зміни, внесені до визначень об'єкта DB2, що вирішують будь-які потенційні конфлікти перед виконанням
  • Допомагає будувати команди DB2 для виконання проти баз даних та таблиць
  • Дозволяє користувачам створювати, змінювати, мігрувати, видаляти та повертати об’єкти DB2 інженера
  • Створює та виконує утилітні завдання, дозволяючи користувачам скористатися LISTDEF та TEMPLATE для підвищення продуктивності

Інтеграція з інструментами SCM

Деякий час тому мене закликав клієнт фактично "інтегрувати" альтернативу BMC у свій життєвий цикл SCM (керований SERENA ChangeMan ZMF ). Ідея такої інтеграції полягає в тому, щоб " розглянути нашу команду DBA DBA (робити речі з DDL) як особливий випадок команди розробників, випадково використовуючи якийсь екзотичний редактор (інструмент BMC) для створення коду (DDL) для міграції ".

Однією (але реальною !) Проблемою цієї інтеграції було також сприяти "перезавантаження", що є однією з ключових переваг такого інструменту DBA:

• Ретабельність означає, що коли цей інструмент DBA робить свою справу (іноді тривалими робочими завданнями, відповідно до характеру роботи, яку потрібно виконати), можуть статися несподівані речі (тупики, часові відхилення тощо).

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

• Ще краще (чи я повинен сказати «ще гірше»?), Якщо новачок до інструменту DBA не знає, як перезапустити з такої контрольної точки, і просто спробує ще раз (з початку), тоді інструмент DBA просто вийде з ладу з якоюсь помилкою користувача. І це з вказівкою з чимось на кшталт " Поки ти не скажеш мені, як ти хочеш, щоб я продовжував діяти після останнього моменту відмови, я відмовляюся робити що-небудь (щоб не зробити речі ще гіршими) ".

• Зрештою, справжня підказка, яка реалізує цю перезапуск у використаному інструменті SCM, також вимагала налаштування інструменту SCM. Насправді, щоб дозволити його використовувати для повторного запуску невдалих процедур SCM (як правило, пов'язаних з поставками в цільове середовище тесту / продукту) ... замість того, щоб просто знову подавати невдалу процедуру SCM (як правило, ці інструменти SCM відновлюються з таких ситуацій ).

Бонус: після завершення інтеграції SCM альтернативи BMC клієнт вирішив змінити свій інструмент DBA на альтернативу IBM. І хоча обидві альтернативи насправді не виглядають однаково, вплив цього на інтеграцію в SCM був досить мінімальним: просто питання заміни (у налаштуваннях багаторазового використання SCM) деяких викликів на альтернативу BMC еквівалентними дзвінками до IBM альтернатива ... яка (використовуючи термінологію DevOps) реалізована за допомогою функцій-прапорів / функцій-перемикачів .