Репликация SQL на который смотрит АОС

[Marik]

Добрый день.
Ситуация следующая. Есть сервер приложений на котором установлен DAX 4, есть SQL сервер, на который смотрит АОС с сервера приложений. Задача заключается в том что бы поднять ещё один SQL сервер на который будет в реал тайме клонироваться информация с основного, для того что бы делать отчёты на резервном дабы разгрузить основной сервер.
Из всех видов репликации я выбрал одноранговую репликацию транзакций. И наткнулся на пару грабель:
первое, если одноранговая репликация включена не возможно что бы АОС работал с двух сторон, т.е. если я подключаю ещё один сервер приложений DAX 4 и настраиваю АОС на резервный SQL то он просто не ключается вываливая ошибку 100. но это не основная проблема.
вторая и наиболее важная проблема в том что при добавлении новых столбцов в таблицы, через интерфейс DAX репликация рушиться, так как она не может реплицировать структуру таблиц, и продолжить репликацию возможно только после восстановления базы из резервной копии с учётом внесенных столбцов в таблицы..

В общем суть вопроса в том, как настроить репликацию что бы она реплицировала так же и структуру таблиц. Так как восстановление баз из резервной копии процесс довольно долгий, база порядка 50 гигов..

[S.Kuskov]

Действительно ли так критична актуальность данных для сервера отчётов?
У нас используется репликация моментальных снимков. Для изменения структуры таблицы приходится временно убирать её из подписки. Так и живём

[Marik]

Цитата:

Сообщение от S.Kuskov

Действительно ли так критична актуальность данных для сервера отчётов?
У нас используется репликация моментальных снимков. Для изменения структуры таблицы приходится временно убирать её из подписки. Так и живём

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

[Pustik]

Если перед Вами поставлена такая задача, то кроме репликации транзакций, Вам нужна и репликация логики. Причем они друг с другом должны дружить.
В общей схеме это должно выглядеть так:
1)Копирование логики с основного сервера приложений на резервный.
2)Синхронизация логики(в Вашем случае таблиц) на резервном сервере приложений.
3)Репликация транзакций(данных) с основного SQL на резервный.

[Marik]

Цитата:

Сообщение от Pustik

Если перед Вами поставлена такая задача, то кроме репликации транзакций, Вам нужна и репликация логики. Причем они друг с другом должны дружить.
В общей схеме это должно выглядеть так:
1)Копирование логики с основного сервера приложений на резервный.
2)Синхронизация логики(в Вашем случае таблиц) на резервном сервере приложений.
3)Репликация транзакций(данных) с основного SQL на резервный.

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

[Pustik]

Цитата:

Сообщение от Marik

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

Можно настроить копирование и синхронизацию логики, например, ночью на каждый день в автоматическом режиме.(У нас это именно так и происходит). После завершения, средствами SQL отсинхронизировать транзакции, которые произошли за прошедший день.(Тут не уверен, но думаю, наверное можно это сделать).С утра у Вас и логика и данные на резервном сервере будут правдивы на это утро. Т.е. получите информацию в отчетах с погрешностью на сегодняшний день. Если только конечно ночью у Вас никто не работает. Но даже если это и так, то можно выделить необходимое время на проведение такой процедуры.
То, что хотите Вы - синхронизацию логики и данных в режиме онлайн, сделать если как-то и можно, но видимо с таким количеством извращений, что на ум ничего умного не приходит. И даже если это удастся сделать, то не исключены возникновения ошибок, потеря информация и т.д..

[Marik]

Цитата:

Сообщение от Pustik

Можно настроить копирование и синхронизацию логики, например, ночью на каждый день в автоматическом режиме.(У нас это именно так и происходит). После завершения, средствами SQL отсинхронизировать транзакции, которые произошли за прошедший день.(Тут не уверен, но думаю, наверное можно это сделать).С утра у Вас и логика и данные на резервном сервере будут правдивы на это утро. Т.е. получите информацию в отчетах с погрешностью на сегодняшний день. Если только конечно ночью у Вас никто не работает. Но даже если это и так, то можно выделить необходимое время на проведение такой процедуры.
То, что хотите Вы - синхронизацию логики и данных в режиме онлайн, сделать если как-то и можно, но видимо с таким количеством извращений, что на ум ничего умного не приходит. И даже если это удастся сделать, то не исключены возникновения ошибок, потеря информация и т.д..

Т.е. вы предлагаете востанавливать логику полным восстановлением базы данных?
Меня интересует как именно востановить структуру таблиц на резервном сервере?

[Pustik]

Цитата:

Сообщение от Marik

