3) As plainly documented, in syncrepl all of the configuration and
important
state is consumer-side; the provider doesn't keep track of anything about
any
consumers. This is why syncrepl is flexible enough to allow consumers to be
added arbitrarily without needing to reconfig/restart or otherwise disturb
the
provider. It's also the only way to have really scalable replication. Since
the provider has no knowledge of individual consumers, *of course* the
provider doesn't complain when a consumer goes down. This fact is
self-evident
if you actually read the docs.
In fact, if you stated this this thing, you have *clearly no idea* how
replication (as a term) should work.
So, again, I don't care if you write the code, and if you want to help or
not. If you don't want to help, just don't write.
*Clearly* the provider SHOULD provide information, if it has pushed all the
updates to the slaves.
Ok, your excuse is that this is due to the fact, that the provider does not
keep track of slaves. Ergo?
The slaves are wrongly implemented. And *they* should provide the
information if they have the connection and are up2date or not.
This is of course totally implementation-dependent (in this case, I'd even
risk the statement that it is quite wrongly implemented), when we have *no
idea* if the slave copy is up2date or not.
Answers like those, make me think that open-source is a waste of time
comparing to paid solutions (even though I am a strong evangelist of Debian
and other open source solutions, which I think the writer does not care
about).
Are you an engineer geek in the cellar? Stay there. Sorry, real world of
*clearly* undocumented things.
Irritated night wishes.
Regards,
Radoslaw Antoniuk