Более, чем одна Master-реплика в одном дереве.

[Андрей Добров]

Более, чем одна Master-реплика в одном дереве.
Но для разных разделов дерева.
Возможно ли? И если возможно насколько правильно такое решение?

[Андрей Фисенко]

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

[Андрей Добров]

Тогда вроде делаю правильно, но появился странный казус.
Решился на территориально разнесённые обьекты сделать раздел в eDirectoty для конкретного OU. Как бы говорят по науке всё.
Сделал, назначил Master на сервера удалённо стоящие но находящиеся в этих OU.
И как бы всё работает, и нет проблем с логином, что ранее бывало.
Но .... но так сложилось сменили железку и не только сменили но замена была и имени сервера. Ранее на предыдущем сервере лежала реплика R-W. Что-ж решил и на на новом поднять. И пошло поехало, на всех других созданных разделах появилась подчиненная ссылка на новый сервер.
Стоит сейчас на любой сервер положить реплику как тут же на всех других разделах появляется подчиненная ссылка. Правильно ли это?
В чём засада и почему ранее такого не было.
И наверно как от этого избавиться?

[Павел Гарбар]

Перед удалением сервера с него надо было убрать реплику штатным образом, если она была главной (master), то надо было предварительно назначить главной другую реплику этого же раздела (partition). Потом можно было ставить новый сервер и класть на него нужную тебе реплику. Если ты делал не так, то теперь тебе надо почистить дерево от хвостов старого сервера. Для этого есть несколько TID'ов.
Subordinate reference - специальный тип реплики, а не ссылка на сервер. Создаются и удаляются они автоматически при определенных комбинациях разных реплик на одном сервере. Трогать их не надо.

[Андрей Добров]

Т.е. всё как полагается и реплику сняли и службы его перевели на другие сервера. С этим всё Ok.
Что напрягает - ранее такого не происходило!!! А тут, на тебе.
Каюсь, не правильно выразился. Тип реплики - "подчинненая ссылка".

[Андрей Фисенко]

Вот цитата из первоисточника Course 3067 - Novell eDirectory 8.8 Design & Implementation:
Subordinate Reference
Subordinate reference (SR) replicas are system-generated replicas that don't contain all the object data of a master or a R/W replica.
SR replicas, therefore, don't provide fault tolerance.
They are internal pointers that are generated to contain enough information for eDirectory to resolve object names across partition boundaries.
You can't delete an SR replica; eDirectory deletes it automatically when it is not needed. SR replicas are created only on servers that hold a replica of a parent partition but no replicas of its child partitions.
If a replica of the child partition is copied to a server holding the replica of the parent, the SR replica is automatically deleted.
They contain only the partition root object. They only exist to provide a link between the parent partition and its child partition.
eDirectory creates an SR replica on a server when the server holds a real parent partition and but does not hold a real child partition of that parent partition.
------------------
Real refers to a Master, Read/Write, Read-Only, or filtered replica. An SR replica is not a real replica.
------------------
When you define the partitions and replicas for your tree, consider a strategy that minimizes SR replicas showing up in your tree. This is, however, more of guideline than a hard and fast rule because SR replicas are handled better in current versions of eDirectory.
As a rule of thumb, when a parent partition is placed as a replica on a server, a replica of the child partition exists automatically as a SR unless you have identified it as another type of replica, as shown in the following:

To minimize SRs, you need to understand why they automatically appear in certain locations:
■ When a parent partition is placed as a replica on a server, eDirectory automatically places SRs on that server connecting the parent partition to its child partitions. An SR is not placed to connect to its grandchild partitions. Figure 4-4 shows 3 partitions under a parent partition.
■ An SR replica will not show up if a replica of the (R/W or R-O) child partition exists on the same server as the replica of the parent partition.
■ Replicas of child partitions do not require a replica of the parent partition.
Because SRs are copies of partition root objects, they hold the replica attribute, which is a list of servers that are in the replica list. eDirectory uses this list to locate replicas of other servers who hold replicas of the partition for tree walking purposes.