master stops responding when slave cannot be updated

[brandon]

Okay, I don't know if this is the designed behaviour or not, but we have 
a single master server with one slave, and we shutdown the slave to 
rebuild it, but did not remove the replication agreement.  The master 
server stopped responding to queries after a period of time, and did not 
start servicing queries again until the slave came back online and it 
was able to complete its replication (read-only queries, nothing that 
should require changes).

Is this the designed behaviour?

Running

    389-ds-base-1.2.7.5-1 on the Master
    389-ds-base-1.3.3-1 on the Slave

On the master, there are a bunch of log messages about the Replication 
Manager getting TCP connection reset by pee, Consumer failed to replay 
change, and DSA is unwilling to perform.  These were expected, since the 
slave was down.  If it would help, I can digup those entries.

Thanks,

-Brandon

[Rich Megginson]

On 04/26/2011 12:46 PM, brandon wrote:
>  Okay, I don't know if this is the designed behaviour or not, but
> we have
>  a single master server with one slave, and we shutdown the slave to
>  rebuild it, but did not remove the replication agreement.  The master
>  server stopped responding to queries after a period of time, and did not
>  start servicing queries again until the slave came back online and it
>  was able to complete its replication (read-only queries, nothing that
>  should require changes).
>
>  Is this the designed behaviour? 
No.
>  Running
>
>       389-ds-base-1.2.7.5-1 on the Master
>       389-ds-base-1.3.3-1 on the Slave
>
>  On the master, there are a bunch of log messages about the Replication
>  Manager getting TCP connection reset by pee, Consumer failed to replay
>  change, and DSA is unwilling to perform.  These were expected, since the
>  slave was down.  If it would help, I can digup those entries. 
Sure.  Are there any
other errors?
Can you post excerpts from the master access log showing connection 
attempts from clients during this time?
>  Thanks,
>
>  -Brandon
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[brandon]

On 04/26/2011 12:52 PM, Rich Megginson wrote:
>  Sure.  Are there any other errors? 
I am still trying to quantify the problem, it may be bigger than I 
originally thought.  We have four slaves, one was down for service, the 
others were current, but all of them have failed and slapd is no longer 
running.  No logged messages to the slapd log, but there are sealert 
messages.

>  Can you post excerpts from the master access log showing connection 
>  attempts from clients during this time? 
Hmm, I will have to sanitize it.

-Brandon

[Rich Megginson]

On 04/26/2011 01:05 PM, brandon wrote:
>  On 04/26/2011 12:52 PM, Rich Megginson wrote:
> > Sure.  Are there any other errors?
>  I am still trying to quantify the problem, it may be bigger than I
>  originally thought.  We have four slaves, one was down for service, the
>  others were current, but all of them have failed and slapd is no longer
>  running.  No logged messages to the slapd log, but there are sealert
>  messages. 
Can you post the sealert messages?
> > Can you post excerpts from the master access log showing
> connection
> > attempts from clients during this time?
>  Hmm, I will have to sanitize it. 
Ok.  Please do.
>  -Brandon
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users