Синхронизация SQL Serverных баз через Облако


В прошлом посте мы использовали SQL Azure Data Sync для синхронизации между настольной Northwind1 и облачной Northwind1_Azure базами данных, которые были включены в Sync Group по имени "группа захвата". Базы данных безоблачных экземпляров в пределах одной машины взаимодействуют со службой синхронизации данных через клиентского агента. Это сделано по соображениям безопасности, чтобы исключить взаимодействие с сервисом напрямую, к тому же базы могут (и должны) прятаться за файрволом. Единственно, что мне не нравится, это предупреждение, что срок действия агента истекает:

 

image001

Рис.1

 

Если перейти в левой панели на агента, получается более развернутое сообщение:

 

image002

Рис.2

 

Ссылка в сообщении указывает на http://www.microsoft.com/en-us/download/details.aspx?id=27693. Это странно. С того же места я его ставил пару дней назад, и номер версии (4.0.5.0) с тех пор не изменился. Тем не менее как дисциплинированный пользователь я расстался со старым проверенным агентом Смитом. Предварительно нужно разрегистрировать все зарегистрированные на нем (см. Рис.17 предыдущего поста) локальные базы:

 

image003

Рис.3

 

Чтобы изменения отразились на портале Windows Azure Platform, следует нажать Refresh в верхнем меню:

 

image004

Рис.4

 

Тогда Northwind пропадает из-под агента в левом дереве, и агента можно прикончить с помощью кнопки Remove из того же меню:

 

image005

Рис.5

 

После чего по-новой запустил установку агента с приведенной ссылки, повторив шаги Рис.6 - 18 предыдущего поста. Смит1 установился, освоился и выкинул желтый треугольник совершенно аналогично (см.Рис.1) своему безвременно погибшему предшественнику. Что-то здесь не то, догадался я, и обратился к авторам этой замечательной проги. Ответили в том ключе, что сейчас агента менять не нужно, потому что нового они еще не доделали, а ссылка должна вести на страницу, разъясняющую что новый сервис (тот, который выйдет в июньском обновлении) будет несовместим со старой версией агента, но почему-то не ведет. Большое мне спасибо, что я это заметил. Высказав со своей стороны теплые слова в адрес аффторов, я забил на вопли агента и двинулся дальше.

 

Дальше нам предстоит добавить в существующую группу синхронизации еще одну настольную базу, которая будет синхронизироваться с первой настольной, а облачная будет играть роль посредника, или хаба. Если воспользоваться традиционными для такого рода примеров обозначениями, взятыми из повести Пушкина "Дубровский", то первая настольная база Northwind1 будет играть  роль Маши, облачная база Northwind1_Azure - дупла, и еще нужно создать вторую настольную базу на роль Дубровского. Идем в ту же группу синхронизации, видим иконку, на которой написано Click to add a SQL Server database, и, натурально, кликаем:

 

image006

Рис.6

 

Далее по накатанной дорожке, как проходили в предыдущем посте:

 

image007

Рис.7

 

По бедности у меня сейчас нет под рукой второй машины. Есть второй экземпляр SQL Server по имени POWERPIVOT на той же самой. На нем живут SharePoint, PowerPivot, Power View, все дела, и я еще создам пустую базу Northwind1_Pivot. Это будет Дубровский. Если бы экземпляры находились на разных машинах, на вторую тоже бы следовало установить Sync Agent, а в пределах одной я не уверен, что их может быть несколько. В FAQ говорится: Q: How many instances of the local agent UI can be run? - A. Only one instance of the UI can be run. Но то про юзер интерфейс. На всякий случай решил проверить. Выбираю Install a new Agent вместо использовать существующий:

 

image008

Рис.8

 

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

 

image009

Рис.9

 

image010

Рис.10

 

за исключением вот этого:

 

image011

Рис.11

 