Т.е. вы предлагаете востанавливать логику полным восстановлением базы данных?

Нет, я предлагаю восстанавливать логику путем обыкновенного копирования папки приложений основного сервера(Application) на резервный сервер приложений.
Можно воспользоваться советом S.Kuskov :

Цитата:

Сообщение от S.Kuskov

Настроить оба AOSa на одно и тоже приложение (папку Application). И при изменении приложения через один из AOSов запускать обновление словаря и синхронизацию на другом AOSe.

Цитата:

Сообщение от Marik

Меня интересует как именно востановить структуру таблиц на резервном сервере?

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

[Alexius]

А не проще ли переписать отчеты через "прямые" SQL-запросы непосредственно из АХ, через SSRS или другой отчетник ? При грамотной реализации они будут выполнять значительно быстрее, нежели при варианте с копией.

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

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

[S.Kuskov]

Цитата:

Сообщение от Marik

А каким образом реализовать копирование логики, в моём случае структуры таблиц?

Способ. Настроить оба AOSa на одно и тоже приложение (папку Application). И при изменении приложения через один из AOSов запускать обновление словаря и синхронизацию на другом AOSe.
По-моему на форуме когда-то обсуждалась такая возможность...

[Михаил Андреев]

2 Marik:

Насколько важна актуальность данных и в каком режиме работает рабочее приложение (8х5 или 24х7)?

Если актуальность онлайн не нужна, а достаточно за вчерашний день, проблема решается довольно просто - копированием базы и приложения. Но если нужно онлайн, то, ИМХО, лучше воспользоваться советом Alexius - обращаться к таблицам для отчетов не из АХ, а напрямую. Сильно сервер SQL это загрузить не должно - он умеет грамотно распараллеливать загрузку (если, конечно, правильно настроена база).

[Marik]

Уважаемые участники форума, Спасибо за проявленную активность, если честно не ожидал. Очень приятно с Вами вести дискуссию.

А теперь по порядку.

Для отчётов используется ODBC и отчёты делаются напрямую с SQL сервера, в экселевских файлах, используя DSN.
Актуальность данных нужна максимум с отставанием в пол часа. База работает в основном 10х5 но бывает и 10х7 в зависимости от времени года и загруженности предприятия.

Цитата:

Сообщение от S.Kuskov

Способ. Настроить оба AOSa на одно и тоже приложение (папку Application). И при изменении приложения через один из AOSов запускать обновление словаря и синхронизацию на другом AOSe.
По-моему на форуме когда-то обсуждалась такая возможность...

не получится так сделать так как я имел ввиду что второй АОС на отдельной машине. Т.е. Архитектура такая:
Сервер приложений АХ + SQL сервер
Резервный сервер приложений АХ + Резервный SQL сервер.
На резервном сервере приложений если включена одноранговая репликация АОС не стартует (ошибка 100 ), только если отключить АОС на основном сервере, тогда запускается. Но это не особо принципиально. Так как задача состоит в том что бы был Зеркальный сервер SQL, и в случае падения основного сервера можно было бы переключить АОС сервера приложений на резервную базу SQL.
поэтому предложение:

Цитата:

Сообщение от Alexius

А не проще ли переписать отчеты через "прямые" SQL-запросы непосредственно из АХ, через SSRS или другой отчетник ? При грамотной реализации они будут выполнять значительно быстрее, нежели при варианте с копией.
Если уж очень хочется реплицировать, то определите список таблиц, требуемых для ваших отчетов и гоняйте только его. Если перетаскивать все таблицы, то можно нарваться на системные, которые изменяются даже при запуске и выполнении отчетов, например SysLastValue.
Если в них просходит изменение структуры, то придется переливать полный бэкап, для 50Гб это должно занять в районе получаса на нормальном железе.

мне не подходит. Так как нужна актуализированная версия БД со всеми существующими таблицами. Плюс ко всему время от времени новые столбцы появляются и тех таблицах которые используются для отчётов, поэтому нельзя выделить определённые таблицы и только их реплицировать.

Цитата:

Сообщение от Alexius

А не проще ли переписать отчеты через "прямые" SQL-запросы непосредственно из АХ, через SSRS или другой отчетник ? При грамотной реализации они будут выполнять значительно быстрее, нежели при варианте с копией.

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

