При розробці сучасних веб-додатків складно недооцінити користь від використання систем контролю версій. Стосовно до файлів продукту, що розробляється, ми здатні відстежити будь-які етапи виробництва в будь-який момент, починаючи з першої ревізії. Інструменти, які допомагають нам у цьому, на сьогоднішній день популяризували, вважаються хорошим тоном при розробці, а в багатьох випадках успішне виробництво без їх застосування неможливо в принципі. А які можливості ми маємо, коли виникає необхідність простежити зміни не в файлах, а в базах даних проекту? Під катом я поділюся інформацією про існуючі засоби, за якими мені довелося ознайомитися.
1. PHP SQLDIFF, a.k.a. SQLDiff
PHP-скрипт, який дозволяє побачити повні відмінності (як в структурі, так і в даних) між будь-якими таблицями двох БД. В інструменті відсутні будь-які засоби по автоматичної синхронізації структури або даних - надається лише візуальна інформація. Ще з істотних недоліків - можливість підключення тільки до БД, до яких можливий доступ безпосередньо (не через ssh-тунель). Повільна швидкість роботи на великих обсягах даних (робота через pear-модуль, який не блищить ні новизною, ні швидкістю). Вважаю даний скрипт вельми корисним для розробника в випадках, коли необхідне розуміння і візуальне уявлення відмінностей між різними таблицями - має зручний інтерфейс, швидке налаштування. Охарактеризує швидше як корисну кишенькову утиліту для швидкого отримання розуміння про рассинхронизации таблиць, які в теорії повинні бути ідентичні, ніж як серйозний інструмент, який можна застосувати для автоматизації процесів синхронізації.
2. LIQUIBASE
Зручний багатофункціональний і простий у використанні мігратор структури БД на java. Бачу для себе в цьому плюс, якщо використовувати в зв'язці з Jenkins.
Приклад (host1 - сервер, з якого необхідно копіювати структуру БД; host2 - сервер, на який необхідно перенести структуру з host1):
Формує changeset в форматі xml, подальша міграція якого наводить структуру бд на host2 в стан, ідентичне host1.
Після міграції є сенс перевірити ще раз, що changeset порожній.
Відбувається не тільки синхронізація таблиць і полів, але також індексів, ключів. Не впевнений з приводу збережених процедур - це я не перевірив.
Changeset також можна формувати і в інших форматах - в sql, в json (не тільки в xml). Формування changeset'а в sql буде корисним в тих випадках, коли для міграції використовуються кошти інший утиліти.
3. schemasync
Інструмент для синхронізації структури БД. Для роботи необхідний python і відповідний інтерфейс для mysql.
З істотних відмінностей з liquibase:
- schemasync створює не тільки ченжсет, але і файл, що дозволяє відкинути редагування (найважливіше і найцінніше перевагу, хоча, на мій погляд, не рятує від необхідності робити backup перед синхронізацією)
- liquibase дозволяє не тільки отримати ченжсет, але і відразу ж запустити міграцію засобами самої утиліти. Може бути, не кілер-фича, але все одно зручно і корисно
4. MAATKIT data sync
Додаток 1:
Згадані інструменти мають істотний недолік, який менш важливий при Деплой на production-сервер, але постійно про себе нагадує в процесі розробки - швидкість виконання. Спочатку було завдання побудувати механізм, який дозволить автоматизувати сіхнронізацію між майданчиками в ланцюжку «розробники - тестові сервера - stage - production». Починаючи (у згаданій вище ланцюжку) з тестових серверів все досить просто - з ресурсів потрібно тільки час, навантаження мінімальне. Якщо процес виконується автоматично за розкладом ночами, то важливо не те, за скільки часу виповнилося, а то, щоб не створити навантаження і щоб до ранку завдання було повністю завершена. Якщо синхронізація регулярна, то списки змін ніколи не будуть надмірно великими, а навантаження буде незначною. Інша справа, коли мова йде про синхронізацію між майданчиком розробника і тестовим сервером. В такому випадку, синхронізація, що виконується 1 годину, завжди буде відчутною і буде створювати незручності. Ці обставини і наштовхнули на засіб синхронізації №5:
5. «Напівавтоматична синхронізація».
В описаних вище утиліти велику (трохи менше, ніж повністю) частину часу займає саме формування списку відмінностей. Застосувати ж потім скрипт щодо усунення відмінностей - дія досить швидке (знову ж таки, не аксіома, але в більшості випадків в процесі розробки). Це наштовхує на думки, що можна попрацювати над ручним формуванням для відстеження змін, а автоматизувати тільки його застосування. Очевидних способів знайшлося тільки два:
а) в будь-якому продукті існують методи для роботи з БД - не важливо, чи використовуєте ви популярний фреймворк або у вашого продукту саморобний ядро. Досить фіксувати всі необхідні запити (якщо тільки стуктура цікавить - DDL, якщо дані теж - update і delete, наприклад) в власне сховище;
б) якщо ваш фреймворк (а ще більше цим грішать cms) не має можливості розширити методи класу, що працює з БД і навіть не має обробника подій в методі, що виконує запит до БД, можна парсити лог всіх запитів (сподіваюся, можливість включити такий лог має весь цільової софт) і фіксувати тільки необхідні дії з цього журналу.
Така «напівавтоматична синхронізація» зі створенням власних логів змін має право на існування, але повинна спонукати розробника виконувати за допомогою згаданих вище утиліт перевірку після синхронізацій, що таблиці дійсно збігаються (нехай це виконується хоча б по ночах за розкладом, щоб бути впевненими, що людський фактор не вніс свої корективи в синхронність даних).
Додаток 2:
Вдалого застосування і не забувайте робити бекапи!