Понятно, чем она недовольна. На Рис.10 внизу можно видеть, что окно относится к агенту Смит1, для которого ключ уже введен. Если бы можно было как-нибудь изменить в окне Рис.11 привязку к агенту Смит1 (Рис.7) на Бонд (Рис.9), но как? Если сейчас запустить инсталляцию бинарников агента, сетап обнаружит, что таковой уже стоит, и спросит: Repair? Uninstall? Похоже, все-таки нельзя иметь двух агентов на одной машине, но для очистки совести я еще спросил у авторов и получил окончательный ответ: One local sync agent is allowed in one box. You can register several databases you want in one local sync agent. Значит, в данном случае так и поступим. За все будет отвечать агент Смит1.

 

Возвращаемся на Рис.8 и выбираем Through an existing Agent:

 

image012

Рис.12

 

Аналогично Рис.17 предыдущего поста задаем строку соединения с новой настольной базой и регистрируем базу на агенте:

 

image013

Рис.13

 

Теперь на агенте зарегистрировано 2 настольных базы: Northwind1 (старая) и Northwind1_Pivot (новая).

image014

Рис.14

 

Добавляю новую базу в старую группу синхронизации. Чтобы она показалась в комбобоксе STEP 3 Select database, на STEP 2 справа надо нажать кнопку Get Database List. Теперь ее можно выбрать:

 

image015

Рис.15

 

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

 

image016

Рис.16

 

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

 

image017

Рис.17

 

 и, пошуршав, успокаиваются. Статус Synchronizing в верхней строке сменяется на Good:

 

image018

Рис.18

 

Схемы и данные из дупла (Northwind1_Azure) передались на Дубровского (Northwind1_Pivot). Со своей стороны, Дубровский пробует в них что-то изменить:

 

image019

Рис.19

 

Смотрим по журналу, что сейчас произойдет с его изменениями:

 

image020

Рис.20

 

Как можно видеть из журнала, в 10:28:08 3 изменения с Дубровского были положены в дупло. Узнать конкретно, что это были за изменения, из журнала в текущей версии нельзя. Здесь человек увидел в журнале, что столько-то failed и спросил, а как посмотреть, какие именно гавкнулись? Был дан ответ, что в настоящий момент никак, но this will be fixed in the near future and the failing rows will be identified with the PKs. For now, you will have to do a data diff between the source and destination DBs and identify the differences.

 

image021

Рис.21

 

Действительно, мы их сейчас видим в Northwind1_Azure:

 

image022

Рис.22

 

Проходит еще один 5-минутный интервал, заданный в расписании (Рис.21 предыдущего поста), и изменения Дубровского из дупла получает Маша:

 

image023

Рис.23

 

которая, в свою очередь, тоже вносит какие-то изменения. На некоторое время здесь пришлось отвлечься  и застопить сервис агента синхронизации Microsoft SQL Azure Data Sync (в интервале 10:31 -10:46) для наглядности, чтобы не переполнять журнал событиями. После внесения изменений запущен вновь.

 

image024

Рис.24

 

Изменения своим чередом отправляются в дупло:

 

image025

Рис.25

 

На Дубровском в этот момент пока ничего нового:

 

image026

Рис.26

 

Эти изменения дойдут до него через 5 мин. в следующую итерацию.

Можно пока посмотреть, как срабатывают триггеры Sync Framework в дупле:

 

image027

Рис.27

 

и что в действительности выполняется в промежуточной базе:

 

image028

Рис.28

 

Но вот проходят томительные 5 минут ожидания:

 

image029

Рис.29

 

и Дубровский забирает, наконец, из дупла весточку от Маши - запись с CategoryID = 9 удаляется. Молодец!

 

image030

Рис.30

 

Мы рассмотрели простейший пример дуплексной синхронизации двух баз данных, расположенных на традиционных SQL Serverах, через SQL Azure. К преимуществу такого сценария можно отнести гибкость - экземпляры SQL Server не обязаны видеть друг друга в пределах одной локальной сети или VPN. Все, что им требуется, это выход в Интернет. Ну и доступ к Облаку, само собой. Недостаток вытекает из ограничений облачной базы, которая выступает в роли концентратора. Поскольку на пути от одного SQL Server к другому данные оседают в облачной базе, они должны удовлетворять ограничениям SQL Azure.

 

Алексей Шуленин

 

Skip to main content