Всем привет! Подскажите как настроить . Есть 3 филиала , центральный сервер терминальный сервер 1С с базой SQL, vpn настроен между филиалами на уровне провайдера. Но периодически у провайдера происходят сбои, раз было 2 дня связи, периодически от 30 минут до 3 часов, и стоит задача обеспечить работу филиалов во время обрывов связи с главным сервером. Кластер 1С и кластер SQL замороченно делать, да и связь с хранилищем с схд оборвется при обрыве с центральным офисом.
Поэтому пока для тестов создал 1С сервер с SQL, SQL раз в 12 часов с схд в центральном офисе восстанавливает копию базы. В менеджере 1CV8 сервера добавил дополнительный сервер 1С и в клиенте для филиала настроено подключение к 2 серверам. при обрыве связи клиент 1С перегружается и работает с доп. сервера.
Вопрос подскажите как настроить синхронизацию баз, после того как восстановится связь после обрыва, так как в центральном офисе изменится база 1С и в филиале изменится?

РИБ

(1)+ В место тысячи слов ))

РИБ это не наш метод

аминь

Может зеркалирование sql или резервный провайдер

или вот https://docs.google.com/file/d/0B5YZFVgmFfcwRnZZNlhZTnpEcVE/edit?pli=1

(0) риб для слабоков. рдп тоже да?

База большая, риб заморочено, много коллизий, как бы желательно на уровне Субд сделать. Как на SQL настроить синхронизацию двух баз, если обе базы изменялись ?

Зеркалирование не подходит так как 3 сервера 1С и базы на всех изменятюся при обрыве связи, а при зеркалирование  одна база рабочая вторая в режиме чтения. По ссылке  https://docs.google.com/file/d/0B5YZFVgmFfcwRnZZNlhZTnpEcVE/edit?pli=1 указана настройка двух серверов 1С с одной базой MS SQL при обрыве, филиалу не будет доступна база MS SQL.

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

(0)
1.РБД
2.РДП (+резерв какнал)
3.Тонкий(Веб) клиент

всё остальное от лукавого

Веб-клиент

все отстальное бесовщина

фраза после которой улвольняют в хороших конторах

"Кластер 1С и кластер SQL замороченно делать"

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

Кластер SQL использует внешнее хранилище, у нас одна схд в центральном офисе, при отключении связи кластер SQL потеряет связь с хранилищем.

Кун-фу с SQL базами должно помочь, только как настроить репликации ?

(16) от коллизий точно не поможет это.

Взял за основу http://niios.ru/docs/Kurilenko/design_lab9_sample.pdf и настроил репликации слиянием только.

(16)
классическая репликация работать будет
но реструктуризацию субд сделать не даст.
т.к. при реструктуризации 1с8 пере создает таблицы, а субд не даст удалять таблицы, участвующие в репликации.

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

(18) Надейся теперь, что назад всё вернуть не попросят. ))

+19

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

Ждем ветки "Как починить базу?".

Почему бы не настроить базы РИБ точно так же "в режиме ожидания"? Когда связи нет - филиалы переключаются на эти базы и работают там.

Реструктуризацию в 1С не используем, все настроено на уровне СУБД в плане обслуживания

пусть работаю через РДП в центре, а в своем локальном РИБ-узле при обрыве. Обмен пусть будет раз в 5 минут

Либо РИБ либо одна база с резервным каналом связи!!!
Третьего не дано.
Все остальное садо -маза и изобретение великов!!!

(0) РДП+резервный канал! Смысл других телодвижений вообще не ясен..

(25) ошибаетеся есть и "третье" и "четвертое"
пример :
http://www.softpoint.ru/products_id28.htm

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

(27) Я имел виду стандартные вещи. То что софтпоинт предлагает это уже не обычные методы.

(27) Наверняка есть даже "пятое" и "шестое", на нафига эти мучения?

(25) +1, все к этому приходят))

(27) в вашей же ссылке - http://www.softpoint.ru/info_id147.htm , понимаю что работать будет но и коллизии будут))

(0)
мучения - для незнающих.

но учитывая, что 1с сильна наличием тьмы мало квалифицированных но доступных специалистов( так называемых 1с -ников), при выборе метода доступности ИБ и актуальности данных нужно рассчитывать на то, кто будет поддерживать работоспособность.

(30)
каллизии бывают и в рамках работы  пользователей 1 субд.
а для распределенных баз - обычное явление.

коллизии бываю при всех типах репликаций.

Есть простые правила.
1. Если хотят единую  базу и при этом всегда быть в онлайне то нужно железобетонный канал связи. А это очень сложно в наших реалиях СНГ. Может быть в пределах одного города еще можно но а если разные города и разные области? И не да бог вне городов.
2. Если в бизнесе критичны простои  которые измеряются минутами и учитывая 1й п. следует РИБ делать.
3. Если критичность простоев измерятеся часами то с резервным каналом можно делать одну базу.

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

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

(35) +1 Со времен 1с77 дружу с рибом. Еще лучше ничего не придумано. Думаю все зависит от прокладки кто пишет РИБ.

(36) Да тут даже писать ничего не надо - тупой полный обмен между идентичными базами.