Обзор средств синхронизации баз данных MySQL. Сравнение программ для синхронизации сетевых баз данных. Бесплатная программа для синхронизации
Синхронизация баз данных MySQL позволяет создать и автоматически поддерживать две или более базы данных с идентичным содержимым. Синхронизациия нужна для создания зеркал, кластеров и т.д. Программа Handy Backup позволяет полностью автоматизировать процесс синхронизации БД MySQL.
Методы синхронизации MySQL баз
В MySQL синхронизация двух баз может быть односторонней или двусторонней.
Односторонняя синхронизация
Содержимое одной базы (master) копируется в другую (slave). В MySQL синхронизация БД на разных серверах используется для репликации таблиц, создания тестовых и резервных баз, бэкапа MySQL и т.д.
Двусторонняя синхронизация
Двусторонняя синхронизация MySQL обеспечивает копирование актуальных изменений из каждой базы данных в другую. Эта техника применяется прежде всего для распределения вычислительных задач, связанных с базами данных – создания кластеров и зеркал БД.
Преимущества Handy Backup для синхронизации БД MySQL
Handy Backup содержит встроенный плагин MySQL, позволяющий копировать состояние баз данных и таблиц MySQL в "горячем" режиме (без остановки сервера), а также в "холодном" (с остановкой). При этом обеспечиваются следующие преимущества:
- Синхронизация данных MySQL (копирование и восстановление) по расписанию;
- Хранение таблиц MySQL в удобочитаемом текстовом формате из списка SQL команд;
- Автоматический останов сервера-приёмника MySQL при восстановлении данных;
- Версионное копирование и создание временных меток на копиях по необходимости;
- Получение доступа к внешним MySQL серверам.
Как выполнить синхронизацию MySQL с помощью Handy Backup?
Синхронизация баз данных MySQL состоит из создания резервной копии базы и последующего восстановления таблиц этой базы на другом сервере с помощью плагина "MySQL". Этот процесс включает в себя 2 последовательных задачи:
Резервное копирование данных исходной таблицы (в случае односторонней синхронизации) или обеих таблиц (при симметричной синхронизации).
Восстановление данных в синхронизируемую таблицу MySQL, полное или дифференциальное, в зависимости от типа синхронизации.
Детальное описание задач копирования и восстановления MySQL имеется в Руководстве Пользователя.
Автоматизация задач синхронизации таблиц MySQL
Чтобы сделать процесс синхронизации баз данных MySQL полностью автоматическим, обратите, пожалуйста, внимание на следующие пункты:
- Разделите время запуска задач резервного копирования MySQL и их восстановления на достаточно большой промежуток, чтобы запущенная задача резервного копирования базы данных успела завершиться перед началом восстановления.
- Выбирайте для промежуточных копий MySQL достаточно быстрые по скорости доступа носители: локальные и внешние диски, устройства NAS/SAN и серверы FTP/SFTP/FTPS с широкой пропускной способностью сетевого интерфейса.
- Пользуйтесь возможностями Шага 7 (установка запуска программ до и/или после выполнения задачи) для автоматического останова и перезапуска сервера MySQL на стороне восстановления, а также на стороне записи – для "холодной" загрузки данных.
- Поскольку резервные копии хранятся в доступном для чтения текстовом формате, пользуйтесь при необходимости инструментами для внесения исправлений в восстанавливаемые файлы – скажем, для смены механизма хранения данных.
Приобретение лицензии
Как было сказано выше, синхронизация баз данных (БД) MySQL не заменяет регулярного резервного копирования. Мы рекомендуем обеспечивать задачи резервного копирования БД MySQL с помощью одного из бизнес-ориентированных решений нашего программного обеспечения (ПО).
- Если вам нужно работать только с одним сервером СУБД MySQL, Handy Backup Office Expert обеспечит вас всеми необходимыми возможностями для этого и многими дополнительными функциями.
- Если вам необходимо обслуживать несколько серверов и рабочих станций, организуя процессы резервного копирования БД MySQL и любых других данных с общего рабочего места, используйте наше флагманское решение Handy Backup Server Network .
Чтобы сравнить цены на эти и другие продукты, пожалуйста, обратитесь к странице Купить .
Видеоурок
В следующем видеоуроке показано, как осуществлять резервное копирование и восстановление БД MySQL с помощью Windows-версии Handy Backup. В настоящий момент видео доступно только на английском языке.
Скачайте и установите наше программное обеспечение прямо сейчас – первая резервная копия ваших данных будет готова уже через пару минут!
Handy Backup предоставляет надёжный, быстрый и гибко настраиваемый инструмент для синхронизации MySQL на уровне таблиц и баз данных. Попробуйте прямо сейчас, скачав бесплатно полную версию программы на 30 дней!
Каждый, кто когда-либо разрабатывал приложения, использующие базу данных, наверняка сталкивался с проблемой обновления структуры БД при разворачивании и обновлении приложения.
Чаще всего используется простой подход - создание набора SQL-скриптов для модификации структуры БД от версии к версии. Конечно, есть такой мощный инструмент, как Red gate , но он во-первых небесплатный, во-вторых не решает проблему полной автоматизации обновления.
Технология migrations, впервые появившаяся в ОРМ Hibernate и реализованная в Linq, очень хороша и удобна, но подразумевает стратегию разработки структуры БД code first, что весьма трудоемко для уже существующих проектов, а использование в БД триггеров, хранимых процедур и функций делает задачу перехода на code first практически невыполнимой.
В данной статье предлагается альтернативный подход к решению этой задачи, использующий хранение эталонной структуры БД в XML-файле и автоматическую генерацию SQL-скрипта на основе сравнения эталонной и существующей структуры. Итак, начнем...
Генерация XML-файла со структурой БД
Для экспериментов будем использовать БД DbSyncSample. Скрипт для создания БД приведен ниже.
USE GO /****** Object: Table . Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE .( IDENTITY(1,1) NOT NULL, (50) NULL, NULL, (18, 2) NOT NULL, CONSTRAINT PRIMARY KEY CLUSTERED ( ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ) ON GO CREATE NONCLUSTERED INDEX ON . ( ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON GO /****** Object: Table . Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE .( IDENTITY(1,1) NOT NULL, (150) NULL, NULL, (18, 2) NOT NULL, CONSTRAINT PRIMARY KEY CLUSTERED ( ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ) ON GO /****** Object: Trigger Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TRIGGER . ON . AFTER INSERT,UPDATE AS BEGIN UPDATE Orders SET TotalCost = s.Total FROM (SELECT i.OrderId OId, SUM(d.Cost) Total FROM Details d JOIN inserted i ON d.OrderId=i.OrderId GROUP BY i.OrderId) s WHERE Id=s.OId END GO /****** Object: Trigger Script Date: 06/01/2017 10:37:43 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TRIGGER . ON . AFTER DELETE AS BEGIN UPDATE Orders SET TotalCost = s.Total FROM (SELECT i.OrderId OId, SUM(d.Cost) Total FROM Details d JOIN deleted i ON d.OrderId=i.OrderId GROUP BY i.OrderId) s WHERE Id=s.OId END GO /****** Object: Default Script Date: 06/01/2017 10:37:43 ******/ ALTER TABLE . ADD CONSTRAINT DEFAULT ((0)) FOR GO /****** Object: Default Script Date: 06/01/2017 10:37:43 ******/ ALTER TABLE . ADD CONSTRAINT DEFAULT ((0)) FOR GO /****** Object: ForeignKey Script Date: 06/01/2017 10:37:43 ******/ ALTER TABLE . WITH CHECK ADD CONSTRAINT FOREIGN KEY() REFERENCES . () GO ALTER TABLE . CHECK CONSTRAINT GO
Для экспериментов создаем консольное приложение. Подключаем к нему nuget-пакет Shed.DbSync .
Структуру БД в виде XML получаем следующим образом:
class Program { private const string OrigConnString = "data source=.;initial catalog=FiocoKb;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"; static void Main(string args) { // получаем XML со структурой БД var db = new Shed.DbSync.DataBase(OrigConnString); var xml = db.GetXml(); File.WriteAllText("DbStructure.xml", xml); } }
После запуска программы в файле DbStructure.xml видим следующее:
Разворачивание/обновление структуры БД при помощи полученного XML.
Теперь научимся использовать полученный XML. Создаем еще одну пустую БД DbSyncSampleCopy, в код нашей консольной программы добавляем следующее:
class Program { private const string OrigConnString = "data source=.;initial catalog=DbSyncSample;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"; private const string TargetConnString = "data source=.;initial catalog=DbSyncSampleCopy;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"; static void Main(string args) { // получаем XML со структурой эталонной БД var dborig = new Shed.DbSync.DataBase(OrigConnString); var xml = dborig.GetXml(); File.WriteAllText("DbStructure.xml", xml); // если нужно предварительно очистить структуру целевой БД, используем // Shed.DbSync.DataBase.ClearDb(TargetConnString); // обновляем структуру целевой БД var dbcopy = Shed.DbSync.DataBase.CreateFromXml(xml); dbcopy.UpdateDb(TargetConnString); // на самом деле можно обойтись одной строкой: // dborig.UpdateDb(TargetConnString); // dbcopy создаем только для демонстрации создания объекта базы из XML } }
После запуска программы можно убедиться, что в DbSyncSampleCopy появилась структура таблиц, идентичная эталонной БД. Эксперименты с изменением эталонной структуры и обновлением целевой оставляю читателю.
В сценариях тестирования может понадобиться создание тестовой БД каждый раз с нуля. В этом случае будет полезно использовать функцию Shed.DbSync.DataBase.ClearDb(string connString)
Автоматическое слежение за структурой БД.
Слежение за структурой оформим в виде отдельной функции, которую следует вызывать при старте/рестарте приложения либо в другом месте по желанию разработчика.
static void SyncDb() { // автоматическое слежение за структурой БД Shed.DbSync.DataBase.Syncronize(OrigConnString, @"Struct\DbStructure.xml", // путь к файлу структуры @"Struct\Logs", // путь к папке логов синхронизации @"Struct\update_script.sql" // (необяз.) в случае определения этого параметра // в него будет записан скрипт, сгенерированный // для обновления БД); }
Слежение производится при помощи параметра (тега) Version в XML. Сценарий использования процедуры такой:
- Назначить версию БД. В Microsoft SqlServer Management Studio на узле нужной базы данных правой кнопкой выбрать Properties.
- Далее Extended Properties и в таблице свойств добавить свойство Version со значением 1. При каждой последующей модификации структуры это свойство следует наращивать на 1.
- При запуске приложения, если XML-файла нет или его версия меньше, чем у БД, он создается.
- Если версия XML-файла больше, чем у БД, генерируется скрипт на обновление БД и исполняется.
- Если в процессе исполнения скрипта возникли ошибки, все изменения откатываются.
- Результаты синхронизации пишутся в log-файл, создаваемый в папке, указанной параметром logDitPath.
- Если указан параметр SqlScriptPath, создается файл со скриптом из п.4.
Эксперименты оставляю читателям. Успехов вам!
Теги:
- ms sql
- синхронизация баз данных
- database
- syncronize
- dbsync
- sql
- shed
- shed.dbsync
Друзья, всем привет! Рад всех вас видеть у себя в гостях 😉 Сегодня я расскажу, как синхронизировать базы данных WordPress. А так же о том, какие таблицы в базе наиболее важные и как с ними работать.
Эту тему я освещаю не просто так. Как вы помните, я рассказывал о том, как . Очень удобная возможность при разработке сайтов.
Так вот, после доработки сайта, его нужно вернуть на хостинг. И с этим, вообще, нет никаких проблем. В том случае, если во время вашей работы на локальном сервере, сайт, расположенный, в интернете не обновлялся. Но такие случаи бывают крайне редко.
А вот если вы регулярно обновляли сайт и при этом работали, как я, над его дизайном у себя на компьютере, то возникает определенная трудность. В вашей локальной базе будет новый дизайн, но не будет новых статей и комментариев.
И вот тут-то и нужна синхронизация базы данных. Именно так можно объединить в базе данных и новый дизайн, и новые записи. А уже после, без проблем, перенести готовый сайт обратно на хостинг.
И это лишь один пример, но вы уже и сами поняли, что умелое обращение с базой данных открывает перед вами новые возможности в работе над сайтом.
Структура базы данных WordPress
Прежде чем приступить к синхронизации нужно разобраться, что синхронизировать. База данных Вордпресс состоит из множества таблиц, в которых хранятся данные о пользователях, статьях, категориях, тегах, плагинах, комментариях, системных настройках и многое другое.
По большому счёту досконально разбираться во всех таблицах необязательно. Достаточно знать, в каких таблицах находится информация о статьях, комментариях и так далее. Именно эти таблицы имеют ключевое значение при синхронизации.
Итак, рассмотрим ключевые таблицы в базе данных WordPress.
wp_options – содержит все настройки сайта;
wp_posts – все статьи и записи на сайте;
wp_postmeta – вспомогательные данные о статьях и записях на сайте;
wp_comments – комментарии;
wp_commentmeta – вспомогательная информация о комментариях;
wp_term_relationships – связи статей и записей с категориями и тегами;
wp_terms – связи категорий (рубрик) со ссылками;
wp_term_taxonomy – связи категорий, тегов, ссылок;
wp_usermeta – информация обо всех зарегистрированных пользователях;
wp_users – информация об администраторе.
Многие другие таблицы в базе данных создаются всевозможными плагинами, виджетами, и прочими такими инструментами. В основном в этих таблицах собрана системная информация, её можно использовать с пользой. Так, посмотрев внимательно эти таблицы, вы можете узнать по какому ключевому запросу пришёл посетитель, на какую страницу, был ли это первый визит или повторный, и даже с какого браузера и операционной системы.
Вот теперь, когда общее представление о базе данных WordPress у вас сложилось, можно приступать к цели нашего урока – синхронизации баз данных.
Подготовка к процессу синхронизации
Прежде чем приступить к работе с базой данных, — обязательно сделайте резервную копию. Так как если вы сделаете, что-то не так. То сможете всё восстановить из копии.
Так, вы и процесс поймёте, и сможете создать нужную базу данных на своём компьютере и перенести на хостинг уже готовую БД.
Самое главное не забудьте про резервную копию.
Сравнение баз данных в phpMyAdmin
Этот шаг необязательный, но лучше, если вы будете знать, как, подручными средствами, сравнить базы данных. Меня эти знания частенько выручают.
Использовать для этого будем утилиту phpMyAdmin, которая доступна и на хостинге и на локальном сервере.
В качестве сравнения будем использовать базу данных на локальном сервере, которую я использовал в работе над . И базу данных, которая используется у меня на моём блоге.
Для сравнения возьмём одну цифру – количество статей. Так как для таких сайтов, как мой, – это самое ценное. Ну и комментарии, конечно. К тому же эти цифры всегда у вас на виду.
Анализируем тестовый сайт и базу данных:
Для начала посмотрим на количество статей. Сделать это можно в административной панели Вордпресс. Достаточно открыть консоль.
Как видно, на скриншоте, статей на тестовом сайте – 136.
После обновления темы оформления, я успел написать ещё пару статей. И сейчас их уже 138.
Количество статей должно соответствовать количеству записей в таблице wp_posts . Но, если открыть эту таблицу, то записей вы увидите гораздо больше.
Как видите на скриншоте – всего записей 2,245. И среди них и статьи и отдельные записи. А ещё это куча черновиков и прочих записей о картинках и так далее.
Поэтому сразу определить количество статей нереально. Для этого потребуется сделать небольшой запрос с параметрами сортировки.
Открываете базу данных – таблицу wp_posts – переходите на закладку SQL – вводите запрос:
SELECT * FROM `wp_posts` WHERE `post_status` = "publish" AND `post_type` = "post"
Этот запрос говорить о том, что в таблице wp_posts нужно выбрать все записи (* ), где статус – опубликовано (publish ) и это статья (post ).
В итоге получаем 136 записей. Вот теперь эта цифра соответствует количеству статей.
Точно так же сверяется и другая база данных. В моём случае – реальная база с моего блога.
Эти знания помогут вам не потерять ничего важного. И проверить после синхронизации, всё ли прошло успешно.
В качестве досадного примера расскажу небольшую историю. Один мой знакомый, однажды переезжал с одного хостинга на другой. Делал всё по инструкции, техподдержка ему помогла. Но, через какое-то время он заметил, что на его сайте не хватает двух статей. Когда он попросил меня разобраться, в чём может быть проблема, я провёл сверку, и выяснилось, что в новой базе нет двух записей, которые есть в старой базе данных. Скорей всего, когда он переносил базу данных, то что-то сделал не так и потерял эти две статьи. В результате пришлось немного поколдовать и вернуть эти две статьи на их законное место.
Вот почему важно знать, как провести сверку. И убедиться, что после синхронизации, все ваши записи успешно перенесены из одной базы в другую.
Синхронизация баз данных WordPress
Все действия будем делать на локальном сервере. А после готовую базу данных можно импортировать на хостинг.
Шаг 1. Создание двух пустых баз данных
Если возникает вопрос почему две базы, то объясняю, — это нужно для того, чтобы не трогать рабочие базы данных и показать пример с чистого листа.
Первым делом запускаете Денвер и в браузере набираете localhost/tools/ , а далее жмёте на ссылке phpmyadmin .
Шаг 2. Импортируем данные в базу
Итак, я сделал резервные копии баз данных. Одну с тестового сайта, другую с моего блога в интернете. Они понадобятся для импорта содержимого во вновь созданные базы. А далее будут страховкой.
У вас должно быть тоже две базы, которые вы будете синхронизировать.
Теперь нужно импортировать данные из резервных копий в новые базы данных. Для этого выбираете новую базу – откройте закладку «Импорт» — выбираете «файл резервной копии» — нажимаете кнопку «Ок» .
Шаг 3. Синхронизация баз данных
Вообще, есть возможность просто копировать нужные таблицы из одной базы в другую. Но мы рассмотрим непосредственно процесс синхронизации. Как полной так и частичной (в виде отдельных таблиц).
Для этого нужно перейти на главную страницу phpMyAdmin и выбрать раздел «Синхронизировать» .
Теперь в качестве источника определяем базу данных с блога в интернете (она более свежая), а в качестве целевой базы – базу с тестового сайта. Наша задача скопировать новые статьи, комментарии и теги в базу данных тестового сайта.
После того как пройдёт сравнение. На выбор будет предложено синхронизировать отдельные таблицы, в которых есть изменения, или провести полную синхронизацию.
Если вы хотите синхронизировать отдельные таблицы, то необходимо нажать на буквы S или D . Эти буковки станут серыми, а в окошке ниже вы увидите добавленные таблицы на синхронизацию. После чего вы можете синхронизировать эти таблицы, нажав на кнопку «Применить выбранные изменения» .
В нашем случае подходит именно этот способ, так как нам нужно синхронизировать только статьи, комментарии и метаданные.
Для синхронизации баз данных полностью, ничего отмечать не нужно. Достаточно нажать на кнопку «Синхронизировать базы данных» .
Вот, и всё. На этом процесс синхронизации окончен. Можно проверять результат. Для наглядного примера, я сменил базу данных на локальном сайте. Если кто забыл, делается это в файле wp-config.php. И теперь можно сравнить количество статей, записей и комментариев. Правда, комментариев на блоге стало немного больше, пока я писал статью.
Статистика по тестовому блогу:
Статистика по рабочему блогу:
Ну и напоследок напомню, что синхронизировать базу данных это ещё половина дела. К базе данных должны прилагаться и файлы, задействованные в работе сайта. К примеру, если не скопировать скриншоты, сопровождающие статью, то статья будет без них с пустыми местами.
А теперь советую посмотреть видеоурок, в котором весь процесс синхронизации баз данных я показываю шаг за шагом.
Сегодня на этом всё. Всем желаю хорошего настроения. До встречи в новых материалах. И конечно же, жду ваших комментариев 😉 А полученные знания пригодятся вам при .
Подписывайтесь на новые статьи!
Приложения, используемые торговыми представителями или другими работниками на местах – курьеры службы доставки, выездные медсёстры, сотрудники клининговых компаний и т.д., предназначены для сбора информации на местах с последующей отправкой её в центр обработки данных. Кроме того, периодически необходима обратная связь, т.е. отправка данных обратно от центра обработки к конкретным исполнителям на местах.
Например, каждый раз, когда медсестра осуществляет визит к пациенту, она делает отметку о визите на мобильном устройстве. По итогам рабочего дня, вся информация отправляется в централизованную базу данных больницы. После этого, они могут синхронизировать свои мобильные устройства с центром обработки данных, чтобы получить актуальную информацию о своих пациентах или узнать список новых посещений, который они должны осуществить на следующий день.
В любом подобном сценарии использования основная потребность – это постоянный обмен данными между мобильными устройствами на местах и общим хранилищем данных.
Как можно решить подобные задачи
1. Репликация SQL Server. С помощью репликации вы можете осуществлять синхронизацию удалённых баз данных между собой путём копирования данных. Но у неё (репликации SQL Server) есть ряд ограничений:
- Только более дорогие редакции SQL Server Standard и Enterprise могут выступать в роли издателя (Publisher), поэтому если вы используете бесплатную редакцию SQL Express, то вам придётся обновиться.
- Конфигурация из издателя (Publisher) SQL Server 2005 и подписчика (Subscriber) SQL Server 2008 не поддерживает web-репликацию.
- Версия распространителя (Distributor) должна быть строго равна или выше версии издателя (Publisher).
- В репликации транзакций (Transactional Replication) версия подписчика (Subscriber) не должна отличаться от издателя (Publisher) больше, чем на две версии SQL Server, т.е. издатель SQL Server 2000 не может работать с подписчиком SQL Server 2012.
- В репликации слиянием (Merge Replication) версия подписчика (Subscriber) должна быть меньше или равна версии издателя (Publisher), т.е. подписчик SQL Server 2012 не сможет работать с издателем SQL Server 2008.
2. Sync Framework
– API, которое позволяет создавать приложения для синхронизации данных между разными базами данных. Эта платформа более гибкая для решения подобных задач, но требует дополнительной разработки, что повышает стоимость и сроки реализации.
3. ApexSQL Data Diff – инструмент SQL Server для поиска различий в данных и синхронизации их между собой. Этот инструмент позволяет находить различия не только между базами данных, но и анализировать резервные копии БД, как обычные, так и сжатые. В результате анализа можно получить подробный отчёт о найденных расхождениях и файл синхронизации, который можно выполнить.
Как это сделать
Представьте себе, что у вас есть единое хранилище данных больницы (Central) и базы данных посещения (Visits) на мобильном устройстве медсестры. В больнице создаются записи в таблице посещения (Visits) и каждое утро медсёстры синхронизируют свои устройства, чтобы узнать свой маршрут на предстоящий день. В течении дня медсёстры на мобильных устройствах желают пометки о посещениях в таблице VisitReports.
Для обратной синхронизации всех изменений, которые совершили медсёстры в течении дня необходимо выполнить похожие действия:
Теперь рассмотрим, как автоматизировать процесс синхронизации, при наличии проектов синхронизации.
Для вечерней синхронизации повторите шаги с 3 по 9, чтобы создать ещё одно задание.
С помощью приложения ApexSQL Data Diff вы можете легко настроить синхронизацию ваших удалённых БД SQL Server с центральным хранилищем. При этом вы не привязаны к какой-то конкретной версии или редакции SQL Server, от вас не потребуется дополнительного времени на разработку, при этом вы осуществляете полный контроль над всеми вашими данными до единой записи.
При разработке современных веб-приложений сложно недооценить пользу от использования систем контроля версий. Применительно к файлам разрабатываемого продукта, мы способны отследить любые этапы производства в любой момент, начиная с первой ревизии. Инструменты, помогающие нам в этом, на сегодняшний день популяризированы, считаются хорошим тоном при разработке, а во многих случаях успешное производство без их применения невозможно в принципе. А какие возможности мы имеем, когда возникает необходимость проследить изменения не в файлах, а в базах данных проекта? Под катом я поделюсь информацией о существующих средствах, с которыми мне пришлось ознакомиться.
1. PHP SQLDIFF, a.k.a. SQLDiff
PHP-скрипт, позволяющий увидеть полные различия (как в структуре, так и в данных) между любыми таблицами двух БД. В инструменте отсутствуют какие-либо средства по автоматической синхронизации структуры или данных – предоставляется лишь визуальная информация. Еще из существенных недостатков – возможность подключения только к БД, к которым возможен доступ напрямую (не через ssh-тоннель). Медленная скорость работы на больших объемах данных (работа через pear-модуль, который не блещет ни новизной, ни скоростью). Считаю данный скрипт весьма полезным для разработчика в случаях, когда необходимо понимание и визуальное представление различий между разными таблицами - имеет удобный интерфейс, быстрая настройка. Охарактеризую скорее как полезную карманную утилиту для быстрого получения понимания о рассинхронизации таблиц, которые в теории должны быть идентичны, нежели как серьезный инструмент, который можно применить для автоматизации процессов синхронизации.
2. LIQUIBASE
Удобный многофункциональный и простой в использовании мигратор структуры БД на java. Вижу для себя в этом плюс, если использовать в связке с Jenkins.
Пример (host1 - сервер, с которого необходимо копировать структуру БД; host2 - сервер, на который необходимо перенести структуру с host1):
Java -jar liquibase.jar --driver=com.mysql.jdbc.Driver --classpath=mysql-connector-java-5.1.xx-bin.jar --logFile=db.ExampleChangelog.xml --url="jdbc:mysql://host2" --defaultSchemaName=db_name --username=username --password="password" --referenceUrl=jdbc:mysql://host1 --referenceUsername=username --referencePassword="password" diffChangeLog > ChangeSet.xml
Формирует changeset в формате xml, дальнейшая миграция которого приводит структуру бд на host2 в состояние, идентичное host1.
Запуск миграции:
Java -jar liquibase.jar --driver=com.mysql.jdbc.Driver --classpath=/path/to/classes --changeLogFile=ChangeSet.xml --url="jdbc:mysql://host2" --username=user --password="password" migrate
После миграции есть смысл проверить еще раз, что changeset пустой.
Происходит не только синхронизация таблиц и полей, но также индексов, ключей. Не уверен по поводу хранимых процедур – это я не проверил.
Changeset также можно формировать и в других форматах - в sql, в json (не только в xml). Формирование changeset"а в sql будет полезным в тех случаях, когда для миграции используются средства другой утилиты.
3. schemasync
Инструмент для синхронизации структуры БД. Для работы необходим python и соответствующий интерфейс для mysql.
Из существенных различий с liquibase:
- schemasync создает не только ченжсет, но и файл, позволяющий откатить изменения (самое важное и самое ценное преимущество, хотя, на мой взгляд, не избавляет от необходимости делать backup перед синхронизацией)
- liquibase позволяет не только получить ченжсет, но и сразу же запустить миграцию средствами самой утилиты. Может быть, не киллер-фича, но все равно удобно и полезно
schemasync работает только с sql – никаких промежуточных xml и аналогов – вижу для себя в этом как преимущества, так и недостатки.
Очень лаконичный синтаксис, минимум настроек. Позволяет не синхронизировать комментарии и автоинкремент (настраивается) - безусловный плюс.
Пример использования:
Schemasync mysql://user:pass@dev-host:3306/dev_db mysql://user:pass@prod-host:3306/production_db