[389-users] Multimaster replication

[Rich Megginson]

Juan Asensio Sánchez wrote:
> Hi
>
> Thanks for the answer. Now we have more than fifty servers (more than
> twenty organizations, each with at least two servers), each one with
> about the same number of replication agreements, and we are not having
> any problems about resource limits. Each server has its own database
> in multimaster mode and the databases of the other organizations in
> hub mode. We thought there were a limit of four (4) servers per
> multimaster replica;
That is a limit only in the Red Hat Directory Server product.  The 
support referred to there is an issue of machines required to diagnose 
problems and answer questions, not an issue in the code.
> the biggest organization will have now 6 servers,
> each one with the replica of its database in multimaster mode, so
> that's my question.
>
> Anyone has multimaster replicas with such number of servers? Any suggestions?
>
> Regards.
>
> 2009/10/20 Rich Megginson <rmeggins at redhat.com>:
>   
>> Juan Asensio Sánchez wrote:
>>     
>>> Hi
>>>
>>> Has 389DS any limit of servers for multimaster replication? If so,
>>> what is the best option to have any number of servers with read/write
>>> databases and replication agreements among them?
>>>
>>>       
>> The upper limit on the number of replicas is 65534 - we use a short integer
>> field for the master replica ID.
>> However, long before that, you will likely run into resource limits.  For
>> example, each replication agreement uses at least one thread and sometimes
>> two.  This will use memory and CPU resources.
>>     
>>> Regards.
>>>
>>> --
>>>       
>
> --
> 389 users mailing list
> 389-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20091020/214480e6/attachment.bin>