Hi,
Thanks for explaining the architecture in detail!
> If we want to include that as an option, yes. If it is "always on" then
> no, not everybody wants that.
Yes. I also think that archiving should be optional on each servers.
> The best way to implement that is to archive from the standby, not to
> send the data twice. By definition the archive is more closely
> associated with the standby node than the primary.
>
> Maybe I misunderstood the diagrams? The additional flows to the archive
> are actually all optional?
>
> Anyway, I enclose a slightly simplified version of p.6 to allow us to
> see the progression of file mode through to streaming mode. This is an
> in-my-understanding version.
Yes, I basically agree with you! The only difference between us is
whether the primary also has to switch two modes (FLS <-> SLS).
I think that the primary don't need to stop archiving forcibly when
replication starts, which should be optional for the user. The user
who doesn't want to archive can disable archiving by using existing
mechanism (change archive_command & pg_ctl reload). It's more
complicated to switch the modes on each servers.
For clarity: the user can choose the strategy of archiving from the
following.
1) each primary and standby archives
2) only primary archives
3) only standby archives
4) no server archives
The user who don't want to share an archive would choose 1).
The user who want to share an archive and cannot accept any
increase of bandwidth would choose 4). On the other hand,
the user who can accept it would choose 2) or 3). I prefer 2) to
3), for multiple standby in the future. And, if 3) is adopted,
I wonder if we can get a base backup. Can we get it from the
standby during recovery?
> I agree that is the way to do it *if* the archive is not shared. But why
> would you want to *not* share the archive??
First of all, I'd not like to buy a machine only for an archive other than
the primary and standby. Meanwhile, if an archive is located on either
the primary or standby (which should we locate it on?), post-failure
processing is complicated.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center