Синхронизация баз данных: Сравнение компараторов для синхронизации схем и данных баз данных MS SQL Server / Хабр

Сравнение компараторов для синхронизации схем и данных баз данных MS SQL Server / Хабр

Синхронизация схем баз данных

После открытия студии, перейдите на вкладку «Database Sync» и создайте новое подключение, нажав по кнопке «New Connection»:

В открывшемся окне настроек подключения необходимо ввести необходимые данные для подключения к экземпляру MS SQL Server (серверу-источнику). Обратите внимание, что помимо аутентификации MS SQL Server, Windows, Active Directory, появилась возможность аутентификации через MFA. После заполнения всех необходимых полей, нажмите на кнопку «Test Connection» для проверки соединения:

После установки соединения будет выведено следующее диалоговое окно:

Далее нажмите на кнопку «ОК» в диалоговом окне и на такую же кнопку в окне настроек подключения.

Теперь появилось новое подключение:

Аналогичным образом необходимо подключить все нужные экземпляры MS SQL Server (в данном примере нужно создать подключение для сервера-приемника).

После этого необходимо нажать на «New Schema Comparison» для настройки процесса сравнения схем базы данных на сервере-источнике и базы данных на сервере-приемнике:

Появится окно настроек для сравнения схем.

На вкладке «Source and Target» слева в панели Source необходимо выбрать:

1. тип
2. подключение
3. базу данных источника

Справа в панели Target необходимо выбрать:

1. тип
2. подключение
3. базу данных приемника

Обратите внимание, что в типе можно выбрать не только базу данных, но также каталог скриптов, снимок, контроль версий и резервную копию. В нашем случае выбираем в типе «база данных».

После выбора всех настроек необходимо нажать на кнопку «Next» для продолжения настройки синхронизации схем баз данных.

Если сравниваются две изначально одинаковые базы данных, то можно сразу приступать к сравнению схем, нажав на кнопку «Compare».

При необходимости можно перейти к любой вкладке настроек, кликнув на соответствующий элемент слева окна.

На любом этапе можно сохранить настройки в виде bat-файла, нажав на кнопку «Save Command Line» слева внизу окна.

В большинстве случаев при накатывании изменений между изначально одинаковыми базами данных, достаточно сразу нажать на кнопку «Compare». Но для исследования функционала необходимо нажать «Next»:

Во вкладке «Options» можно выставить различные настройки или оставить их по умолчанию:

Во вкладке «Schema Mapping» можно настроить сопоставление схем по имени:

Во вкладке «Table Mapping» можно настроить сопоставление таблиц и столбцов:

Во вкладке «Object Filter» можно задать объекты для сравнения.

После этого, при необходимости можно вернуться к предыдущим шагам.

В конце необходимо нажать на кнопку «Compare» для запуска процесса сравнения схем заданных баз данных:

Окно настроек сравнения схем баз данных исчезнет, и появится окно с индикатором процесса выполнения сравнения:

В конце процесса обратите внимание на окно. Можно изменить настройки сравнения, нажав на кнопку «Edit Comparison» в левом верхнем углу окна. Справа от этой кнопки располагается круг со стрелкой — это кнопка обновления, которая запускает вновь процесс сравнения схем. Также чуть ниже располагаются все зарегистрированные ранее сервера:

Через главное меню в File можно сохранить настройки сравнения схем в виде файла с расширением scomp.

Теперь обратим внимание на центральную часть окна. Здесь галочками нужно выбрать необходимые объекты для синхронизации. Слева располагаются объекты источника, а справа-приемника. Внизу аналогичным образом располагается код определения объектов. Объекты для сравнения разделены на 4 секции с подсчетом количества этих объектов в каждой секции.

Здесь выбрана для просмотра кода определения таблица, которая есть и в источнике, и в приемнике. Поэтому данный объект находится в секции «Different»:

При выборе данного объекта, его код определения слева будет перенесен вправо при синхронизации схем баз данных для приемника.

Здесь для просмотра кода определения выбрано представление, которое есть только в источнике. Поэтому данный объект находится в секции «Only in source» и справа для него нет кода определения:

При выборе такого объекта, его код создания будет сгенерирован для приемника.

Здесь для просмотра кода определения выбрано представление, которое есть только в приемнике. Поэтому данный объект находится в секции «Only in target» и слева для него нет кода определения:

При выборе такого объекта, его код удаления будет сгенерирован для приемника.

Далее, для запуска самого процесса синхронизации схем баз данных необходимо нажать на одну из кнопок, выделенных красным на картинке:

Во вкладке «Output» необходимо указать, как будет происходить процесс синхронизации. Обычно выбирается генерация скрипта в студию или в файл. В нашем случае выберем первый вариант. Рекомендуется внимательно проходить последовательность всех вкладок по настройке процесса синхронизации:

Во вкладке «Options» можно задать различные настройки для синхронизации схем баз данных.

Обычно убираются все настройки из группы «Database backup».

По умолчанию в группе настроек «Transactions» выставлено «Use a single transaction» и «Set transaction isolation level to SERIALIZABLE», что предотвращает ситуации, в которых могут быть применены только части изменений – т.е. изменения будут применяться полностью либо не применяться вовсе:

Во вкладке «Summary» отображаются итоги выбора настроек синхронизации. При необходимости можно вернуться к предыдущим пунктам.

Обратите внимание, что настройки по синхронизации схем баз данных также можно сохранить в bat-файл, нажав на кнопку «Save Command Line» слева внизу окна.

В конце необходимо нажать на кнопку «Synchronize» для начала процесса генерации скрипта синхронизации схем баз данных:

По завершению, будет сгенерирован скрипт в новое окно:

Данный скрипт и есть код для переноса изменений схемы базы данных с источника на приемник. Его можно применить на сервере-приемнике или сохранить в файл для последующего применения на сервере-приемнике. Как правило, в любом случае данный скрипт сохраняют, чтобы после всех проверок применить его сразу на нескольких серверах для одной и той же базы данных. Сделать это можно с помощью групп зарегистрированных серверов в SSMS, отправив получившийся скрипт сразу на всю нужную группу серверов:

После синхронизации, выбранные ранее объекты, должны исчезнуть из окна сравнения схем:

Синхронизация данных баз данных

Предполагается, что были созданы нужные подключения как описывалось выше в «Синхронизация схем баз данных».

После этого необходимо нажать «New Data Comparison» для настройки процесса сравнения данных базы данных на сервере — источнике и базы данных на сервере — приемнике:

Появится окно настроек для сравнения данных.

На вкладке «Source and Target» слева в панели Source необходимо выбрать:

1. тип
2. подключение
3. базу данных источника

Справа в панели Target необходимо выбрать:

1. тип
2. подключение
3. базу данных приемника

Обратите внимание, что в типе можно выбрать не только базу данных, но также каталог скриптов и резервную копию. В нашем случае выбираем в типе «база данных».

После выбора всех настроек необходимо нажать «Next» для продолжения настройки синхронизации данных баз данных.

В отличие от сравнения схем, при сравнении данных рекомендуется пройти все шаги настроек последовательно.

При необходимости можно перейти к любой вкладке настроек, кликнув на соответствующий элемент окна слева.

На любом этапе можно сохранить настройки в виде bat — файла, нажав «Save Command Line» слева внизу окна.

После настройки вкладки “Source and Target” необходимо нажать «Next»:

Во вкладке «Options» можно выставить различные настройки или оставить их по умолчанию:

Во вкладке «Mapping» дается список таблиц для синхронизации данных. Восклицательными знаками отмечены те таблицы, в которых нет первичного ключа. Для таких таблиц сопоставление нужно делать вручную. Для этого выберите нужную строку (таблицу) и справа нажмите на многоточие:

Появится окно сопоставления:

После этого при необходимости можно вернуться к предыдущим шагам.

В конце необходимо нажать «Compare» для запуска процесса сравнения данных заданных баз данных:

