During bulk updates, a DSA might receive more updates than it can send over the slow link between the groups when replicating between multiwrite groups. If the DSA continues to receive more updates, the multiwrite queue for the asynchronous peer slowly builds up. The asynchronous peer slows down because updates are added more quickly than they are removed.
As the queue builds up, it consumes more memory, which can cause machine memory limitations or can exceed the multiwrite queue size. To avoid this problem, use the set multi-write-group-credit command to set an acceptable number of updates for the multiwrite queue.
When the number of queued updates exceeds the limit you have set, the DSA switches to the synchronous multiwrite. In this mode, the DSA sends confirmation to the client after its peers have sent confirmation to it. This confirmation slows the rate at which updates are accepted, giving the queue time to empty. When the queue is smaller than the limit you set, the DSA switches back to the asynchronous multiwrite.
If the DSA is receiving the bulk updates from a client, then you cannot limit the size of the queue. When a client sends batch updates, it does not wait for confirmation from the DSA. In this situation, the set multi-write-group-credit command has no effect.
To limit the size of queues between groups
|
Copyright © 2013 CA.
All rights reserved.
|
|