Процесс синхронизации данных между несколькими бд. Синхронизация БД SQL Server из различных источников. Генерация XML-файла со структурой БД
Друзья, всем привет! Рад всех вас видеть у себя в гостях 😉 Сегодня я расскажу, как синхронизировать базы данных 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. И теперь можно сравнить количество статей, записей и комментариев. Правда, комментариев на блоге стало немного больше, пока я писал статью.
Статистика по тестовому блогу:
Статистика по рабочему блогу:
Ну и напоследок напомню, что синхронизировать базу данных это ещё половина дела. К базе данных должны прилагаться и файлы, задействованные в работе сайта. К примеру, если не скопировать скриншоты, сопровождающие статью, то статья будет без них с пустыми местами.
А теперь советую посмотреть видеоурок, в котором весь процесс синхронизации баз данных я показываю шаг за шагом.
Сегодня на этом всё. Всем желаю хорошего настроения. До встречи в новых материалах. И конечно же, жду ваших комментариев 😉 А полученные знания пригодятся вам при .
Подписывайтесь на новые статьи!
Каждый, кто когда-либо разрабатывал приложения, использующие базу данных, наверняка сталкивался с проблемой обновления структуры БД при разворачивании и обновлении приложения.
Чаще всего используется простой подход - создание набора 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
При использовании ПК Интеллект в системах с распределенной архитектурой необходимо синхронизировать базы данных Серверов и УРМА. Синхронизация баз данных позволяет хранить данные как централизованно (на одном Сервере или УРМА), так и распределенно (репликация данных из баз различных Серверов и УРМА системы видеонаблюдения). Синхронизация баз данных обеспечивает параллельную работу с базами данных Серверов и УРМА и автоматическое обновление при их изменении.
По умолчанию базы данных ПК Интеллект на Серверах и УРМА не синхронизированы между собой. Как правило, ПК Интеллект настраивается таким образом, что синхронизация всех баз данных осуществляется только с одной централизованной базой данных, размещенной на Сервере администрирования.
Примечание.
В том случае, если одна или несколько баз данных хранятся в формате MS Access, необходимо перед настройкой синхронизации конвертировать базы в формат MS SQL server.
Для настройки синхронизации базы данных Конфигурация программного комплекса Интеллект с базой данных сервера администрирования (или другой базой данных), необходимо выполнить следующие действия:
- Проверить, работает ли ПО MS SQL Server.
- Запустить утилиту idb.exe, расположенную в корне директории установки ПК Интеллект (например, C:\Program Files (х86) \Интеллект). На экран будет выведено диалоговое окно утилиты idb.exe.
- Из списка Выберите источник данных: выбрать пункт Synchro source .
- Установить флажок Использовать.
- Нажать кнопку Настроить.
- На экран будет выведено диалоговое окно Свойства связи с данными
. В окне Свойства связи с данными
необходимо перейти на вкладку Поставщик данных
.
- Из списка Поставщики OLE DB необходимо выбрать пункт Microsoft OLE DB Provider for SQL Server .
- Нажать кнопку Далее.
- После нажатия кнопки Далее
будет выполнен автоматически переход на вкладку Подключение
.
- В строке 1. Выберите или введите имя сервера: данного окна необходимо выбрать из списка или ввести вручную наименование MS SQL сервера, на котором хранится база данных, с которой требуется синхронизировать текущую.
- В группе 2. Для входа в сервер использовать:
необходимо указать тип и указать параметры аутентификации для подключения к MS SQL серверу. Аутентификация на MS SQL сервере осуществляется по учетной записи пользователя, авторизированного в ОС Windows, или по имени пользователя (логину) и паролю, которыми защищено подключение к MS SQL серверу.
Метод и параметры, используемые для аутентификации на MS SQL сервере, задаются при установке MS SQL сервера.
В зависимости от метода аутентификации, который требуется использовать для подключения к MS SQL серверу, необходимо указать следующие параметры:- В том случае, если аутентификация на MS SQL сервере осуществляется по учетной записи пользователя в ОС Windows, необходимо установить переключатель в положение учетные сведения Windows NT . При этом необходимо, чтобы в ОС Windows на компьютере, на котором установлен MS SQL сервер и хранится база данных, с которой требуется настроить синхронизацию, была зарегистрирована учетная запись, под которой в текущий момент авторизирован пользователь в ОС Windows на компьютере, с которого выполняется настройка синхронизации.
- В том случае, если аутентификация на MS SQL сервере осуществляется по имени пользователя (логину) и паролю необходимо выполнить следующие действия:
- Установить переключатель в положение следующие имя и пароль пользователя: .
- В поле Пользователь: ввести имя пользователя (логин) для подключения к MS SQL серверу.
- В том случае, если доступ к MS SQL серверу защищен паролем, необходимо снять флажок Пустой пароль и в поле Пароль ввести пароль для доступа к базе данных.
- Нажать кнопку Проверить подключение .
- При успешном подключении к MS SQL серверу на экран будет выведено окно с сообщением Проверка подключения выполнена
.
Необходимо нажать кнопку ОК в окне сообщения, в результате чего окно автоматически будет закрыто. - В том случае, если наименование MS SQL сервера и/или параметры аутентификации, используемые для подключения к MS SQL серверу, были указаны неправильно, на экран будет выведено соответствующее сообщение.
Для закрытия окна с сообщением необходимо нажать кнопку ОК . Далее требуется изменить введенные данные и повторно проверить подключение к MS SQL серверу. - Из списка Выберите базу данных на сервере выбрать название базы данных, с которой требуется синхронизировать текущую.
- Нажать кнопку ОК в диалоговом окне Свойства связи с данными. В результате выполнения данного действия окно будет закрыто.
- Нажать кнопку ОК , расположенную в нижнем правом углу окна утилиты idb.exe.
На этом настройка синхронизации баз данных завершена.
Приложения, используемые торговыми представителями или другими работниками на местах – курьеры службы доставки, выездные медсёстры, сотрудники клининговых компаний и т.д., предназначены для сбора информации на местах с последующей отправкой её в центр обработки данных. Кроме того, периодически необходима обратная связь, т.е. отправка данных обратно от центра обработки к конкретным исполнителям на местах.
Например, каждый раз, когда медсестра осуществляет визит к пациенту, она делает отметку о визите на мобильном устройстве. По итогам рабочего дня, вся информация отправляется в централизованную базу данных больницы. После этого, они могут синхронизировать свои мобильные устройства с центром обработки данных, чтобы получить актуальную информацию о своих пациентах или узнать список новых посещений, который они должны осуществить на следующий день.
В любом подобном сценарии использования основная потребность – это постоянный обмен данными между мобильными устройствами на местах и общим хранилищем данных.
Как можно решить подобные задачи
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