Интересно а если на моём сервере приложений поднять ещё одни АОС который будет смотреть на Резервный сервер SQL, и вносить изменения столбцов сначала через один АОС, потом его останавливать, запускать второй АОС который смотрит на резервный SQL и дублировать изменения, а потом возвращаться обратно, то получается структура таблиц сначала изменится в основной базе, репликация отвалится, но будет повторят попытки, пока базы не будут соответствовать друг другу, потом структура таблиц меняется на резервном сервере, репликация должна подняться если они придут в соответствие. Но в этом способе явно задваивание работы, по внесению столбцов, и что более важно это нужно делать в не рабочее время, так как нужно отключать АОС основного сервера, что бы запустить АОС который будет смотреть на резервный SQL, а если пользователи будут продолжать работу, то может получиться лабуда, так как репликация уже работать не будет, пока структура таблиц разная, а отработает ли она, после того как таблицы будут приведены в соответствие большой вопрос, так как нагрузка на рабочую базу довольно большая, и за несколько часов работы в базе накапливается порядка полумиллиона транзакций, подлежащих репликации...

В общем вопрос репликации структуры таблиц остаётся открытым.

[Alexius]

Цитата:

Сообщение от Marik

Для отчётов используется ODBC и отчёты делаются напрямую с SQL сервера, в экселевских файлах, используя DSN. ... Так как задача состоит в том что бы был Зеркальный сервер SQL, и в случае падения основного сервера можно было бы переключить АОС сервера приложений на резервную базу SQL.

На основании вышеизложенного я не понимаю зачем нужно запускать АОС для копии при работающем основном. Если требуется перенести выполнение отчетов на другой сервер, то достаточно изменить настройки соединения. Для резервного восстановления работы при падении основного сервера БД, нужно просто отключить репликацию и перенастроить АОС либо выключить основной и поднять резервный. Все это проделывается руками или скриптами. В чем засада ?

[Marik]

Цитата:

Сообщение от Alexius

На основании вышеизложенного я не понимаю зачем нужно запускать АОС для копии при работающем основном. Если требуется перенести выполнение отчетов на другой сервер, то достаточно изменить настройки соединения. Для резервного восстановления работы при падении основного сервера БД, нужно просто отключить репликацию и перенастроить АОС либо выключить основной и поднять резервный. Все это проделывается руками или скриптами. В чем засада ?

да в этом и нет засады. с этим то всё понятно. АОС запускать что бы внести столбцы в таблицы в резервной БД, но это двойная работа, и не возможность работы пользователей пока вносятся изменения.

Вопрос в том как поддерживать актуализированную копию БД при одноранговой репликации? т.к. в основную базу через интерфейс АХ вносятся новые столбцы в таблицы, а они то и не реплицируются. Репликация перестаёт функционировать, потому что структура таблиц не соответствуют друг другу.

[Владимир Максимов]

То, что Вы так хотели услышать, но никто внятно не произнес

Цитата:

Сообщение от Marik

Вопрос в том как поддерживать актуализированную копию БД при одноранговой репликации? т.к. в основную базу через интерфейс АХ вносятся новые столбцы в таблицы, а они то и не реплицируются. Репликация перестаёт функционировать, потому что структура таблиц не соответствуют друг другу.

Никак. При помощи репликации - это невозможно "в принципе". По нескольким причинам

1. Часть информации, которую надо "реплицировать" в случае изменения структуры данных физически отстуствует в базе данных. Это само приложение Axapta с описанием структуры таблиц.

Т.е. даже если Вы сможете модифицировать структуру в копии базы данных, то при этом "сломаете" уже копию собственно приложения Axapta.

2. Если речь идте об MS SQL, то физически репликация реализуется через триггера, которые "вешаются" на соответствующие таблицы. Но запуск синхронизации в Axapta при изменении структуры таблицы автоматически отключит все триггера. Т.е. по сути, выключит репликацию.

======================================================

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

1. Отключить (остановить) репликацию
2. Вручную накатить изменения в первой копии Axapta
3. Вручную накатить изменения во второй копии Axapta
4. Заново настроить репликацию (запустить процесс создания триггеров)

======================================================

PS: "Что-то в консерватории надо подправить" (с). У Вас методологическая ошибка. Неправильно организован сам процесс. Впрочем, о разных вариантах Вам уже рассказали.

[AndyD]

Цитата:

Сообщение от Владимир Максимов

2. Если речь идте об MS SQL, то физически репликация реализуется через триггера, которые "вешаются" на соответствующие таблицы. Но запуск синхронизации в Axapta при изменении структуры таблицы автоматически отключит все триггера. Т.е. по сути, выключит репликацию.

Это точно не про MS SQL
В нем репликация транзакций делается по журналу транзакций (с помощью Log Reader Agent).

[EAlex]

Цитата:

Сообщение от Marik

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

