On Thu, Oct 12, 2017 at 05:38:32PM +0200, Patrik Lundin wrote:
> On 2017-10-06 10:03:37, Nico Williams wrote:
> > Trungcating the log is not the same thing as resetting it, and preserves
> > the version number.
>
> To summarize this tread: The --reset flag should currently not be used
> in a
On 2017-10-06 10:03:37, Nico Williams wrote:
> Trungcating the log is not the same thing as resetting it, and preserves
> the version number.
To summarize this tread: The --reset flag should currently not be used
in a production systems since ipropd-master is unable to parse the
resulting log
On Mon, Oct 9, 2017 at 3:40 PM Nico Williams wrote:
> On Mon, Oct 9, 2017 at 3:19 AM Harald Barth wrote:
>
>>
>> Have I got this right?
>>
>> 1. Does write_dump(context, s, database, current_version) always write
>> a comptele dump no matter the value of
On Mon, Oct 9, 2017 at 3:19 AM Harald Barth wrote:
>
> Have I got this right?
>
> 1. Does write_dump(context, s, database, current_version) always write
> a comptele dump no matter the value of current_version?
>
> 2. Does write_dump(context, s, database, current_version) only use
>
Have I got this right?
1. Does write_dump(context, s, database, current_version) always write
a comptele dump no matter the value of current_version?
2. Does write_dump(context, s, database, current_version) only use
current_version to set the version of the dump?
3. I's named "send_complete",
On thing that’s conspicuously missing from this discussion is any historical
context for how the version numbers are *supposed* to be handled. It seems like
most of these problems are recent, or at least recent-ish.
IIUC the deal is (should be? used to be? Please correct!):
1) On initial
We're going to revisit the when-to-send_complete() logic. We've had one
case where a slave was stuck doing repeated send_completes.
It's also problematic that send_complete() is synchronous and
ipropd-master does not fork() and is not multi-threaded. We've seen a
case where one send_complete
On Fri, Oct 06, 2017 at 04:48:20PM +0200, Patrik Lundin wrote:
> On 2017-10-06 09:29:33, Jeffrey Hutzelman wrote:
> > It shouldn't be needed. First, a full dump is automatically triggered
> > if the master doesn't have enough log entries to bring the slave from
> > its current version to the
On Fri, Oct 06, 2017 at 09:29:33AM -0400, Jeffrey Hutzelman wrote:
> On October 6, 2017 5:56:22 AM EDT, Harald Barth wrote:
> It's also not necessary and in fact potentially harmful to check the
> master's version for 0. A real database can never be at version 0, so
> if you see
Trungcating the log is not the same thing as resetting it, and preserves
the version number.
On 2017-10-06 09:29:33, Jeffrey Hutzelman wrote:
>
> It shouldn't be needed. First, a full dump is automatically triggered
> if the master doesn't have enough log entries to bring the slave from
> its current version to the master version. so if a slave us at version
> 0, you either get a
On October 6, 2017 5:56:22 AM EDT, Harald Barth wrote:
>
>Removing that without putting something else in place (and I would say
>not only s->version == 0 but even current_version == 0 should trigger
>a send_complete) was probably a bad idea.
It shouldn't be needed. First, a full
> From what I can tell iprop has no way to differentiate between "I have no
> database, therefore I consider myself at version 0" and "I have a database, in
> sync with version 0".
I think (and hope) that a database is never at version 0 as it should
be created at version 1. So after the
By looking at the code of send_diffs (ipropd_master.c:666) it looks to
me that there somewhere at the beginning of that long function, before
plowing through the log on the master, there should be something like
if (current_version == 0 || s->version == 0){
(...)
return send_complete
Hello,
I am currently testing a 7.4.0 based KDC master with a slave running the
7.1.0 version available in Debian Stretch.
Currently I am experiencing problems with getting iprop to force a
complete sync of the database. As is stated in iprop-log(8) truncating
the log with --reset should cause
15 matches
Mail list logo