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

[Marik]

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

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

[S.Kuskov]

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

[Pustik]

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

[Marik]

Цитата:

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

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

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

[Marik]

Цитата:

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

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

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

[Pustik]

Цитата:

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

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

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

[S.Kuskov]

Цитата:

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

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

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

[Marik]

Цитата:

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

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

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

[Pustik]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

[Alexius]

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

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

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

[Pustik]

Цитата:

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

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

Если отчетов много, а нужно - то не проще.Можно постепенно переносить отчетность в SSRS, можно говорить о том, что это правильнее, но это не проще.

Цитата:

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

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

Т.е., Вы считаете, что отчеты изначально не грамотно построены? или SSRS имеет какие - то преимущества перед существующими отчетами в плане быстродействия? Если второе, то это конечно большой плюс.

Цитата:

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

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

С этим полностью согласен.

Цитата:

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

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

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

[Alexius]

Цитата:

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

Если отчетов много, а нужно - то не проще.Можно постепенно переносить отчетность в SSRS, можно говорить о том, что это правильнее, но это не проще.

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

Цитата:

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

Т.е., Вы считаете, что отчеты изначально не грамотно построены? или SSRS имеет какие - то преимущества перед существующими отчетами в плане быстродействия? Если второе, то это конечно большой плюс.

Более менее серьезные отчеты штатными ср-ми в АХ грамотно построить принципиально невозможно в виду гигантских ограничений языка запросов, поэтому построение отчетов прямыми запросами к серверу БД (использование SSRS частный случай) в большинстве случаев дает существенный прирост быстродействия.

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

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, а если пользователи будут продолжать работу, то может получиться лабуда, так как репликация уже работать не будет, пока структура таблиц разная, а отработает ли она, после того как таблицы будут приведены в соответствие большой вопрос, так как нагрузка на рабочую базу довольно большая, и за несколько часов работы в базе накапливается порядка полумиллиона транзакций, подлежащих репликации...

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

[Pustik]

Цитата:

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

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

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

[Alexius]

Цитата:

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

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

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

[Marik]

Цитата:

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

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

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

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

[Marik]

Цитата:

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

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

Каким образом копировать логику таблиц SQL? и синхронизировать её без репликации?

[EAlex]

Цитата:

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

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

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

[Pustik]

Цитата:

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

Каким образом копировать логику таблиц SQL? и синхронизировать её без репликации?

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

Цитата:

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

Актуальность данных нужна максимум с отставанием в пол часа.

то этот вариант Вам не подойдет.