Использование зеркалирования SQL2012 в режиме always on для 1С 8.2 #639168

Не раз спрашивали не используем ли мы зеркалирование SQL2012 в режиме always on для 1С 8.2.?  Основной интерес к этому решению в том что впервые появилась возможность реализации синхронного кластера (зеркала) и при этом база данных на зеркале находится в режиме read only. То есть ее можно реально использовать для отчетов при этом не только аналитических(в синхронном режиме). Недавно реализовали прототип , который активно тетсируем.Написал статью о этом решении, рассмотрел другие средства  кластеризации СУБД MSSQL с целью повышения масштабируемости ИТ систем.Ниже ссылка.

А как 1с (программа, не фирма) относится к базе в ридонли? Она туда ничего не пытается писать?

настройки отчетов - легко

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

и каковы накладные расходы в синхронном зеркале, да плюс балансировщик?

Зависит от конфигурации.

Ну тут можно обойтись и прямыми запросами.

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

нагрузка на изменение данных и на чтение отличается в 10-ки раз минимум а как правило соотношение 1 к 99-и мне почему то всегда казалось что наоборот. ибо запись и обновление это транзакции и блокировки. селекты своим количеством что ли берут?

Это распостраненное заблуждение. Это несложно проверить. У нас например есть прогламмулина которая по трассам MSSQL может четко посчитать сколько на чтение и сколько на изменение в конкретной БД.

Хорошо расписано. Разжевано для "тупых 1Сников" :)

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

Я так понимаю что это типа аналога Oracle RAC ? от MS ?

Это утверждение написано в контексте логшиппинга. Этот процесс означает по сути востановление бэкапа из журнала транзакций. Вы утверждаете что ваши админы каким то чудесным образом сделали во время этого процесса базы в readonly? Готов забиться на ящик пива что это не так.

Тем на самом деле для продвинутых одинэсников. На sql.ru к примеру уверен скажут что наоборот много воды, типа зачем итак понятные вещи расписывать.

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

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

Читаем вниммательно статью, там насчет этого расписано, разжевано.

а реструктуризацию как переносит такой межанизм ?

Да, вполне. В этом то его плюсы.

То есть по сравнению с репликацией над этим моентом не нужно особо париться.

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

2 ну, это разжевано и в How to became a Rock-Star DBA

Лучше проверить.

В том то логические нестыковки.Например, "И вроде я недавно в шипованную заходил, там были изменения ". Это утверждение совершенно не доказывает то что - вы могли в ЛЮБОЕ ВРЕМЯ(хотя бы после транзакции)  зайти в базу и увидеть изменения. Сколько я разных проспектов рекламных не читал , где только чего не пишут... А вообще вы видимо не поняли до конца суть проблемы. Проблема например в том что если у вас запрос выпролняется 30 минут - есть два варианта. Вариант один - выкинуть запрос.Вариант два- отложить на 30 минут обновление БД.

Data Cluster - очень громкое название, стоит поберечь для чего-нибудь более крутого, а этот продукт назвать SQL Mirror Router :)

У нас два продукта. Один действительно скорее примочка(адаптация) для always on и 1С 8.2 - его действительно можно назвать SQL Mirror Router(прокси) :) Второй продукт полностью самобытный - его разрабатываем не для 1С вовсе. Да и не только для MSSQL, в частности например для Mysql. Патент в стадии оформления.(с технологией уже все понятно, а вот бренды все в США заняты)

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

2 у меня просто нет этой проблемы, поэтому я даже не понял зачем мне ее понимать.

Специально сейчас проверил. Внес изменение в конфигурацию Primary базы, на сервере Праймери базы выполнил джоб в котором вызов "C:Program FilesMicrosoft SQL Server100ToolsBinnsqllogship.exe" -Backup 5BA0EBC7-53BC-4512-84F3-B4196DA85FA3 -server <ИмяПраймериСервера> На сервере Секондари базы выполнил доставку и накатку забэкапленного с праймери сервера лог-шиппинга. "C:Program FilesMicrosoft SQL Server100ToolsBinnsqllogship.exe" -Copy F43BDF9A-DC9C-4276-A835-30A2D6D147E8 -server <ИмяПраймериСервера> "C:Program FilesMicrosoft SQL Server100ToolsBinnsqllogship.exe" -Restore F43BDF9A-DC9C-4276-A835-30A2D6D147E8 -server <ИмяСекондариСервера> После этого зашел конфигуратором в эту базу и увидел все изменения принятые в рабочей (добавлены реквизиты в регистры, пару предопределенных элементов в справочник) Все на месте.

Абсолютно правильные утверждения. Где я утверждал обратное? А вот что я утвержал - Внесите изменения в базу, зайдите в базу зеркала и держите сессию, а лучше запустите запрос. В этот момент попытайтесь накатить бэкап очередного транзакшион лога не получится. То есть пока кто нибудь работает с базой зеркалом накатить изменения не получится. То есть рассинхронизация БД будет равна максимальному выполняемому запросу , к тому же в момент блокировки никто работать с ней не сможет. По другому говоря - если хотя бы один пользователь активный есть с БД зеркала - обновиться нельзя.Странно, я думал что  понятно в статье все объяснил.

Если вы соглачны с этим утверждением то я могу дальше обосновать что практического применения для масштабирования при таком условии нет. (для подавляющего большинства систем)

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

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

Я бы делил технологии скорее не на лог-шиппинг и зеркалирование, а для начала на синхронное и асинхронное. Причина - разные требования по прохождению транзакции. + я бы добавил в статью политику лицензирования. Емнип (по 2008 скулю) асинхронное зеркалирование на скуле стандарт не доступно, только на ентерпрайз. А это уже другая цена вопроса.

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