Виводимо MySQL з середовища
Технології
Як тільки ваша інформаційна система стає робочою (production), з'являється необхідність мати як мінімум дві копії її бази даних. Перша, резервна, з деякою частотою створюється за допомогою штатних утиліт і являє собою узгоджений дамп (consistent dump). Мета його створення - відновлення системи після збою (disaster recovery).
Ми ж розглянемо створення другої копії, необхідної для продовження роботи над проектом. Стаття орієнтована на розробників, які тільки вступають на тернистий шлях управління якістю. І марна тим, хто вже знає, що «друга копія» насправді не зовсім друга, і не зовсім копія.
Розділяй і володарюй
Індустрія рекомендує 3-4 незалежних оточення (environment) для інформаційних систем. Крім вищезгаданого робітника, це оточення: розробки (development), тестування (test) і симуляції (staging).
Оскільки розгортання і обслуговування кожного оточення суть прямі витрати, то їх застосування визначається специфікою проекту. Чим вище вартість помилки в робочому оточенні, тим більше оточень включається в процес розробки. І навпаки. Останні два можуть бути замінені одним оточенням тестування, якщо процес не передбачає окремі приймальні (acceptance) тести або демонстрацію. Аналогічно, всі три можуть бути одним оточенням розробки, якщо процес не передбачає регресійне (regression) тестування або безперервну інтеграцію (continuous integration). У межі, всіх трьох може не існувати зовсім. Наприклад, для статичного сайту-візитки невідомої компанії, оновлюваного за ftp.
Крім ігор з функціоналом і усуненням помилок, наявність незалежних оточень дозволяє масштабувати команду проекту. Коли програміст програмує, а адміністратор адмініструє, це добре. Це називається розділом обов'язків (segregation of duties). Рекомендується замикати розробника на оточення розробки, а тестувальника на оточення тестування. Вважається, що такий організаційно-технічний підхід знижує операційні ризики (operational risk), тому сильно радує власників інформаційних систем.
Так що там з другою копією? Найпростіший і очевидний спосіб її отримати - скопіювати резервну. І з неї вже підняти будь-яке додаткове оточення де потрібно.
Нельзя просто так взять.
і скопіювати базу даних з робочого в оточення розробки або тестування.
Справа в тому, що в даний час ключовим ризиком інформаційних систем є витік непублічних даних. Наприклад, відповідно до дослідження Verizon's 2013 Data Breach Investigations Report, з 47 тисяч інцидентів, 69% витоків даних були виявлені третіми особами. Тобто, витік даних виявляється десь сторонніми людьми, в тому числі нашими з вами клієнтами. А більше половини випадків інсайду припадає на колишніх співробітників, які скористалися своїми забутими активними обліковими записами або бекдорами.
Отже, прямий доступ до робочого середовища повинен бути тільки у тих, хто безпосередньо з ним працює. Наприклад, у адміністратора бази даних. Але ніяк не у всіх програмістів компанії «тому що так простіше дебажити». Так, Угода про Нерозголошення (non-disclosure agreement, NDA) в контракті - цей хороший превентивний захід. Але лише організаційна, а тому недостатня. Організаційні заходи повинні бути підкріплені технічним контролем.
Дані стають дорожчими в обслуговуванні
До них пред'являється все більше вимог захисту. Від добровільної відповідності (наприклад, стандартам ISO27K) аж до сертифікації місцевим регулятором (в ЄС це Office of the Data Protection). Так, в кінцевому рахунку, все зводиться до мінімізації збитку компанії від витоку непублічних даних. Причому, захист даних про людей вже затьмарив собою захист комерційної таємниці. А використання хмарних сховищ невідомо де і обслуговування їх невідомо ким, тільки додає проблемі гостроти.
Стандартною практикою захисту даних поза робочим оточенням є їх анонімізація (sanitization). Дані, що підлягають захисту, групуються за типами. Наприклад, номер банківського рахунку, дата народження, прізвище, зашифрований пароль. Далі до них застосовується одна з технік анонімізації - повне або часткове маскування, очищення, перемішування, підміна, шифрування або хешування. Розглядати їх тут не будемо, це тема окремої статті. Як бонус, якщо ви одного разу будете писати анонімізацію рахунків, зверніть увагу на Sample Account Data. Там є як валідні, так і невалидні банківські дані по країнах.
Дані стають більше за обсягом
Ручний метод розгортання тестової бази являє собою:
- копіювання дампа робочої бази на тестовий сервер;
- відновлення бази даних з нього;
- виконання скрипту анонімізації.
Для передачі «чистої» бази даних далі, в оточення розробки або зовні, робиться її резервна копія.
Переваги такого підходу очевидні: висока швидкість на малих обсягах і узгодженість реляційних даних на виході. Але є і недоліки, які в повне зростання проявляються на обсягах від десятків гігабайт:
- використовується проміжний файл дампа, що передається по мережі;
- повна копія зазвичай надлишкова для цілей розробки або тестування;
- до анонімізації дані схильні витоку як з файлу дампа, так і з бази;
- скрипт анонімізації є окремим елементом, у разі помилки дані залишаються колишніми.
Рішення
У рамках підготовки до іспиту з Java була написана утиліта org.crystalcopy для MySQL, позбавлена цих недоліків і достоїнств.
Утиліта підтримує таблиці, записи, тригери, збережені процедури, індекси та зовнішні ключі. Підходить для:
- часткового копіювання бази даних в іншу базу або файл;
- повного копіювання бази даних в іншу базу або файл;
- копіювання тільки схеми бази даних в іншу базу або файл;
- анонімізації засобами SQL без передачі даних по мережі.
При частковому копіюванні реляційні зв'язки між полями зберігаються, проте узгодженість всіх записів не гарантується. Швидкість повного копіювання з однієї бази даних в іншу на моїй машині становить близько 2Гб на годину. Утиліта запускається з командного рядка, її можна вбудувати в білд безперервної інтеграції. Доступна в Інтернет за некомерційною ліцензією.
Статус - бета. Так що буду щасливий отримати ваші відгуки!
