Обсуждение: [GENERAL] vacuum on streaming replication
Hi
setup a cluster, with streaming replication and hot stand by
the idea is to use the stand by to do queries whilst the primary is doing inserts.
But I noticed the stats on the stand by server don't update, nor can I run vacuum against it as its in recovery mode.
So how do update the stats and how will it affect my queries ?
On 31 July 2017 04:15:33 GMT+02:00, Alex Samad <alex@samad.com.au> wrote: >Hi > >setup a cluster, with streaming replication and hot stand by > >the idea is to use the stand by to do queries whilst the primary is >doing >inserts. > >But I noticed the stats on the stand by server don't update, nor can I >run >vacuum against it as its in recovery mode. > >So how do update the stats and how will it affect my queries ? The standby is read only, vacuum runs on the master and replicated to the standby. Analyse as well. Regards, Andreas -- 2ndQuadrant - The PostgreSQL Support Company
On Mon, Jul 31, 2017 at 7:28 AM, Andreas Kretschmer <andreas@a-kretschmer.de> wrote: > The standby is read only, vacuum runs on the master and replicated to the standby. Analyse as well. Please note as well that if hot_standby_feedback is enabled, the cleanup done by VACUUM on the primary is influenced as well so as tuples that a standby may need to avoid conflicts for its transactions are not removed. So VACUUM may result in less cleanup depending on the read load on the standby. -- Michael
On Mon, Jul 31, 2017 at 10:08 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Mon, Jul 31, 2017 at 7:28 AM, Andreas Kretschmer
<andreas@a-kretschmer.de> wrote:
> The standby is read only, vacuum runs on the master and replicated to the standby. Analyse as well.
Please note as well that if hot_standby_feedback is enabled, the
cleanup done by VACUUM on the primary is influenced as well so as
tuples that a standby may need to avoid conflicts for its transactions
are not removed. So VACUUM may result in less cleanup depending on the
read load on the standby.
Also that replication slots provide standby feedback and may further delay vacuuming when the standby is offline.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
Thanks
On 31 July 2017 at 18:11, Chris Travers <chris.travers@gmail.com> wrote:
On Mon, Jul 31, 2017 at 10:08 AM, Michael Paquier <michael.paquier@gmail.com> wrote:On Mon, Jul 31, 2017 at 7:28 AM, Andreas Kretschmer
<andreas@a-kretschmer.de> wrote:
> The standby is read only, vacuum runs on the master and replicated to the standby. Analyse as well.
Please note as well that if hot_standby_feedback is enabled, the
cleanup done by VACUUM on the primary is influenced as well so as
tuples that a standby may need to avoid conflicts for its transactions
are not removed. So VACUUM may result in less cleanup depending on the
read load on the standby.Also that replication slots provide standby feedback and may further delay vacuuming when the standby is offline.--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general --Best Wishes,Chris TraversEfficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.