Окно настроек сравнения данных баз данных исчезнет и появится окно с индикатором процесса выполнения сравнения:

В конце процесса обратите внимание на окно. Можно изменить настройки сравнения, нажав «Edit Comparison» в левом верхнем углу окна. Справа от этой кнопки располагается круг со стрелкой — это кнопка обновления, которая запускает процесс сравнения данных вновь. Также чуть ниже располагаются все зарегистрированные ранее сервера:

Через главное меню в File можно сохранить настройки сравнения схем в виде файла с расширением dcomp.

Теперь обратим внимание на центральную часть окна. Здесь галочками нужно выбрать необходимые объекты для синхронизации. Слева располагаются объекты источника, а справа — приемника:

Внизу отображается следующая информация:

1. для вставляемых строк — данные вставляемых строк:
2. для изменяемых строк — сравнение строк:
3. для удаляемых строк — данные удаляемых строк:

Внизу слева при необходимости можно выбрать не все строки для изменений, а нужные. По умолчанию выбираются все строки:

Также можно переходить между добавляемыми, изменяемыми и удаляемыми строками с помощью вкладок над самой таблицей данных:

Для управления видимостью нужных столбцов (полей) есть необходимый функционал:

По умолчанию выбраны все столбцы.

Далее для запуска самого процесса синхронизации данных баз данных необходимо нажать на одну из кнопок, выделенных красным на картинке:

Во вкладке «Output» необходимо указать, как будет происходить процесс синхронизации. Обычно выбирается генерация скрипта в студию или в файл. В нашем случае выберем первый вариант. Рекомендуется внимательно проходить последовательность всех вкладок по настройке процесса синхронизации:

Во вкладке «Options» можно задать различные настройки для синхронизации.

Обычно убираются все настройки из группы «Database backup».

По умолчанию в группе настроек «Transactions» выставлено «Use a single transaction» и «Set transaction isolation level to SERIALIZABLE», что предотвращает ситуации, в которых могут быть применены только части изменений – т.е. изменения будут применяться полностью либо не применяться вовсе:

Во вкладке «Summary» отображаются итоги выбора настроек синхронизации. При необходимости можно вернуться к предыдущим пунктам.

Обратите внимание, что настройки по синхронизации схем баз данных также можно сохранить в bat — файл, нажав «Save Command Line» слева внизу окна.

В конце необходимо нажать «Synchronize» для начала процесса генерации скрипта синхронизации:

По завершении будет сгенерирован скрипт в новое окно:

Данный скрипт и есть код для переноса изменений данных с источника на приемник. Его можно применить на сервере — приемнике или сохранить в файл для последующего применения на сервере — приемнике.

После синхронизации выбранные ранее объекты должны исчезнуть из окна сравнения данных.

Краткий обзор инструмента dbForge Compare Bundle for SQL Server

Помимо самой dbForge Studio for SQL Server для сравнения данных и схем баз данных можно использовать инструмент dbForge Compare Bungle for SQL Server от компании Devart, который встраивается в SQL Server Management Studio (SSMS). Рассмотрим пример использования данного инструмента в SSMS:

Здесь нужно нажать правой кнопкой мыши на нужную базу данных и выбрать необходимое действие: сравнение данных или сравнение схемы. После этого установить выбранную базу данных как источник или как приемник. Аналогичным образом выбрать вторую базу данных как приемник или как источник.

После установки источника и приемника для начала настройки синхронизации данных или схемы баз данных необходимо нажать на зеленую стрелку посередине экрана:

После этого появится привычное окно настроек синхронизации данных или схем баз данных в зависимости от того, что было выбрано ранее.

Обзор средств синхронизации баз данных MySQL / Хабр

При разработке современных веб-приложений сложно недооценить пользу от использования систем контроля версий. Применительно к файлам разрабатываемого продукта, мы способны отследить любые этапы производства в любой момент, начиная с первой ревизии. Инструменты, помогающие нам в этом, на сегодняшний день популяризированы, считаются хорошим тоном при разработке, а во многих случаях успешное производство без их применения невозможно в принципе. А какие возможности мы имеем, когда возникает необходимость проследить изменения не в файлах, а в базах данных проекта? Под катом я поделюсь информацией о существующих средствах, с которыми мне пришлось ознакомиться.

1. PHP SQLDIFF, a.k.a. SQLDiff