У Вас новые столбцы добавляются onLine на рабочем приложении? Если так, то проблема не техническая, а методологическая. Может, лучше 1 раз в сутки, когда никто не работает, переносить приложение и синхронизировать таблицы на резервном сервере (тем самым обеспечив одинаковую стрктуру данных), а в течение дня производить репликацию, не трогая структуру данных. Ну а добавление новых столбцов проводить в конце рабочего дня.

[Индра]

> Для отчётов используется ODBC и отчёты делаются напрямую с SQL сервера, в экселевских файлах, используя DSN. Актуальность данных нужна максимум с отставанием в пол часа. База работает в основном 10х5 но бывает и 10х7 в зависимости от времени года и загруженности предприятия.

Ровно по этой схеме живем уже больше года. Но у нас на зеркало реплицируются только избранные таблицы (около сотни), естественно - на зеркале нельзя запустить аксапту, да и не нужно. Изменения структуры таблиц не проводятся каждый день, и тем более не происходят в разгар рабочего дня. Загрузки проектов осуществляются поздно вечером или ночью - выгоняются юзеры, компилируются проекты, далее запускается пересоздание зеркала.

Я сам воевал за полную копию БД, но админ меня буквально принудил составить фиксированный список таблиц, за что я ему теперь очень благодарен, так как он-лайн репликация того же sysdatabaselog - очень веселое и бесполезное занятие.

[gl00mie]

Цитата:

Сообщение от Marik

Ситуация следующая. Есть сервер приложений на котором установлен DAX 4, есть SQL сервер, на который смотрит АОС с сервера приложений. Задача заключается в том что бы поднять ещё один SQL сервер на который будет в реал тайме клонироваться информация с основного, для того что бы делать отчёты на резервном дабы разгрузить основной сервер.

Немного о поддерживаемых способах репликации написано в заметке Transactional Replication with AX 2009

Цитата:

Сообщение от S.Kuskov

Способ. Настроить оба AOSa на одно и тоже приложение (папку Application). И при изменении приложения через один из AOSов запускать обновление словаря и синхронизацию на другом AOSe.

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

Цитата:

Сообщение от Владимир Максимов

Если речь идте об MS SQL, то физически репликация реализуется через триггера, которые "вешаются" на соответствующие таблицы. Но запуск синхронизации в Axapta при изменении структуры таблицы автоматически отключит все триггера. Т.е. по сути, выключит репликацию.

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

Цитата:

Сообщение от Индра

Я сам воевал за полную копию БД, но админ меня буквально принудил составить фиксированный список таблиц, за что я ему теперь очень благодарен, так как он-лайн репликация того же sysdatabaselog - очень веселое и бесполезное занятие.

+1. Вообще, если отчеты создаются прямыми SQL-запросами и не переписываются каждый раз, когда меняется схема данных рабочей базы (мало ли, нафиг в отчетах нужны все новые столбцы?), то непонятно, зачем нужно реплицировать базу 1-в-1. В моем случае отчетность строится в кубах, туда периодически забираются данные из нужных транзакционных/справочных таблиц, на последних просто везде включено поле modifiedDataTime и сделаны индексы по нему, за счет чего можно быстро выбрать измененные и новые данные. Каждую ночь выгружаются изменения за день (это занимает буквально минут 10-15 при базе на порядок больше упомянутых 50-и гигов), на выходных идет полная перекачка. Если нужны данные максимум получасовой давности, так можно и перекачку запускать раз в полчаса - и выкачивать только те столбцы только тех таблиц, которые реально используются в отчетах, а не все подряд. При настроенных индексах все это проходить будет достаточно быстро.

[AndyD]

Цитата:

Сообщение от Marik

В общем суть вопроса в том, как настроить репликацию что бы она реплицировала так же и структуру таблиц. Так как восстановление баз из резервной копии процесс довольно долгий, база порядка 50 гигов..

А какая версия SQL сервера у вас используется?
В 2008-м ALTER TABLE умеет реплицироваться точно. Судя по документации, 2005-й тоже
Другой вопрос, а использует ли DAX4 эту команду для изменения метаданных?

Насчет размера базы и восстановления из бэкапа.
Можно включить на базе режим восстановления FULL и использовать Log Shipping - все зависит от объема изменений, но, думаю, раз в десять-пятнадцить минут актуализировать данные можно будет. Как минус - на момент заливки бэкапа база будет недоступна

Также, если у вас используется Enterprise версия SQL, то можно настроить зеркалирование и создать Database snapshot.
Если зеркалирование делается в синхронном режиме, то на втором сервере всегда будут актуальные данные.
Достучаться до них можно будет через Snapshot, но так как он показывает срез данных на момент своего создания (которое выполняется очень быстро), то придется периодически его пересоздавать