Сложности обмена в РБД
Для получения доступа к форуму необходимо
авторизоваться
или
зарегистрироваться
на сайте.
Доступ к форуму партнерам «1C-Рарус» по дистрибуции предоставляется на сайте
rarus-soft.ru
Читают тему
Имеется АА ред. 4., релиз 15. Доработанная.
Проблема: нарушился обмен данными между подразделениями рбд.
Причина: были нарушены последовательности с 2010 года. С этого периода в базе наверное около 100 000 документов. В общем после восстановления последовательностей, файл обмена данными весит более 1,5 гига. И то это я запустил обмен на 12-ти ядерном серваке, продолжался трое суток, и я его прекратил... так бы наверное стол еще с месяц. На слабом сервере вообще через 3 часа пишет недостаточно памяти и закрывается все.
Вопрос: уважаемые гуру, как разбить процедуру обмена на несколько этапов?? Или как разбить файл?
Первый вопрос предпочтительнее, т.к. ждать неделю пока сформируется файл обмена не реально.
Или что посоветуете вообще?
Артем, все таки в данном случае мне кажется легче заного создать подчиненный узел,и не мучаться с переносом. А если есть возможность, вообще уйти от рбд, с ней вечно проблемы....
Ни один способ не гарантирует, к сожалению, более стабильного способа "соединения" удаленных подразделений. Интернет соединение по впи и единая база - не вариант, т.к. инет вечно скачет, может на сутки и более пропасть. На резервные каналы тоже нет особой надежды... да и потом надежные каналы связи стоят дорого...
Облака тоже не подходят, по той же причине + дорого
Больше вариантов я не вижу! Мне самому рбд не нравится, очень много заморочек с ней.
Я с РБД толком не знаком, но разве при восстановлении последовательностей необходимо заново переносить документы в подчиненную базу? Это вопрос к разработчикам. Мне кажется процесс востановления последовательностей не должен влиять на формирование файла обмена.
А мне наоборот, это кажется логичным. Ведь при перепроведении изменяется много вещей, в том числе и, нередко, сами документы. Поэтому подразделения должны обязательно их видеть.
Причина проблемы была в том, что специалист, контролирующий обмены ушел в отпуск, а замещающий его - забыл контролировать. А фтп-сервер, через которые шел обмен - остановился.
Была подобная проблема, файл обмена был около 2 Гб. Для того, чтобы прогнать все изменения в центральную базу - создавали дополнительный план обмена в конфигураторе, регистрировали в нем изменения документов порциями (например по 2000 документов) и производили обмен. Таким образом разгребли изменения и снизили файл обмена до приемлемых размеров. Потребовалось около недели работы специалиста имеющего опыт работы с планами обменов. После этого - вспомогательный план обмена - удалили.
Причина проблемы была в том, что специалист, контролирующий обмены ушел в отпуск, а замещающий его - забыл контролировать. А фтп-сервер, через которые шел обмен - остановился.
Очень сложный и дорогой вариант!
А как же все таки универсальный обмен XML? Вернее так - выгружаем все доки из периферии за период когда не было обмена. Удаляем подразделение в главной базе. Загружаем недостающие доки и регистры. Восстанавливаем последовательности. Создаем периферийную базу заново и вуаля! Все будет по прежнему... нет? НЕ получится?
Я где то видел опцию - разбивать файл обмена на части... но где не помню)) показалось?
Рарус ПОМОГИТЕ!
Я где то видел опцию - разбивать файл обмена на части... но где не помню))
Я где то видел опцию - разбивать файл обмена на части... но где не помню))
Он ни на что не влияет! Ставил и 1 и 10 и 50 и 1000 и 10 000 ... все тоже самое. Обмен висит трое суток и не доходит до конца!
Что делать??
Я где то видел опцию - разбивать файл обмена на части... но где не помню))
А что конкретно он подразумевает этот параметр?
Что касается ошибки загрузки надо понять причину ошибки. Надо попробовать в функции одОбменДанными.ПрочитатьСообщениеСИзменениями после вызова ПрочитатьСообщениеОбменаНаКлиенте/пвПривилегированныйМодуль.ПрочитатьСообщениеОбмена получить ошибку методом ОписаниеОшибки(). Может что то более понятное будет.
Что касается ошибки загрузки надо понять причину ошибки. Надо попробовать в функции одОбменДанными.ПрочитатьСообщениеСИзменениями после вызова ПрочитатьСообщениеОбменаНаКлиенте/пвПривилегирован ныйМодуль.ПрочитатьСообщениеОбмена получить ошибку методом ОписаниеОшибки(). Может что то более понятное будет.
Ошибок никаких нет. Просто файл обмена стал невероятно большим и все. Нет возможности его сформировать, т.к. процедура обмена продолжается несколько суток. Сообщение обмена становится более 2х Гб.
Вопрос в том, можно ли разбить файл обмена?
Или же, возможно сначала загрузить все документы из периферии, а потом вновь создать периферийную базу?
Пожалуйста, читайте сообщение #1 от 07.05.2013 10:07:25
1) Очищаем регистрацию изменений в периферийной базе для центральной базы методом: "УдалитьРегистрациюИзменений". При этом сохраняем в каталоге на диске файлы XML, каждый из которых содержит 1000 объектов, для которых очистили изменения.
2) По очереди регистрируем изменения для объектов, содержащихся в каждом XML-файле, полученном на этапе 1 и прогоняем обмен между всеми базами распределенки (чтобы не перебрать с накоплением изменений в центральной базе). После обработки каждого XML файла - он удаляется из каталога
Метод на практике не проверен, нужно проверить реализуемость, программировать, тестировать. Ну и если все нормально - разгребать 2 Гб.
Можно попробовать такой вариант:
1) Очищаем регистрацию изменений в периферийной базе для центральной базы методом: "УдалитьРегистрациюИзменений". При этом сохраняем в каталоге на диске файлы XML, каждый из которых содержит 1000 объектов, для которых очистили изменения.
2) По очереди регистрируем изменения для объектов, содержащихся в каждом XML-файле, полученном на этапе 1 и прогоняем обмен между всеми базами распределенки (чтобы не перебрать с накоплением изменений в центральной базе). После обработки каждого XML файла - он удаляется из каталога
Метод на практике не проверен, нужно проверить реализуемость, программировать, тестировать. Ну и если все нормально - разгребать 2 Гб.
Воспользовались советом и сделали так:
1. Удалили всю регистрацию изменений;
2. Зарегистрировали справочники в каждой базе по префиксам, прогнали по всем узлам, обменялись;
3. Зарегистрировали изменения по месяцу, начиная с дня когда остановился обмен, обменялись.
В итоге обмен восстановлен.
Минусы - некоторые справочники не зарегистрироли (как-то упустили их из виду), в результате в узлах теперь не видны к примеру пользователи-создатели, некоторая контактная информация и др. Пока других ошибок не замечено!
В итоге нескольких месяцев поиска, проблема решилась банально просто... если конечно не вылезут какие-то косяки в дальнейшем.