Red Hat DIRECTORY SERVER 7.1 SP7 - S Guía para resolver problemas descargar pdf (Pagina 58)

58 Novell eDirectory 8.8 SP7 Troubleshooting Guide

9.4.2 Previous Practices

In the past, several different strategies have been employed to resolve stuck obituaries. Some of these

strategies involve expensive partitioning operations, or the use of undocumented features that might

cause problems in the future.

The first strategy was to switch which replica held the master. This would work in some cases

because the master is the agent responsible for moving the Back Link obituaries through their various

states. In the case where the replica was inconsistent and the master didn't hold the deleted object,

switching masters to an agent that held the deleted entry with its obituaries would give the new

agent the license to push the obituaries through their states and eventually purge it out. Send Single

Entry is a much cleaner and less dangerous way to resolve obituaries that are stuck because the

replica is inconsistent.

The second strategy used was to run DSRepair with certain switches to delete all obituaries. (There is

a third-party application which resolves stuck obituaries by launching DSRepair.) We do not

recommend this strategy. Using those switches will delete all obituaries on this agent, which means

that obituaries that are not stuck might also be removed, creating further replica inconsistencies and

more stuck obituaries. Because this is not a distributed operation, you must run DSRepair on all of

the servers with stuck obituaries, which increases the odds that one of those servers has obituaries for

another partition which will be prematurely deleted. The premature deletion of obituaries can cause

additional orphaned obituaries and, in turn, cause problems which can be found years later when

you change replicas types, add new replicas, or perform other partitioning operations.

The third strategy used was to make objects authoritative, either using DSBrowse with the advanced

mode operation and time stamping the entry, or running DSRepair with the -0T switch. This forces

the entry to become authoritative and synchronize out to all other replicas. This should be done with

great care because you might lose data changed on other servers. We recommend that this be a rarely

employed method of obituary cleanup.

1 2 ... 53 54 55 56 57 58 59 60 61 62 63 ... 119 120

Sin comentarios

Red Hat DIRECTORY SERVER 7.1 SP7 - S Guía para resolver problemas Pagina 58