Репликация. Идеи, мысли, практика...

[Constantin A Chervonenko]

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

Эта галка очень оригинально влияет на интерпретацию групп в ACL при создании локальной реплики

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

А почитать тред в-зад?
Речь-то не о новом сервере, а о НОВЫХ документах для старого сёрвера, ранее ограниченных содержимым полей READERS

А пулл-ли-пуш репликация - совсем из другого города..

 

[VladSh]

Например, есть несколько десятков серверов и все они в одном домене.
Нужно чтобы определенного типа док-ты лежали на определенных серверах.
Док-ты создаются на любом сервере. При создании док-та, в зависимости от типа док-та,
в поле Ридерс записывается название некой группы серверов ServersGroup.
Соответственно в names.nsf имеется группа ServersGroup, содержащая определенные сервера.
При репликации, те сервера, которые указаны в ServersGroup, увидят док-т и соответственно на эти сервера док-т среплицируется.
Если в будущем потребуется добавить новый сервер, то просто добавляем его в ServersGroup и на него среплицируется всё что нужно.

Вроде для одного домена схема рабочая, но может возможны подводные камни..., кто что думает?

Рабочая.
Была ситуация, когда пытались выпхать документы с главного сервера на новый, они нормально отреплицировались, т.к. новый сервер был в одной из групп доступа на главном сервере, но после окончания сеанса репликации новый сервер, т.к. не имел доступа к этим документам (админ забыл поставить репликацию 2-й адресной книги, где и были эти группы), посчитал их хламом и удалил. При следующей репликации документы, естественно, были удалены на главном сервере... Благо были бэкапы.
Какие выводы:
1. Если на серверах используются общие АК, то прежде всего настраивать и проводить репликацию именно их; в документе настройки репликации указывать для этих баз самый высокий приоритет, чтобы репликация начиналась с них.
2. Если используются разные АК, то перед первой репликацией группы должны быть правильно настроены и всё должно быть выверено до мелочей.
И потом менять содержимое таких групп нужно очень осторожно, например, удалять оттуда имя сервера только если сервер реально "приказал долго жить" или "вышел из репликации" (например при расколе организации).

 

[Akupaka]

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

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

 

[VladSh]

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

Вообще-то да Но случилось то, что случилось. Прецедент был - запомнилось надолго.
Оба сервера были 6.5.4 (как оказалось глючнейшей версии трудно было найти))), оба под linux.
Ещё тогда глюк был, что в документе репликации указание папки не работало, нужно было указывать каждую БД, только тогда репликация стартовала...

 

[keen]

Я тут вспонил как устроена одна многобуквенная система в одной очень трёх буквенной компании:
Ситуация: много филиалов, серверов очень много, подчёркиваю их ОЧЕНЬ много они достаточно мощные (чего только стоят e25k)
Задача: обеспечить функционирование системы когда один рецензент Калиниграде, а другой на Сахалине. А ознакомиться должен кто-нибудь из Краснодара.
Решение: Разбили нашу необъятную на подрегионы. Внутри одного подрегиона стоит главный сервер на нём крутяться все доки, с местными представительствами настроена выборочная репликация. Адресная книжка общая на всю компанию. В Сталице нашей прекрасной стоит вообще непонятно что), но работает это следующим образом. С главного сервера подрегиона на сервер златоглавой идёт документация выгруженная в XML, а от туда на гл. сервер целевого подрегиона, оттуда же выборочной репликацией к конечному серверу.
Как я понимаю стоят серверные службы, которые изменения или документы целиком переводят в XML и передают между подрегионами, этакая над репликационная репликация.

 

[Kee_Keekkenen]

они б еще все по почте пересылали, но как говорится, кому и кобыла невеста..

 

[rinsk]

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

Дополнение - где то начиная с версии 6.х было замечено, что изменении АСЛ у базы приводит к полному сканированию ранее не реплицирумых документом... что меня в свое время порадовало.