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
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 SlaveOn 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org
-
brandon -
Rich Megginson