Thans for your responses.
> I think you see such a behavior because you have disabled 'synchronized_standby_slots'
> in your script (# disable "synchronized_standby_slots"). You need to enable that to
> avoid data loss. Considering that, I don't think your proposed text is an improvement.
Yes, I know.
As David said, "without losing data" makes me confused because there are three patterns that users
think the data was lost though there may be other cases.
Pattern1. the data which clients get a committed response for from the old primary, but the new primary doesn’t have in
thecase of asynchronous replication
-> we can avoid this with synchronous replication. This is not relevant to the failover feature.
Pattern2. the data which the new primary has, but the subscribers don't have
-> we can avoid this with the failover feature.
Pattern3. the data which the subscribers have, but the new primary doesn't have
-> we can avoid this with the 'synchronized_standby_slots' parameter.
Currently, I understand that the following documentation says
* the failover feature makes publications without losing pattern 2 data.
* pattern 1 data may be lost if you use asynchronous replication.
* the following doesn't mention pattern 3 at all, which I misunderstood point.
> They can continue subscribing to publications on the new primary server without losing data.
> Note that in the case of asynchronous replication, there remains a risk of data loss for transactions
> committed on the former primary server but have yet to be replicated to the new primary server
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
