Conference azur::mcc

2135.0. "More DNS read-only replica problems" by ANOSWS::COMFORT (Spent a little time on the hill) Fri Jan 17 1992 10:09

	Hi,

	I am cross-posting this note in DNS and in DECmcc notes.

	Running version 1.1 of both DECmcc and DNS server.

        I have come across a failure that occurs during writes to DNS when
        using read-only replicas.  I have noticed the problem under two
        conditions so far, when reigstering a node for the first time and when
        creating a domain.  It appears that during the write operation, the
        read-only replica may be chosen to be the target DNS server node. 
        Often times, at least with domain creation, one receives an MCC error
        of operation failure, but the domain is actually created.  The catch is
        that any additional information such as user or directory
        specifications are not written.  Similarly, with node registration, if
        the read-only replica is the "first" or "target" DNS server, the
        registration completes, but without the circuits, lines, etc.  One then
        must register them as child entities in a separate step to be able to
        be recognized by the PA and Historian.  If the DNS target is the master
        replica, all information is registered first time, every time.

        My solution, as I had to do with the binary attributes skulk problem,
        is to lock the MCC node out of the read-only replica until I have
        populated the namespace.  Read issues from the read-only replica have
        been resolved by using the various patches.

        I do not know if this is an MCC error or a DNS error.   I thought that
        all writes would be directed to the master replica node, but it appears
        that DNS starts up a whole bunch of network processes if the node that
        receives the write request is the read-only replica.  I assume these
        processes should pass the write request on to the master replica, but
        not all information is being sent.

	Thanks for your attentions to the problem.

	Regards,

	Dave Comfort

    

    
    RE: .0
    
    In MCC V1.1, there have been a number of MCC DNS Errors in a multiple
    DNS Clearinghouses environment.  During registration process, the
    information written to the Master replica was not yet propagated to all 
    of its Read-Only replicas causing inconsistency in the Namespace as a 
    whole. This is an inheritant problem in distributed databases.
    
    The timing fix in MCC V1.1 was to retry to read upto 5 times with some
    delay when the expected information (single valued attributes) were not
    found. But this retry fix never guaranteed a read request being sent to the
    Master replica. In case of reading set valued attributes, the re-trial was
    not done at all because some cases expected no attributes to be found, and
    5 retries with some time delays in between were too costly.
    
    New fixes were made in April, 1991, and are in DECmcc V1.2.
    The new fixes are to retry ONCE with the Master replica immediately
    after the information is not found in Read-Only replica when reading both
    single-valued and set-valued attributes. With the new fixes, the timing 
    problems seemed to be eliminated. However, there is a cost for retrying to
    read a set valued attribute when the caller were expecting no attributes 
    to be  found.
    
    There exists a Kernel Patch for this problem (see MCC Notes
    1267.16-1267.18).  Please note that the patch is not the the most
    efficient implementation of the timing fixes, but does eliminates the 
    problem that the timing fixes in MCC V1.2 solve. (The patch was a
    short effective implementation of timing fixes - the patch involved
    a few lines of code changes whereas the timing fixes in V1.2 involved
    a several dozens lines of codes)