(http://phpsqldiff.sourceforge.net/)

PHP-скрипт, позволяющий увидеть полные различия (как в структуре, так и в данных) между любыми таблицами двух БД. В инструменте отсутствуют какие-либо средства по автоматической синхронизации структуры или данных – предоставляется лишь визуальная информация. Еще из существенных недостатков – возможность подключения только к БД, к которым возможен доступ напрямую (не через ssh-тоннель). Медленная скорость работы на больших объемах данных (работа через pear-модуль, который не блещет ни новизной, ни скоростью). Считаю данный скрипт весьма полезным для разработчика в случаях, когда необходимо понимание и визуальное представление различий между разными таблицами — имеет удобный интерфейс, быстрая настройка. Охарактеризую скорее как полезную карманную утилиту для быстрого получения понимания о рассинхронизации таблиц, которые в теории должны быть идентичны, нежели как серьезный инструмент, который можно применить для автоматизации процессов синхронизации.

2. LIQUIBASE

(http://www.liquibase.org/)

Удобный многофункциональный и простой в использовании мигратор структуры БД на 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

(http://schemasync.org/)

Инструмент для синхронизации структуры БД. Для работы необходим 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

4. MAATKIT data sync

(http://www.maatkit.org/doc/)
mk-table-sync — утилита для синхронизации данных таблиц. Сразу же упомяну, что maatkit — это целый комплекс средств для работы с MySQL, который предоставляет возможности, не заложенные в оригинальном MySQL. Это и не удивительно, учитывая, что данный продукт создан Percona – мы уже привыкли видеть от них продукты а-ля «Мы возьмем MySQL и добавим в него то, что в нем уже давно должно было быть».
Эффективно работает с таблицами только при наличии первичного ключа или уникального индекса (что, в общем-то, оправданно).
Имеет внушительное количество опций и настроек, позволяет синхронизировать master-slave, master-master конфигурации. Позволяет запускать автоматическую синхронизацию, но нас интересует в первую очередь не этим, а возможностью создать именно лог изменений. Думаю, по этой утилите можно написать отдельную статью, поэтому не буду углубляться в настройки – акцентирую лишь на том, что опций действительно много и они дарят разработчику возможность очень гибкой настройки синхронизации, позволяя учитывать многие нюансы. Есть смысл читать оригинальную документацию (http://www.maatkit.org/doc/mk-table-sync.html).

Пример использования:

mk-table-sync
    --verbose
    --print
    --charset=DB_CHARSET,
        h=host,
        P=port1,
        u=user1,
        p=password1,
        t=table1,
        D=db1
        h=host2,
        P=port2,
        u=user2,
        p=password2,
        D=db2
    > /__path__/ChangeLogQueries.sql

Дополнение 1:

Упомянутые инструменты имеют существенный недостаток, который менее важен при деплое на production-сервер, но постоянно о себе напоминает в процессе разработки – скорость выполнения. Изначально была задача построить механизм, который позволит автоматизировать сихнронизацию между площадками в цепочке «разработчики — тестовые сервера — stage — production». Начиная (в упомянутой выше цепочке) с тестовых серверов все довольно просто – из ресурсов требуется только время, нагрузка минимальна. Если процесс выполняется автоматически по расписанию по ночам, то важно не то, за сколько времени выполнилось, а то, чтобы не создать нагрузку и чтобы к утру задача была полностью завершена. Если синхронизация регулярная, то списки изменений никогда не будут чрезмерно большими, а нагрузка будет ничтожной. Другое дело, когда речь идет о синхронизации между площадкой разработчика и тестовым сервером. В таком случае, синхронизация, выполняющаяся 1 час, всегда будет ощутимой и будет создавать неудобства. Эти обстоятельства и натолкнули на средство синхронизации №5:

5. «Полуавтоматическая синхронизация».

В описанных выше утилитах большую (чуть менее, чем полностью) часть времени занимает именно формирование списка различий. Применить же потом скрипт по устранению различий – действие достаточно быстрое (опять же, не аксиома, но в большинстве случаев в процессе разработки). Это наталкивает на мысли, что можно поработать над ручным формированием списка различий, а автоматизировать только его применение. Очевидных способов нашлось только два:
а) в любом продукте существуют методы для работы с БД — не важно, используете ли вы популярный фреймворк или у вашего продукта самодельное ядро. Достаточно фиксировать все необходимые запросы (если только стуктура интересует — DDL, если данные тоже — update и delete, к примеру) в собственное хранилище;
б) если ваш фреймворк (а еще больше этим грешат cms) не имеет возможности расширить методы класса, работающего с БД и даже не имеет обработчика событий в методе, выполняющем запрос к БД, можно парсить лог всех запросов (надеюсь, возможность включить такой лог имеет весь целевой софт) и фиксировать только необходимые действия из этого лога.

Такая «полуавтоматическая синхронизация» с созданием собственных логов изменений имеет право на существование, но должна побудить разработчика выполнять с помощью упомянутых выше утилит проверку после синхронизаций, что таблицы действительно совпадают (пусть это выполняется хотя бы по ночам по расписанию, чтобы быть уверенными, что человеческий фактор не внес свои коррективы в синхронность данных).

Дополнение 2:

(updated)
К сожалению, почти все упомянутые мной средства обладают существенным недостатком (и я буду рад, если ошибаюсь, но опровержений моим словам я не нашел) — все они требуют удаленного доступа к БД по tcp/ip. Учитывая, что нормальной практикой является разрешение доступа к БД только с локального хоста и запрет удаленного доступа, добиться синхронизации лишь средствами упомянутых утилит не удастся.
Большое спасибо пользователю DarkByte за предложенное решение с пробросом портов — это решает проблему.

Удачного применения и не забывайте делать бэкапы!

Синхронизация баз данных MySQL

Синхронизация баз данных MySQL состоит из создания резервной копии базы и последующего восстановления таблиц этой базы на другом сервере с помощью плагина «MySQL». Этот процесс включает в себя 2 последовательных задачи:

1

Резервное копирование данных исходной таблицы (в случае односторонней синхронизации) или обеих таблиц (при симметричной синхронизации).

2

Восстановление данных в синхронизируемую таблицу MySQL, полное или дифференциальное, в зависимости от типа синхронизации.

Детальное описание задач копирования и восстановления MySQL имеется в Руководстве Пользователя.

Автоматизация задач синхронизации таблиц MySQL

Чтобы сделать процесс синхронизации баз данных MySQL полностью автоматическим, обратите, пожалуйста, внимание на следующие пункты:

1. Разделите время запуска задач резервного копирования MySQL и их восстановления на достаточно большой промежуток, чтобы запущенная задача резервного копирования базы данных успела завершиться перед началом восстановления.
2. Выбирайте для промежуточных копий MySQL достаточно быстрые по скорости доступа носители: локальные и внешние диски, устройства NAS/SAN и серверы FTP/SFTP/FTPS с широкой пропускной способностью сетевого интерфейса.
3. Пользуйтесь возможностями Шага 7 (установка запуска программ до и/или после выполнения задачи) для автоматического останова и перезапуска сервера MySQL на стороне восстановления, а также на стороне записи – для «холодной» загрузки данных.

4. Поскольку резервные копии хранятся в доступном для чтения текстовом формате, пользуйтесь при необходимости инструментами для внесения исправлений в восстанавливаемые файлы – скажем, для смены механизма хранения данных.

Как было сказано выше, синхронизация баз данных (БД) MySQL не заменяет регулярного резервного копирования. Мы рекомендуем обеспечивать задачи резервного копирования БД MySQL с помощью одного из бизнес-ориентированных решений нашего программного обеспечения (ПО).

Скачать Handy Backup

Полнофункциональная бесплатная пробная версия в течение 30 дней!

• Если вам нужно работать только с одним сервером СУБД MySQL, Handy Backup Office Expert обеспечит вас всеми необходимыми возможностями для этого и многими дополнительными функциями.
• Если вам необходимо обслуживать несколько серверов и рабочих станций, организуя процессы резервного копирования БД MySQL и любых других данных с общего рабочего места, используйте наше флагманское решение Handy Backup Server Network.

Чтобы сравнить цены на эти и другие продукты, пожалуйста, обратитесь к странице Купить.

Синхронизация баз MySQL с помощью сервиса Dropbox / Хабр

По долгу службы мне приходиться трудиться много и в разных местах. На работе, дома и в командировках меня преследует одержимость моей работой. Я работаю в небольшой веб-студии и в мои задачи входит верстка сайтов и проектирование GUI для интранет-проектов. Не могу не упомянуть неоценимую помощь моих верных друзей, их имена iMac, Mac Pro и MacBook. В своей работе я использую джентльменский набор верстальщика в Mac OS X: Coda — для редактирования HTML/JavaScript и MAMP — для запуска локального веб-сервера. Но речь пойдет не о установке и настройке вышеперечисленных продуктов, а о том как облегчить жизнь разработчикам имеющим в своем парке два и более компьютера работающих под управлением Mac OS X.

Давным-давно, когда много-мегабитные интернет каналы существовали у обычного обывателя только в фантазиях, все мы довольствовались простым способом переноса данных с одного компьютера на другой — флешка или внешний винчестер. За последний год, мой флеш-брелок служивший мне верой и правдой больше четырех лет, мирно покоится на книжной полке. Его заменил аккаунт Dropbox — всем Вам известном сервисе по хранению и синхронизации данных. Бесплатного аккаунта размером 2Гб мне вполне хватает для синхронизации всех рабочих проектов между моими рабочими лошадками.

Если с синхронизацией обычных файлов, HTML-шаблонов и скриптов, скорее всего, ни у кого из Вас вопросов не возникает, то с синхронизацией баз MySQL не все так просто. Нет. Вру..! На самом деле все очень просто! Есть два (бесплатных) варианта:

1. В конце рабочего сеанса делать выгрузку дампа измененных баз (естественно в Dropbox) с последующим импортом дампа в MySQL на следующей машине
2. Полностью хранить базы в Dropbox

Нетрудно догадаться, что второй вариант идеален, а его воплощение в жизнь займет у Вас не более пяти минут. Итак приступим:

В-первую очередь выясним где MySQL запущенный с помощью MAMP хранит свои данные. Запускаем phpmyadmin и переходим на закладку «Переменные». В списке находим переменную datadir и ее значение. В переменной указано местоположение на диске файлов с базами. В моем случае — /Library/Application Support/appsolute/MAMP PRO/db/mysql/

1. Выключаем MySQL сервер, открываем терминал и начинаем шаманить.

2. Создадим папку для хранения базы MySQL:
mkdir -p ~/Dropbox/database

3. Переходим в папку с каталогом базы (не забываем про экранирование пробелов)
cd /Library/Application\ Support/appsolute/MAMP\ PRO

4. На компьютере с актуальной базой данных перемещаем папку с локальной копией базы MySQL в хранилище Dropbox. На всех последующих компьютерах этот шаг пропускаем.
mv db ~/Dropbox/database/db

5. Удаляем папку с локальной копией базы MySQL:
rm -rf db

6. Создаем символическую ссылку на хранилище Dropbox
ln -s ~/Dropbox/database/db db

7. Всё готово! Теперь можно запускать MySQL сервер.

Действия по указанному алгоритму необходимо выполнить на всех синхронизируемых машинах.

Для корректной синхронизации, в конце рабочего сеанса необходимо отключать mysql сервер. Это связано с тем, что работающий mysql блокирует файлы с которыми он работает и синхронизация таких файлов невозможна до их разблокировки. Упростить процедуру завершения трудового сеанса можно создав скрипт в Automator.

Надеюсь моя небольшая заметка принесет вам пользу.

Веб-синхронизация слиянием на MS SQL / Хабр

Данную статью-инструкцию решено было написать для помощи моим друзьям и коллегам по работе, так как большинство из них не сталкивалось с настройкой веб синхронизации в MS SQL, и я надеюсь, что она позволит избежать некоторых мелких проблем, с которыми столкнулся я сам при настройке. Надеюсь и вам, уважаемое хабрасообщество, она может пригодиться.

Информация по настройке в интернете имеется, но как мне показалось, что все очень разрознено и по большей части нет практической части в настройке. Возможно плохо искал.

Зачем и для чего

И так нам нужно синхронизировать информацию между двумя магазинами, чтоб они всегда получали актуальные количества товаров, справочники и т. д и чтоб это все регулировалось с одного бэк-офиса, а в магазинах были бы только фронт-офисы.

Почему бы не настроить репликацию с белыми IP или через VPN:

1. Провайдер не предоставляет белый IP.
2. Используется мобильный интернет с плохой скоростью.
3. При использовании PPTP провайдеры блокируют GRE.
4. VPN имеет особенность обрываться, хоть и после восстанавливает соединение.
5. Из-за незначительной потери связи агент SQL Server не всегда успевает соединиться с подписчиком, и следующая попытка идет по расписанию через некоторое время, при не частой синхронизации это может быть достаточно критично.
6. При большом количестве публикаций и подписчиков соединяющихся с сервером, опять же агент не всегда «успевает» соединиться с подписчиком. Помогает обычно настройка расписания для того, чтоб синхронизация не проходила для всех в одно время, что тоже не всегда удобно.

При работе с веб-синхронизацией в репликации слиянием синхронизация данных идет по HTTPS и обновления отсылаются в виде XML, это позволит избежать проблемы, описанные выше, возможно не все, но все же:

1. Нам не требуется постоянный IP и соответственно пользователь не привязан к рабочему месту и может быть со своим ноутбуком где угодно.
2. Соединение использует безопасный протокол.
3. Маловероятно, что провайдером будет блокироваться порт 443.
4. При медленном интернет соединении синхронизация проходит быстрее и обрывов по моим наблюдениям гораздо меньше.
5. Агент слияния располагается на подписчике, что снижает нагрузку на сам сервер.

Небольшое отступление от основной темы:По своей работе очень часто приходится сталкиваться с репликацией слиянием, репликацию настраиваем для одной товаро-учетной системы болгарского разработчика. В основном вся настройка репликации у нас сводится с использованием белых IP адресов и пробросом порта 1433 наружу или настройкой VPN канала, а тут уже каждый настраивает по своим возможностям и знаниям.

Первый вариант можно просто и быстро настроить, но в плане безопасности он проигрывает, на него со временем начинают идти атаки в основном с китайских IP, конечно спасает firewall, но «добросовестные» пользователи очень любят его отключать.

Второй вариант уже более безопасный (хоть и не всегда), но требует от партнеров, которые занимаются автоматизацией больших знаний в настройке, в основном используются Hamachi, SoftEther или следующими по полярности это OpenVPN или функционал Windows Server (в основном PPTP).

Сам по большей части до поры до времени использовал при работе с репликацией возможности Windows Server (SSTP) и\или OpenVPN.

Подготовка

Работать с веб-синхронизацией можно начиная с MS SQL 2005 и старше, на центральном сервере потребуется редакция Standard или старше, для подписчика достаточно Express редакции.

В данном примере используются:

• Microsoft SQL Server 2014 Standard в роли издателя.
• Microsoft SQL Server 2014 Express в роли подписчика.
• Установленный на центральный сервер IIS
• Развернутая основная база данных нашего магазина на издателе.
• Созданная пустая база данных на подписчике.
• Пользователь Windows с правами доступа для группы IIS_IUSRS
• Немного терпения.

Настройка IIS

1. В первую очередь подготовим IIS для работы, создадим каталог для сервиса C:\inetpub\wwwroot\WebSQL. Если на сервере предполагается работа с несколькими публикациями создайте отдельные каталоги в WebSQL\RCU.
2. Скопируйте replisapi.dll из C:\Program Files\Microsoft SQL Server\120\COM в каталог, созданный на первом шаге в WebSQL, при работе с несколькими публикациями скопируйте в WebSQL\RCU.
3. На многих интернет ресурсах рекомендуется провести регистрацию библиотеки, но в моем случае, как ни странно это не потребовалось. Для регистрации воспользуйтесь командой regsvr32 «C:\inetpub\wwwroot\WebSQL\RCU\replisapi.dll» от имени администратора.
4. Создадим новый веб-сайт через диспетчер служб IIS. Физический путь указываем каталог, созданный на первом шаге, если есть подкаталоги внутри оставляем в любом случае корневой каталог.Добавление веб-сайта
5. После добавим к нашему сайту виртуальный каталог. Псевдоним указываем согласно имени каталога и указываем физический путь до него. Если каталог один путь можно указать на коренной каталог.Добавление виртуального каталога
6. Следующим шагом настроим разрешение для исполнения replisapi.dll для этого в диспетчере служб IIS выберем виртуальный каталог и в центральной панели в категории IIS найдем пункт сопоставление обработчиков. Далее в панели действий выберем пункт добавить сопоставление модуля.Сопоставление обработчика
   • В поле путь запроса укажем replisapi.dll
   • В списке модулей выберем IsapiModule. Если данного модуля в списке нет тогда в компонентах Windows для IIS служб требуется добавить расширения ISAPI.

   Добавление компонентов Windows

   • Для исполняемого файла укажем путь до библиотеки в виртуальном каталоге C:\inetpub\wwwroot\WebSQL\RCU\replisapi.dll. Хочу обратить внимание, что опять же если публикаций несколько, тогда и обработчик добавляете для каждого виртуального каталога со своим путем.
   • В поле имя укажем Replisapi
   • Нажмем кнопку ограничения и перейдем на вкладку доступ и выберем выполнение.

   Ограничения запроса

   • Подтверждаем изменения в окне ограничения запроса и в сопоставлении модуля. При подтверждении нам будет выведен предупреждение о том действительно ли мы хотим разрешить данное расширение ISAPI, нажимаем да.

   Разрешить данное расширение

   • Добавим обработчик требуется его включить, так как по умолчанию он будет не запущен, для это найдем и выберем его в списке обработчиков и в панели действий нажмем изменение разрешений функции и в открывшемся окне отметим пункт выполнение и подтвердим изменения.

   Изменение разрешений функции

7. Для правильной работы потребуется настроить проверку подлинности для сайта целиком в IIS. В центральной панели в категории IIS выберем проверку подлинности и отключим анонимную проверку подлинности и включим обычную проверку подлинности. Опять же если данный пункт отсутствует в IIS, требуется добавить данную возможность в компонентах Windows.Проверка подлинности
8. Следующим шагом мы должны привязать SSL сертификат к сайту, саму процедура получения сертификата описывать не буду, так как данной информации везде предостаточно, в том числе и на Хабрахабре.
   • Получаем SSL сертификат к примеру, на startssl и формируем PFX файл.
   • В диспетчере IIS для самого сервера IIS выбираем в центральной панели сертификаты сервера и в панели действий выберем импортировать, укажем путь до сохраненного сертификата и пароль к нему.

   Импорт сертификата

   • После импорта снова выбираем сайт в диспетчере и в панели действий выбираем привязки и в открывшемся окне выбираем добавить. Выбираем тип https и в списке SSL-сертификат выбираем тот, который импортировали на предыдущем шаге и подтверждаем изменения. Привязку для http можно удалить за ненадобностью.

   Добавление привязки

9. Последним шагом в настройке IIS проверим сервиса для этого перейдем по данному адресу https://server.domain.com/rcu/replisapi.dll?diag и введем логин и пароль пользователя Windows (для каждой публикации рекомендую создавать отдельного пользователя). При успешном подключении должна отобразиться диагностическая информация, как на скриншоте ниже.Диагностическая информация

Создание и настройка публикации

1. Подключаемся к центральному серверу с Microsoft SQL Server 2014 Standard через Management Studio в Object Explorer -> Replication -> Local Publication -> New Publication (в контекстном меню), далее следуем по шагам мастера создания публикации. На данном этапе настройка репликации слиянием с использованием веб-синхронизации не отличается от настройки в локальной сети.
   • Выбираем базу данных для публикации.

   Выбор базы

   • Выбираем тип репликации — репликация слиянием (Merge)

   Тип репликации

   • Выбираем с какими версиями SQL Server будет совместима репликация. У себя обычно использую SQL Server 2005 и SQL Server 2008 и старше, так как бывают совсем слабые машины.

   Совместимость

   • Указываем, какие таблицы будут участвовать в синхронизации. Хочу дополнительно отметить если синхронизация будет проходить не часто, а записей по каким-либо таблицам будет проходить много, рекомендую увеличить значения для Publisher range size и Subscriber range size к примеру, до 1 000 000. Больше ставить не рекомендуется, так как диапазон может быстро закончится при большом количестве подписчиков и частом их пересоздании, так же хочу отметить если используется автоматическая выдача диапазона (Automatically manage identity ranges), увеличьте процент для выделения нового диапазона при достижении порога (Range threshold percentage), например, 90-95.

   Таблицы

   Диапазон издателя и подписчика

   • Данный шаг оставляем без изменений для всех таблиц будет добавлена колонка с уникальным идентификатором.

   Уникальный идентификатор (не обязательно)

   • Фильтрацию синхронизируемых данных оставляем на без изменений, если фильтрация потребуется её можно добавить в любое время.

   Фильтрация (не обязательно)

   • Указание расписания для снятия моментального снимка, данный шаг можно, так же оставить по умолчанию или изменить его расписание по своему усмотрению.

   Моментальный снимок (не обязательно)

   • Указываем настройки безопасности для агента моментальных снимков. Выбираем в настройках «Выполнять с учетной записью службы агент SQL Server» и соединение с издателем «Путем олицетворения учетной записи процесса» и подтверждаем изменения.

   Безопасность агента

   • Следующий шаг оставляем без по умолчанию в нем на предлагается подтвердить создание публикации и сгенерировать скрипт по пройденным шагам для создания публикации.
   • Указываем имя публикации и нажимаем Finish. Обычно для удобства пишу имя так «имя_базы_pub»

   Имя публикации

   • Дожидаемся окончания создания публикации и проверяем, чтоб все пункты завершились корректно.

   Создание публикации

2. После создания публикации нам потребуется произвести дополнительные настройки. Для этого выберем созданную публикацию в Object Explorer -> Replication -> Local Publication -> имя_публикации и откроем настройки.
   • В основных настройках укажем, что срок действия подписок никогда не истекает, это нужно в том случае если планируется, что подписчики могут находиться продолжительное время в офлайн и операций проходить много не будет. В ином случае укажите через какой срок будут удалены метаданные репликации.

   Срок действия подписок

   • В настройках моментального снимка (Snapshot) укажем альтернативное место хранения снимка при этом каталог должен быть доступен для общего доступа в сети и путь до каталога должен указываться сетевой. В данном примере это будет \\Replication\ftproot. Так же установим сжатие для снимка в данной папке.

   Расположение моментального снимка

   • Далее в настройках FTP и интернет для моментального снимка (FTP Snapshot and internet) разрешим синхронизацию подписчиков через web сервер, а также укажем адрес ранее созданного сайта https://server.domain.com/rcu/replisapi.dll

   Синхронизация подписчиков

   • Последним шагом в настройке публикации будет добавление пользователя в список доступа публикации (Publication Access List). Пользователя заранее создаем для каждой публикации, после добавляем его в MSSQL Server, сопоставляем с базой данных для публикации и указываем членство в роли db_owner.

   Сопоставление пользователя

   Список доступа к публикации

Создание подписки и синхронизация

1. Подписку при веб-синхронизации потребуется создавать скриптами, а не через мастер, по причине того, что синхронизация с подпиской у нас будет выполнять по запросу, а также из-за того, что на MSSQL Server Express нельзя запустить агент. Скриптами в любом случае получается на много быстрее.
   • В начала добавим подписчика на центральном сервере с публикацией

   USE имя_базы
   GO
   EXEC sp_addmergesubscription
   @publication = N'Microinvset_pub', -- Указываем имя публикации
   @subscriber = 'Kassa01-PC', -- Указываем имя ПК подписчика
   @subscriber_db = N'MicroinvestFront', -- Указываем имя пустой базы данных на подписчике
   @subscription_type =N'pull';
   

   • Далее добавляем подписку по запросу уже на самом подписчике

   USE имя_базы
   GO
   EXEC sp_addmergepullsubscription
   @publisher = 'MainServer', -- Указываем имя сервера с публикацией
   @publication = N'Microinvset_pub', -- Указываем имя публикации
   @publisher_db = N'Microinvest'; -- Указываем имя базы данных публикации
   

   • Так же на подписчике добавляем задание для агента для синхронизации подписки по запросу

   USE имя_базы
   GO
   EXEC sp_addmergepullsubscription_agent
   @publisher = 'MainServer', -- Указываем имя сервера с публикацией
   @publisher_db = N'Microinvest', -- Указываем имя базы данных публикации
   @publication = N'Microinvest_pub', -- Указываем имя публикации
   @distributor = 'MainServer', -- Указываем имя сервера с публикацией
   @use_web_sync = 1, -- Разрешаем WEB синхронизацию.
   @internet_security_mode = 0, -- Указываем проверку подлинности, в данном случае используется обычная проверка подлинности (проверка пароля и имени входа, входящая в протокол HTTP). 
   @internet_url = 'https://server.domain.com/rcu/replisapi.dll', -- Указываем адрес ранее созданного сайта
   @internet_login = 'Логин пользователя Windows, который мы вводили в браузере при входе в диагностическую информацию',
   @internet_password = 'Пароль пользователя Windows, который мы вводили в браузере при входе в диагностическую информацию',
   @internet_timeout = 9999; -- Указываем время в секундах до истечения срока действия запроса на веб-синхронизацию
   

2. Наконец доходим до самого главного до первой синхронизации, как уже было написано ранее Express редакция MSSQL не позволяет запустить встроенный агент, но никто не запрещает сделать свой агент при помощи RMO, мы же пойдем более простым путем и будем запускать агент слияния вручную при помощи батника, который после просто поместим в планировщик Windows.

   @echo OFF
   SET Publisher=MainServer
   SET Subscriber=Kassa01-PC
   SET PublicationDB=Microinvest
   SET SubscriptionDB=MicroinvestFront
   SET Publication=Microinvest_pub
   REM -- Путь до расположения REPLMERG.EXE указываем в зависимости от версии MSSQL Server
   "C:\Program Files\Microsoft SQL Server\120\COM\REPLMERG.EXE" -Publication %Publication% -Publisher %Publisher%  -Subscriber  %Subscriber%  -Distributor %Publisher% -PublisherDB %PublicationDB%  -SubscriberDB %SubscriptionDB% -DistributorSecurityMode 1 -SubscriptionType 1 -SubscriberSecurityMode 1
   

3. По завершению синхронизации вы увидите примерно следующую информацию в CMD, как на скриншоте.Итог запуска синхронизации
4. Контролировать ход репликации можно, как и раньше через монитор репликации.Монитор репликации

Послесловие

Веб-синхронизация настроена нам остается только разместить созданный выше батник в планировщик Windows и запускать его автоматически, например, раз в 5-10 минут, конечно если это требуется. При запуске батника и синхронизации будет постоянно выскакивать окно с CMD, чтобы этого избежать можно запускать батник через WScript.exe, например, так:

Set WshShell = CreateObject("WScript.Shell")  
WshShell.Run "startsync.bat", 0, false  
Set WshShell = Nothing  
WScript.Quit

После чего данный скрипт указываем для запуска в планировщике. Дополнительно по синхронизации отмечу если планируются довольно объемные передачи данных, возможно потребуется увеличить значение для WebSyncMaxXmlSize. Настраивается данный параметр в реестре HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\120\Replication\, будьте аккуратнее с данной настройкой, так как при увеличении значения, увеличивается и количество потребляемой виртуальной памяти.

Ссылки

1. Веб-синхронизация для репликации слиянием
2. Как синхронизировать подписку по запросу (программирование репликации)
3. Как синхронизировать подписку по запросу (программирование объектов RMO)

Постарался указать все нюансы, с которыми пришлось столкнуться самому даже не которые могут быть очень банальными, но такие банальности иногда могут отнять много времени, особенно если не знаешь где искать.

Спасибо всем, кто осилил статью до конца, буду рад любым вашим комментариям.

Синхронизация БД SQL Server из различных источников

Сценарий использования

Приложения, используемые торговыми представителями или другими работниками на местах – курьеры службы доставки, выездные медсёстры, сотрудники клининговых компаний и т.д., предназначены для сбора информации на местах с последующей отправкой её в центр обработки данных. Кроме того, периодически необходима обратная связь, т.е. отправка данных обратно от центра обработки к конкретным исполнителям на местах.

Например, каждый раз, когда медсестра осуществляет визит к пациенту, она делает отметку о визите на мобильном устройстве. По итогам рабочего дня, вся информация отправляется в централизованную базу данных больницы. После этого, они могут синхронизировать свои мобильные устройства с центром обработки данных, чтобы получить актуальную информацию о своих пациентах или узнать список новых посещений, который они должны осуществить на следующий день.

В любом подобном сценарии использования основная потребность – это постоянный обмен данными между мобильными устройствами на местах и общим хранилищем данных.

Как можно решить подобные задачи

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.

1. Запустите ApexSQL Data Diff
2. В качестве источника (Source) укажите базу данных (Database). Далее укажите сервер БД и имя вашей центральной БД.

3. В качестве назначения (Destination) укажите так же базу данных (Database). В качестве сервера укажите удалённое мобильное устройство медсестры и БД, которую необходимо синхронизировать.

4. Нажмите кнопку сравнить (Compare).

   После поиска различий вы получите результирующую таблицу (Main grid) с расхождениями по каждому объекту в ваших БД.

   Записи, вставленные в таблицу посещения (Visits) в больнице, показаны на вкладке отсутствующих записей (Missing).

5. Укажите таблицы, которые вы хотите синхронизировать

6. Нажмите синхронизировать (Synchronize) на вкладке главная (Home).

7. На шаге направления синхронизации (Synchronization direction) мастера синхронизации (Synchronization wizard) нажмите далее (Next).

8. В параметрах вывода результата (Output options) мастера синхронизации (Synchronization wizard) выберите в качестве действия синхронизировать базу данных (Synchronize a database).

9. Нажмите далее (Next).

10. Просмотрите сводку действий, которые будут выполнены и вероятные предупреждения (Summary and warnings).

11. Нажмите синхронизировать (Synchronize) на вкладке главная (Home).

12. В диалоговом окне уведомления нажмите ОК.

    После завершения синхронизации вы увидите следующее уведомление

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

Для обратной синхронизации всех изменений, которые совершили медсёстры в течении дня необходимо выполнить похожие действия:

1. В качестве источника (Source) укажите БД с мобильного устройства, а в качестве назначения (Destination) – центральное хранилище поликлиники.

2. Нажмите сравнить (Compare).

3. Выберите таблицу, в которую были добавлены записи в течении дня, все новые значения можно увидеть на вкладке отсутствий (Missing):

4. В основном меню нажмите кнопку синхронизировать (Synchronize).
5. С помощью мастера синхронизации (Synchronization wizard) укажите записи, которые необходимо добавить в центральное хранилище поликлиники.
6. Нажмите кнопку сохранить (Save) на вкладке главная (Home), чтобы сохранить все настройки синхронизации в виде проекта, тем самым в следующий раз вы сможете легко и быстро выполнить подобную синхронизацию.

Теперь рассмотрим, как автоматизировать процесс синхронизации, при наличии проектов синхронизации.

1. Сохраните следующую команду в виде bat-файла E:\Test\Morning.bat, который будет выполнять ранее созданный проект Morning_Central_Nurse.axdd:

   "C:\Program files 
   (x86)\ApexSQL\ApexSQLDataDiff2014\ApexSQLDataDiff.com" /
   pf:D: \Test\Morning_Central_Nurse.axdd /
   of:D: \Test\MorningSync.sql / sync / bu:D: \Test / v / f
   

   Он создаст в папке D:\Test скрипт MorningSync.sql, который добавит данные из центральной БД в базы данных медсёстр. В папке D:\Test создайте полную резервную копию БД медсестры и вставьте недостающие записи.

2. Запустите SQL Server Management Studio

3. В Object Explorer раскройте SQL Server Agent и правой кнопкой мыши по Jobs создайте новое задание (New job).

4. Укажите имя задания.

5. На вкладке Steps нажмите New, чтобы создать новый шаг задания.
6. Дайте имя новому шагу, в качестве типа укажите “Operating system (CmdExec)” и нажите кнопку открыть (Open).

7. Select the saved batch file D:\Test\MorningSync.bat

8. Нажмите кнопку OK.

9. На вкладке Schedules укажите расписание, по которому должна происходить синхронизация данных.

Для вечерней синхронизации повторите шаги с 3 по 9, чтобы создать ещё одно задание.

С помощью приложения ApexSQL Data Diff вы можете легко настроить синхронизацию ваших удалённых БД SQL Server с центральным хранилищем. При этом вы не привязаны к какой-то конкретной версии или редакции SQL Server, от вас не потребуется дополнительного времени на разработку, при этом вы осуществляете полный контроль над всеми вашими данными до единой записи.

Переводчик: Алексей Князев

November 20, 2015

облако для приложений и структурированных данных / Блог компании Яндекс / Хабр

Для синхронизации данных в приложениях не подходят обычные «файловые» облачные хранилища. Слишком много проблем с консистентностью данных приходится решать самим авторам приложений. Поэтому сегодня мы открываем всем желающим технологию DataSync API, которую команда Яндекс.Диска разрабатывала для собственных сервисов Яндекса. Она позволяет синхронизировать структурированные данные между облачным хранилищем и устройствами. API использует логин Яндекса, который есть почти у каждого пользователя интернета в России и у многих в других странах. DataSync мультиплатформенный и не завязан только на Android или iOS.

Мы правда очень рады, ведь еще три года назад, когда запускался Яндекс.Диск, хотели синхронизировать не только файлы между компьютерами, а вообще любые данные между всеми устройствами человека. Наша цифровая жизнь – это не только файлы, но еще и точки на картах, маршруты, закладки в браузере, список рекордов в компьютерной игре и много другое.

Уже более двух лет Яндекс.Браузер работает на технологиях синхронизации Я.Диска. В ближайшем будущем другие крупные сервисы Яндекса начнут объединять свои платформы на DataSync. Под катом — больше подробностей о том, как он устроен, зачем нужен, и примеры, на которых можно посмотреть и попробовать, как всё работает.

Когда-то базовым инфраструктурным элементом интернета стал веб-сервер, без которого теперь невозможно представить существование всемирной сети. Теперь времена изменились, и мы уверены, что облачная самосинхронизирующаяся база данных будет не менее важным элементом современного мультиплатформенного интернета.

Раньше у пользователя было только одно устройство и только один способ взаимодействовать с интернет-сервисом – пойти на сайт. И для разработчика все было просто. База-Код-Веб-интерфейс. Где-то в недрах сайта работала база данных, где разработчик сохранял нужные ему данные, и откуда их забирал, отображая на одном единственном устройстве пользователя, а точнее — в браузере его компьютера.

Однако времена сильно изменились, и теперь у человека может быть множество устройств, а один сервис может быть представлен целым набором приложений. Это сильно усложнило жизнь разработчика. У него всего стало больше: интерфейсов, баз, логики и даже языков программирования. Но самое ужасное — это данные. На каких-то устройствах есть локальные копии данных, которые живут на сервере и других устройствах, и их все необходимо синхронизировать между собой. Это вовсе не простая задача: возможны конфликты, потеря данных, потеря связи, требуется нормальная скорость работы на всех устройствах – и много другое.

Очевидно, что если разработчик каждый раз будет сам решать с нуля задачи синхронизации приложений и облачного хранения данных, он, скорее всего, забудет, что он собственно собирался сделать изначально или доберется до этого совсем не скоро.

Конечно же, задача решить описываемую проблему появилась и в Яндексе. Мы начали работать над созданием «облачной базы данных», которая освободит разработку от рутинной задачи синхронизации и позволит сфокусироваться на создании приложений.

Обычная база данных скучно живет на одном компьютере, а мы делали базу, которая живет одновременно в облаке и на всех устройствах пользователя. Это, разумеется, как готовое решение, принципиально упрощает задачу разработки мультиплатформенных приложений. Где бы ни были сохранены данные в такую базу – на телефоне, в браузере, на сервере, – ничего не потеряется и везде появятся актуальные данные.

Во внутренней документации на проект написано так: «DataSync API — это хранилище произвольных структурированных данных, привязанных к пользователю или паре пользователь + приложение. Оно заточено под возможность синхронизации между пользовательскими устройствами и нормальную работу в условиях плохой мобильной сети».

Для внешнего разработчика наша база данных очень похожа на популярную noSQL базу MongoDB — суть та же. Она состоит из коллекций, коллекции — из объектов. Объект — это набор key-value полей. Но мы поставили перед собой задачу сделать так, чтобы разработчик не думал о том, как ему связывать данные на разных устройствах и в облаке, а просто работал с нашим API, в то время как вся синхронизация данных происходила магическим образом. Конечно же, такая «магия» возможна, когда вы используете и облако, и клиентскую часть нашего «синхронизирующего» SDK.

И тут хочется чуть подробнее рассказать, какие проблемы и как мы решали, чтобы она случилась.

Конфликты

В предложенном устройстве мира у нас много экземпляров базы, и все они меняются локально. В такой ситуации неизбежно появление конфликтов, когда данные меняются одновременно в разных местах. А терять данные совсем не хочется. Алгоритм решения этой проблемы достаточно традиционный:

• у всех экземпляров данных появляется версия, о которой знает каждое устройство и сервер;
• при отправке изменений она отсылается и проверяется на сервере;
• в случае несовпадений версий клиент получает список изменений, о которых он не знал, и может правильно разрешить конфликт.

Прозрачная работа без сети

Мобильное приложение (да и многие другие) не может рассчитывать на стабильную связь, а данные сервиса могут измениться в любой момент. Это не должно быть проблемой для того, кто использует нашу облачную базу. Очевидно это так же очень важно учитывать в нашем SDK. Мы решили эту проблему такой схемой действий:

• все общение с сервером на себя берет наш SDK;
• общение с сервером полностью асинхронно и происходит в фоне;
• методы, которые SDK представляет разработчикам, никогда не ждут окончания чтения/записи из сети.

В документации DataSync API описаны все методы, которые используют наши собственные SDK. Вам ничего не стоит сделать собственную защищенную от конфликтов и обрывов связи библиотеку для любой платформы.

Мы сначала сделали так, что каждое «приложение» синхронизируется с таким же на других платформах и на сервере. Но потом нашлись примеры, когда важно синхронизировать данные между разными приложениями на одном устройстве – грубо говоря, иметь общую базу данных. И тогда мы реализовали и такое. Теперь, например, если у вас есть lite-приложение и полноценное, то вы без труда сможете пробросить данные пользователя, который решился на апгрейд, из одного в другое. Или отправить или получить данные из приложения партнера.

Как устроен API

В процессе работы с API клиент в основном оперирует такими понятиями, как:

• база данных (БД),
• дельта обновления,
• снэпшот,
• конфликт.

БД является единицей синхронизации для API. Она содержит в себе объекты (записи), объединенные в коллекции. Но все операции по сути дела производятся с отдельными объектами. При этом чтобы однозначно идентифицировать объект, необходимо указать идентификатор его и коллекции.

Идентификатором состояния БД является номер ревизии. В API реализована схема контроля ревизий, что позволяет отслеживать и фиксировать конфликтные ситуации. При создании БД ревизия равна нулю, при дальнейшем получении каких-либо изменений для данной базы номер ревизии будет увеличиваться на единицу. Любые изменения осуществляются за счет отправки дельты обновлений. С её помощью можно создавать, удалять и редактировать записи.

Конфликтом считается такая ситуация, при которой клиент отправляет на сервер ревизию младше существующей на нём. В таком случае сервер смотрит на номер пришедший ревизии и отправляет набор изменений до существующей версии.

В случае, когда ревизия на клиенте настолько устарела, что сервер не может предоставить список необходимых изменений, клиенту необходимо получить снэпшот базы и обновиться до текущей ревизии самостоятельно. Схема решения конфликтов остается на усмотрение разработчиков.

Снэпшот базы отражает состояние актуальной ревизии базы на сервере. Его необходимо запрашивать при создании локальной БД на устройстве или при решении конфликтных ситуаций.

Для того чтобы расшаривать данные только в рамках собственного приложения, необходимо запрашивать права на доступ хранения данных приложения, для расшаривания данных – доступ к общим данным пользователя.

Заключение

Начать использовать HTTP API и JS SDK вы можете уже сейчас. В ближайшем будущем мы выпустим SDK для Android и iOS.

Посмотреть, как всё работает, можно на примере адресной книги в тестовом браузерном приложении. Оно демонстрирует, как может происходить синхронизация телефонных номеров пользователя с шагом в 20 секунд. Данные синхронизируются с облаком и любым экземпляром веб-приложения. Самый простой способ увидеть это — открыть две вкладки в браузере.

Синхронизация баз данных SQL Server в разных удаленных источниках

Сценарии

Приложения, используемые командированными торговыми представителями или другими работниками на местах — водителями-доставщиками, медсестрами и т. Д., Предназначены для сбора данных из удаленных мест и их последующей отправки в центр обработки данных. Кроме того, данные из центра обработки данных иногда необходимо отправлять обратно в эти удаленные места, чтобы поддерживать их актуальность.

Например, когда медсестры посещают пациента, они вводят информацию о посещении в базу данных на мобильных устройствах.В конце дня все эти записи, созданные в течение дня, отправляются в центральную базу данных в больнице. После этого медсестры могут синхронизировать мобильные устройства с базой данных в центре обработки данных больницы, чтобы они получали новую информацию о своих пациентах, а также информацию о любых новых визитах, которые им необходимо совершить на следующий день.

В подобном сценарии постоянно требуется синхронизировать информацию с мобильного устройства с центральной базой данных.

Решения

1.Используйте репликацию SQL Server. Он синхронизирует базы данных путем копирования и распространения записей из одной базы данных в другую, когда эти базы данных находятся в разных местах.

Существуют некоторые ограничения, когда нельзя использовать репликацию SQL Server:

• Только выпуски SQL Server Standard или Enterprise могут выступать в качестве издателя, поэтому при использовании бесплатного SQL Express потребуется обновление.
• Конфигурация с издателем SQL 2005 и подписчиком SQL 2008 не поддерживается для веб-репликации
• Версия распространителя должна быть больше или равна версии издателя
• Версия подписчика при репликации транзакций должна быть в пределах двух версий версии издателя, т.е.г. издатель SQL Server 2000 не может иметь подписчиков SQL Server 2012
• Версия подписчика в репликации слиянием должна быть меньше или равна версии издателя, например У подписчиков SQL Server 2012 не может быть издателя SQL Server 2008 Publisher

2. Используйте Sync Framework, API, который позволяет пользователям создавать приложения и синхронизировать между базами данных. Он обеспечивает большую гибкость, но также требует разработки, что увеличивает стоимость и сроки внедрения.

3. Используйте ApexSQL Data Diff , инструмент сравнения и синхронизации данных SQL Server, который обнаруживает различия в данных и устраняет их без ошибок. Он может сравнивать и синхронизировать действующие базы данных, резервные копии баз данных с встроенным или встроенным сжатием, папки сценариев, проекты системы управления версиями и генерировать исчерпывающие отчеты об обнаруженных различиях, создавать файл синхронизации и выполнять его.

Как это сделать

В следующем примере используются две базы данных:

1. База данных Central — это центр обработки данных больницы
2. База данных Медсестра на мобильном устройстве медсестры

Больница добавляет записи о посещениях в таблицу Посещения , и медсестры каждое утро синхронизируют свои мобильные устройства, чтобы получить последние записи и узнать, какой у них маршрут на день.Записи, вставленные медсестрами в течение дня, хранятся в таблице Visits и должны быть синхронизированы обратно в центр обработки данных в конце дня.

1. Начать различие данных ApexSQL

2. На вкладке Источники данных выберите сервер, на котором расположена база данных Central , в качестве источника и выберите сервер, на котором расположена база данных Медсестра , в качестве места назначения:

3. Нажмите кнопку Сравнить

4. После завершения сравнения будут показаны таблицы Visits вместе с соответствующими данными:

   Записи, вставленные в таблицу Visits из базы данных Central , показаны на вкладке Missing .

5. Нажмите кнопку Сохранить на вкладке Home , чтобы сохранить текущие настройки в проект и быстро и легко выполнить сравнение и синхронизацию в следующий раз:

6. Щелкните Synchronize на вкладке Home , чтобы запустить мастер Synchronization :

7. Щелкните Далее в направлении синхронизации шаг мастера синхронизации

8. На шаге Параметры вывода мастера Синхронизация выберите Синхронизировать сейчас как действие:

9. Нажмите кнопку Далее

10. Просмотрите сводку действий на вкладке Действия , которые будут выполнены:

11. Нажмите кнопку Synchronize в правом нижнем углу мастера синхронизации

12. Появится сообщение с подсказкой, содержащее информацию о том, что сценарий синхронизации будет выполняться в базе данных медсестер.Нажмите кнопку Да , чтобы выполнить синхронизацию:

13. Когда синхронизация целевой базы данных завершится, появится окно результатов со следующими сообщениями:

Если вечером записи, которые медсестры добавляли в свои базы данных в течение дня, необходимо синхронизировать обратно, в центральной базе данных шаги аналогичны:

1. На вкладке Источники данных установите базу данных Медсестра в качестве источника и базу данных Central в качестве назначения:

2. Нажмите кнопку Сравнить

3. Выберите таблицу, в которую записи были добавлены в течение дня.Записи отображаются на вкладке Отсутствует :

4. Нажмите кнопку Сохранить на вкладке Home , чтобы сохранить текущие настройки в проект и быстро и легко выполнить сравнение и синхронизацию в следующий раз:

5. Нажмите кнопку Synchronize на вкладке Home :

6. Повторите те же шаги в мастере синхронизации , как указано выше, и добавьте недостающие записи в базу данных Central

Автоматизация процессов

Теперь, когда оба проекта сохранены, процессы синхронизации можно автоматизировать, создав два сценария PowerShell:

1. Первый сценарий PowerShell автоматизирует синхронизацию записей из базы данных Central в базу данных Медсестра до начала утренней смены:

    # указать местоположение инструмента, определить переменную отметки даты и параметры инструмента
   $ appLocation = "ApexSQLDataDiff"
   $ dateStamp = (Get-Date -Format "MMddyyyy_HHMMss")
   $ appParameters = "/ pr:" "CentralToNurse.axdd "" / sync / v / f / Rece "
    # инициировать сравнение источников данных
   (Invoke-Expression ("&` "" + $ appLocation + "` "" + $ appParameters))
   $ dateStamp = $ LASTEXITCODE
    

2. Второй сценарий PowerShell автоматизирует синхронизацию записей из базы данных Медсестра обратно в базу данных Central , после окончания смены:

    # указать местоположение инструмента, определить переменную отметки даты и параметры инструмента
   $ appLocation = "ApexSQLDataDiff"
   $ dateStamp = (Get-Date -Format "MMddyyyy_HHMMss")
   $ appParameters = "/ pr:" "NurseToCentral" "/ sync / v / f / rec" 
    # инициировать сравнение источников данных
   (Invoke-Expression ("&` "" + $ appLocation + "` "" + $ appParameters))
   $ dateStamp = $ LASTEXITCODE
    

Планирование

После того, как оба сценария PowerShell созданы и весь процесс автоматизирован, его можно запланировать разными способами.Узнайте больше о различных способах планирования работы инструментов ApexSQL.

Сравнение и синхронизация баз данных SQL Server в удаленных местах с базой данных SQL Server в центре обработки данных с помощью ApexSQL Data Diff может выполняться независимо от версий SQL Server, используемых в удаленных и центральных точках, без знания программирования и под полным контролем , до уровня строки.

19 апреля 2013 г.

FIM 2010 Таблицы базы данных службы синхронизации SQL — Статьи TechNet — США (английский)

Таблицы базы данных SQL FIM 2010 — FIM 2010 R2 SP1

Исследование таблиц, созданных в базе данных FIMSynchronizationService

По мере того, как я начинаю изучать FIM, я решил создать статью о том, что хранится в различных найденных таблицах.

в базе данных FIMSynchronizationService

В настоящее время эта работа продолжается, поэтому детали будут изменены и добавлены, включая информацию о других таблицах:

Dbo.mms_run_history

Каждый раз, когда выполняется прогон профиля, в эту таблицу добавляется строка

Он содержит информацию, которую вы увидите в окне операций после нажатия кнопки операций.

по примеру скриншота

Таблица содержит столбцы с дополнительной информацией с уникальными идентификационными номерами

Дополнительные столбцы для информации, отображаемой на панели «Операции», не обязательно должны соответствовать точному названию

(e.г. run_result column = столбец статуса)

Колонны

Таблица содержит следующие столбцы (для заполнения)

.

Выбор очистить все запускает операция из пункта меню Действия очистит эту таблицу

Эта таблица будет продолжать расти, если вы регулярно не очищаете прогоны

Если таблица не очищена, она может в конечном итоге занять весь диск, на котором расположена база данных синхронизации FIM

Dbo.mms_run_profile

Хранит информацию о каждом созданном профиле запуска.

Таблица содержит следующие столбцы (для заполнения)

Дата создания

имя_профиля_пуска

configuration_xml

Dbo.mms_step_history

Каждый раз, когда выполняется профиль прогона, в эту таблицу добавляется строка для каждого шага в прогоне

Выбор очистить все запускает операцию в пункте меню Действия очистит эту таблицу

Информация, хранящаяся в этой таблице, — это информация, которую вы видите, когда выбираете шаг, который выполнялся как часть

рабочий профиль

Когда вы выбираете шаг, который был выполнен, вы можете увидеть различную информацию о действиях

Шаг

, указанный на панели статистики синхронизации , и
ошибки синхронизации / панель состояния

по примеру скриншота

Таблица содержит следующие столбцы (для заполнения)

Dbo.²mms_step_object_details

Каждый раз, когда выполняется шаг в профиле, в эту таблицу добавляется строка для каждого объекта

(например, пользователь, объект группы и т. Д.), В отношении которого было выполнено успешное действие против

это при пошаговом исполнении

Действие может быть проекцией, присоединяйтесь и т. Д.

Выбор очистить все запускает операция в пункте меню Действия очистит большую часть строк

в этой таблице, осталось несколько строк, которые я хочу идентифицировать

.