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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
