Репликация SQL баз 1С #587856

Заинтересовала репликация баз через механизмы SQL. Но сразу возникл вопрос по изменению конфигурации и реакция прежде всего на сервере приложения зеркала. Кт ал такие проблемы поделитесь опытом.

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

МУ-МУ самим написать тоже можно- но проще купить.

Очень дельный совет. Но попытка не пытка.Главное учесть все подводные камни. Эти тоже козленочками стали?

А сколько стоит? Чего то там не нашел. Или напрямую связаться?

Ты бы знал сколько на это сил ушло у них :)) Весь этот проект у местных старожилов на глазах происходил. Ну или по крайней мере у тех, кто с Кубани сюда переполз.

напрямую иключительно.

Спасибо.

Купить в пределах разумного непроблема. Ну так все движится все меняется с тех то пор.

SQL Базы, не 1С, для репликации нормально. Реплицировать 1С-е базы средствами sql server, на фоне штатных проблем, которые присутствуют в репликации обычных баз я бы не рискнул даж под дулом пистолета. Без спец навыков и средств первый же затык реплики может привести к полной ж..е

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

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

Рискни. Только вазелина купи. Мало ли что.

репликацию слиянием хочешь заюзать?

peer-to-peer интересная репликация. но там коллизии не разруливаются. в некоторых случаях можно ее использовать.

это ты по себе судишь. Моим мозгам другое питание нужно. да у меня не будет коллизий. Спасибо. Посмотрю.

А ка с изменением конфигураций. Она наверняка кэшируется на сервере. Решается ли это простым перезапуском службы?

ты всю базу что будешь реплицировать? перезапуск службы тут не причем. просто таблички участвующие в репликации меняются с помощью спец ХП, а не с помощью алтер табле.

что за обмен ты вообще хочешь этой репликацией реализовать? что куда ходить должно?

Я про другое. Про Спец ХП я уже прочитал. Я про изменение кода в конфигурации. Знаю, что она хранится в БД. Но как кэшируется на сервере приложений не знаю.

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

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

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

Я так и не понял что за обмен нужен. Что куда ходить должно.

Одна база для чтения. Вторая рабочая где все изменяется. Так понял, для такого варианта зеркалирование самый прстой способ

Не надо репликацию для этого. Зеркало или бекап-ресторе.

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

Зеркала я правда еще не настраивал. Хз как это работает в контексте 1С.

Тфю не то. Прошу прощения.

Слишком большой объем изменяемой информации, распределение нагрузки, т.к. одна база работает только на чтение и должна быть постоянная доступность, пусть это будет и некийоффлайн

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

Очень большой миллионы строк и нужен офф лайн. Даже можно включать эту базу при отказе основной в крайнем случае. П првости можно пойти и таким путем.

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

Спасибо. У меня есть еще месяц на раздумья. Заодно ознакомлюсь с различными видами репликаций и зеркалирования. Эта область для меня пока "практические" потемки одна теория.

2 есть четыре способа. :)

то есть

метка

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

путь в букварях... мне просто так совестно бывает цитировать оттуда. Как будто я считаю собеседника ну... умственно отсталым. Но если все-таки нужно, то вот:

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

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

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

при больших объемах будет долговато журнал накатывать после рестркутуризации.

в ДБ2 журнал - простой текстовый файл.. вернее набор.. который жмется... Но да. есть такой недостаток.

изменили тип реквизита. как при репликации в базе приемнике все пройдет?

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

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

Если под обновленим БД, подразумевалось обновление конфигурации БД, то я тем более ничего не путаю. Ибо обновление конфы разработчика, без дальнейшего обновления конфы БД не имеет смысла. В вопрос естестевенно в первую очередь касался конфигурации именно БД,

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

В штатном обновлении 1С есть один большой минус. Имена таблиц и полей у базы приемника будут отличными от базы источника. Это большой минус для всяких скульных обменов, репликаций и прочего.

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

по репликации вот полезная книга

Во большое спасибо. На выходных закажу почитаю.

2 там конкретно написано.. буквально с рецептами... ну еще и читай

Что скажете по Одноранговая репликация транзакций

вот чтобы мы ни сказали - она либо будет работать либо нет.. поэтому только провобовать

пробовать

В твоем случе лучше обратить внимание на репликацию моментальных снимков. Но я вот точно уже не помню будет она работать для 1С или там засада где то. Делать надо.

Спасибо. Разгребусь и займусь. Самому интересно для многих решений когда нужно передавать только изменения.

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

Вообщем задавай конкретные технические вопросы на все отвечу. Скрывать нечего.

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

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

в вашем решении как изменения конфы реплицируются?

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

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

полуавтомаом, но в штатном режиме? почему не стали делать обновление конфы средствами скуля?

имеется ввиду, обновление накатывается все таки платформой, или в обход нее?

закладка

я может что-то не понял, но зачем репликация? Если надо в одну базу писать, а из другой читать - есть намного более простые и удобные варианты: 1. Лог-шиппинг. Настраивается просто, сразу умеет делать вторую ("резервную") базу доступной для чтения. Возможный косяк - после перехода на "резервный" сервер, придется на "основном" базу восстанавливать из бэкапа, обратный переход не предусмотрен. Потеря данных, в случае аварии, может быть довольно большой - все бэкапы не доставленные на резервный сервер. Даже SQL Server 2000 его умеет делать. 2. Зеркалирование. Настраивается тоже довольно просто. С одинэсными базами работает отлично (с восьмеркой, по крайней мере, за семерку не уверен). Основная проблема в том, что нужен SQL Server Enterprise Edition, для того чтобы резервная база была доступна для чтения, поскольку это реализуется только через Snapshot (Standard этого не умеет). Потеря данных, при аварии, либо незначительна, либо отсутствует. После сбоя, возможно, придется "первую" (ранее основную) базу восстанавливать из бэкапа, но это зависит от того как прошел "переход" на резервную базу. - в этом треде Гладченко ее сам в открытый доступ выложил. Сейчас, вроде, хрен где ее уже закажешь.

Хм, интересно, а не обращаясь к СУБД, где база лежит можно ли решить вопрос в ? У некоторых могут быть разные СУБД

Нужна не копия базы, а объединение данных нескольких баз. Механизмы распределенной базы 1С не стыкуются с репликацией SQL.

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

как репликация связана с консолидацией?

1. Про объединение данных из нескольких баз ранее нигде не увидел, плохо смотрел, наверное. Тогда да, ни один из этих методов не подойдет. 2. Про репликацию в моем посте нет ни слова (:

Большое Спасибо. Посмотрю. Есть сайт и есть рабочая база. Склады, ТСД и прочяя лабуда с Wi-Fi, уже со своим софтом, который переделывать проблематично. Сайт работает в основном на чтение, (и читать он может из основной). А записывать будет в рабочую базу. Иногда нужно останавливать основной сервер. Но работа сайта должна 24/7. Кроме того основная база изменяется массовыми изменениями булками (не средсвами 1С).

Вернее булками создается темповая таблица, которая через Merge модифицирует таблицу 1С