Re: multi-master replication limits

Rich Megginson <rmeggins@xxxxxxxxxx> · Mon, 17 Dec 2012 08:42:18 -0700



    On 12/16/2012 09:22 AM, Colin Tulloch wrote:
    
      
        Hi all – thanks for reading!
         
        We're planning a deployment of RHDS in our
          environment right now. We want to setup multi-mastering,
          however I'm confused by the "20 masters per replication
          scenario" limit that's in the Redhat documentation. There
          doesn’t seem to be any explanation around this limit that I
          can find.
      
    
    That's just the number of masters that Red Hat will support when you
    purchase RHDS from Red Hat.

    
    Technically, the limit on the number of masters is 65534.

    
    You will usually run into machine resource limits well before you
    set up 65534 replication agreements though.

    
        -         
            Each database (with one or more
          suffix assigned to it) seems to be what is considered as a
          "server" when it comes to replication scenarios - is that the
          case?
      
    
    No.

    
        -         
            Does this mean you are limited
          to 20 databases marked as Masters, in an instance of directory
          server?
      
    
    No.

    
        -         
            Or is it the limit 20 masters of
          a single database, spread across different instances of
          DS/machines?
      
    
    See above.

    
        -         
            How is this limit enforced, if
          it is? This part confuses me, the “limit” seems thrown into
          the documentation with no context.
      
    
    It's really only for Red Hat RHDS supportability, not for technical
    reasons.

    
        We can design the architecture to avoid
          ever worrying about the 20 database limit, but we’re concerned
          about storing a ton of directory information that is currently
          located in separate (different vendor) directory servers, all
          in a single RH/389 DS “database”. We might have some naming
          conflicts as well as policy constraints there as well – so
          we’re just trying to get a handle on the implications of
          scaling the architecture up.
         
         
        And how might all this apply different to
          389, if at all ?
      
    
    Can you be more specific?

    
        Colin Tulloch
        Colin.tulloch@xxxxxxxxxxx

            
      --
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
    
    
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users