В прошлом посте мы использовали SQL Azure Data Sync для синхронизации между настольной Northwind1 и облачной Northwind1_Azureбазами данных, которые были включены в Sync Group по имени "группа захвата". Базы данных безоблачных экземпляров в пределах одной машины взаимодействуют со службой синхронизации данных через клиентского агента. Это сделано по соображениям безопасности, чтобы исключить взаимодействие с сервисом напрямую, к тому же базы могут (и должны) прятаться за файрволом. Единственно, что мне не нравится, это предупреждение, что срок действия агента истекает:
Рис.1
Если перейти в левой панели на агента, получается более развернутое сообщение:
Рис.2
Ссылка в сообщении указывает на http://www.microsoft.com/en-us/download/details.aspx?id=27693. Это странно. С того же места я его ставил пару дней назад, и номер версии (4.0.5.0) с тех пор не изменился. Тем не менее как дисциплинированный пользователь я расстался со старым проверенным агентом Смитом. Предварительно нужно разрегистрировать все зарегистрированные на нем (см.Открыть в полный размер' href="http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-58-84-metablogapi/0317.image_5F00_03CDB596.png" target=_blank style=color:white;>Открыть в полный размер' href="http://blogs.technet.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-58-84-metablogapi/0317.image_5F00_03CDB596.png" target=_blank>Рис.17 предыдущего поста) локальные базы:
Рис.3
Чтобы изменения отразились на портале Windows Azure Platform, следует нажать Refresh в верхнем меню:
Рис.4
Тогда Northwind пропадает из-под агента в левом дереве, и агента можно прикончить с помощью кнопки Remove из того же меню:
Рис.5
После чего по-новой запустил установку агента с приведенной ссылки, повторив шаги Рис.6 - 18 предыдущего поста. Смит1 установился, освоился и выкинул желтый треугольник совершенно аналогично (см.Рис.1) своему безвременно погибшему предшественнику. Что-то здесь не то, догадался я, и обратился к авторам этой замечательной проги. Ответили в том ключе, что сейчас агента менять не нужно, потому что нового они еще не доделали, а ссылка должна вести на страницу, разъясняющую что новый сервис (тот, который выйдет в июньском обновлении) будет несовместим со старой версией агента, но почему-то не ведет. Большое мне спасибо, что я это заметил. Высказав со своей стороны теплые слова в адрес аффторов, я забил на вопли агента и двинулся дальше.
Дальше нам предстоит добавить в существующую группу синхронизации еще одну настольную базу, которая будет синхронизироваться с первой настольной, а облачная будет играть роль посредника, или хаба. Если воспользоваться традиционными для такого рода примеров обозначениями, взятыми из повести Пушкина "Дубровский", то первая настольная база Northwind1 будет играть роль Маши, облачная база Northwind1_Azure - дупла, и еще нужно создать вторую настольную базу на роль Дубровского. Идем в ту же группу синхронизации, видим иконку, на которой написано Click to add a SQL Server database, и, натурально, кликаем:
Рис.6
Далее по накатанной дорожке, как проходили в предыдущем посте:
Рис.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 вместо использовать существующий:
Рис.8
Установку агента мы проходили в прошлом посте, и я в порядке закрепления дополнительно прошел ее уже в этом, поведясь на предупреждение, что старый истекает, поэтому описывать процесс установки еще раз не буду. Все, как обычно:
Рис.9
Рис.10
за исключением вот этого:
Рис.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:
Рис.12
Аналогично Рис.17 предыдущего поста задаем строку соединения с новой настольной базой и регистрируем базу на агенте:
Рис.13
Теперь на агенте зарегистрировано 2 настольных базы: Northwind1 (старая) и Northwind1_Pivot (новая).
Рис.14
Добавляю новую базу в старую группу синхронизации. Чтобы она показалась в комбобоксе STEP 3 Select database, на STEP 2 справа надо нажать кнопку Get Database List. Теперь ее можно выбрать:
Рис.15
В результате конфигурация синхронизации приобретает следующий вид:
Рис.16
После нажатия кнопки Deploy в верхнем меню (чтобы сохранить сделанные изменения на сервере синхронизации) вся эта байда приходит в движение. Точнее, не вся. Поскольку данные между Машей и дуплом еще с прошлого поста находятся в согласии, шуршат только дупло и Дубровский:
Рис.17
и, пошуршав, успокаиваются. Статус Synchronizing в верхней строке сменяется на Good:
Рис.18
Схемы и данные из дупла (Northwind1_Azure) передались на Дубровского (Northwind1_Pivot). Со своей стороны, Дубровский пробует в них что-то изменить:
Рис.19
Смотрим по журналу, что сейчас произойдет с его изменениями:
Рис.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.
Рис.21
Действительно, мы их сейчас видим в Northwind1_Azure:
Рис.22
Проходит еще один 5-минутный интервал, заданный в расписании (Рис.21 предыдущего поста), и изменения Дубровского из дупла получает Маша:
Рис.23
которая, в свою очередь, тоже вносит какие-то изменения. На некоторое время здесь пришлось отвлечься и застопить сервис агента синхронизации Microsoft SQL Azure Data Sync (в интервале 10:31 -10:46) для наглядности, чтобы не переполнять журнал событиями. После внесения изменений запущен вновь.
Рис.24
Изменения своим чередом отправляются в дупло:
Рис.25
На Дубровском в этот момент пока ничего нового:
Рис.26
Эти изменения дойдут до него через 5 мин. в следующую итерацию.
Можно пока посмотреть, как срабатывают триггеры Sync Framework в дупле:
Рис.27
и что в действительности выполняется в промежуточной базе:
Рис.28
Но вот проходят томительные 5 минут ожидания:
Рис.29
и Дубровский забирает, наконец, из дупла весточку от Маши - запись с CategoryID = 9 удаляется. Молодец!
Рис.30
Мы рассмотрели простейший пример дуплексной синхронизации двух баз данных, расположенных на традиционных SQL Serverах, через SQL Azure. К преимуществу такого сценария можно отнести гибкость - экземпляры SQL Server не обязаны видеть друг друга в пределах одной локальной сети или VPN. Все, что им требуется, это выход в Интернет. Ну и доступ к Облаку, само собой. Недостаток вытекает из ограничений облачной базы, которая выступает в роли концентратора. Поскольку на пути от одного SQL Server к другому данные оседают в облачной базе, они должны удовлетворять ограничениям SQL Azure.
Автор статьи: Алексей Шуленин.