[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Ref : Re: (ITS#4214) 2.3.12/2.3.11 syncrepl compatibility problem
This is a multipart message in MIME format.
--=_alternative 0051480CC12570C4_=
Content-Type: text/plain; charset="us-ascii"
Your explanation was very helpful.
The problem occures if I set the "syncrepl" block before "database
monitor"
It does not occur if I set the syncrepl block after the bdb block.
My replica config follows.
Best Regards
Ali Pouya
=============================
> #4 0x080c1d94 in monitor_back_modify (op=0xa38ddf50, rs=0xa38dda40) at
> modify.c:72
This error indicates that the monitor database in you replica is
erroneouslyu configured as a replica (i.e., I guess, a "updatedn"
directive is set) and someone is trying to write to it. This should be
impossible (that's the reason there's an assert(3)) and I believe there
used to be an earlier check at database startup which apparently has been
removed or didn't work. I'll fix it, but I think you need to fix your
configuration as well. Please provide details about your consumer (and
provider) configuration.
p.
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
--=_alternative 0051480CC12570C4_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">Your explanation was very helpful.</font>
<br>
<br><font size=2 face="sans-serif">The problem occures if I set the "syncrepl" block before "database monitor"</font>
<br><font size=2 face="sans-serif">It does not occur if I set the syncrepl block after the bdb block.</font>
<br>
<br><font size=2 face="sans-serif">My replica config follows.</font>
<br><font size=2 face="sans-serif">Best Regards</font>
<br><font size=2 face="sans-serif">Ali Pouya</font>
<br>
<br><font size=2 face="sans-serif">=============================<br>
</font><font size=2 face="Courier New">> #4 0x080c1d94 in monitor_back_modify (op=0xa38ddf50, rs=0xa38dda40) at<br>
> modify.c:72<br>
<br>
This error indicates that the monitor database in you replica is<br>
erroneouslyu configured as a replica (i.e., I guess, a "updatedn"<br>
directive is set) and someone is trying to write to it. This should be<br>
impossible (that's the reason there's an assert(3)) and I believe there<br>
used to be an earlier check at database startup which apparently has been<br>
removed or didn't work. I'll fix it, but I think you need to fix your<br>
configuration as well. Please provide details about your consumer (and<br>
provider) configuration.<br>
<br>
p.<br>
<br>
-- <br>
Pierangelo Masarati<br>
mailto:pierangelo.masarati@sys-net.it<br>
</font>
--=_alternative 0051480CC12570C4_=--