Обсуждение: Sync replication
I have a question regarding synchronus replication.
If i have a master and standby server will sync replication setup..when my slave dies and master is still active. Will the transaction completes, or master will wait for slave to commit the transaction and then commits its. ?
>I have a question regarding synchronus replication.
>If i have a master and standby server will sync replication setup..when my slave dies and master is still active. Will the transaction completes, or >master will wait for slave to commit the transaction and then commits its. ?
Master will wait for slave to come back up. PG"s replication is not the same as SQLServer/DB2/Oracle
where they allow master to continue operating while the slave is down. useful during scheduled maintenance.
>I have a question regarding synchronus replication.
>If i have a master and standby server will sync replication setup..when my slave dies and master is still active. Will the transaction completes, or >master will wait for slave to commit the transaction and then commits its. ?
Master will wait for slave to come back up. PG"s replication is not the same as SQLServer/DB2/Oracle
where they allow master to continue operating while the slave is down. useful during scheduled maintenance.
So untill my slave comes up master does not commit any transaction which means technically my db is non operative?
On Jan 25, 2018 12:23 PM, "Rakesh Kumar" <rakeshkumar464@aol.com> wrote:
>I have a question regarding synchronus replication.>If i have a master and standby server will sync replication setup..when my slave dies and master is still active. Will the transaction completes, or >master will wait for slave to commit the transaction and then commits its. ?Master will wait for slave to come back up. PG"s replication is not the same as SQLServer/DB2/Oraclewhere they allow master to continue operating while the slave is down. useful during scheduled maintenance.
So untill my slave comes up master does not commit any transaction which means technically my db is non operative?
On Jan 25, 2018 12:23 PM, "Rakesh Kumar" <rakeshkumar464@aol.com> wrote:
>I have a question regarding synchronus replication.>If i have a master and standby server will sync replication setup..when my slave dies and master is still active. Will the transaction completes, or >master will wait for slave to commit the transaction and then commits its. ?Master will wait for slave to come back up. PG"s replication is not the same as SQLServer/DB2/Oraclewhere they allow master to continue operating while the slave is down. useful during scheduled maintenance.
correct.
-----Original Message-----
From: Azimuddin Mohammed <azimeiu@gmail.com>
To: Rakesh Kumar <rakeshkumar464@aol.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>; pgsql-general <pgsql-general@postgresql.org>
Sent: Thu, Jan 25, 2018 8:06 pm
Subject: Re: Sync replication
From: Azimuddin Mohammed <azimeiu@gmail.com>
To: Rakesh Kumar <rakeshkumar464@aol.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>; pgsql-general <pgsql-general@postgresql.org>
Sent: Thu, Jan 25, 2018 8:06 pm
Subject: Re: Sync replication
So untill my slave comes up master does not commit any transaction which means technically my db is non operative?
On Jan 25, 2018 12:23 PM, "Rakesh Kumar" <rakeshkumar464@aol.com> wrote:
>I have a question regarding synchronus replication.>If i have a master and standby server will sync replication setup..when my slave dies and master is still active. Will the transaction completes, or >master will wait for slave to commit the transaction and then commits its. ?Master will wait for slave to come back up. PG"s replication is not the same as SQLServer/DB2/Oraclewhere they allow master to continue operating while the slave is down. useful during scheduled maintenance.
correct.
-----Original Message-----
From: Azimuddin Mohammed <azimeiu@gmail.com>
To: Rakesh Kumar <rakeshkumar464@aol.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>; pgsql-general <pgsql-general@postgresql.org>
Sent: Thu, Jan 25, 2018 8:06 pm
Subject: Re: Sync replication
From: Azimuddin Mohammed <azimeiu@gmail.com>
To: Rakesh Kumar <rakeshkumar464@aol.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>; pgsql-general <pgsql-general@postgresql.org>
Sent: Thu, Jan 25, 2018 8:06 pm
Subject: Re: Sync replication
So untill my slave comes up master does not commit any transaction which means technically my db is non operative?
On Jan 25, 2018 12:23 PM, "Rakesh Kumar" <rakeshkumar464@aol.com> wrote:
>I have a question regarding synchronus replication.>If i have a master and standby server will sync replication setup..when my slave dies and master is still active. Will the transaction completes, or >master will wait for slave to commit the transaction and then commits its. ?Master will wait for slave to come back up. PG"s replication is not the same as SQLServer/DB2/Oraclewhere they allow master to continue operating while the slave is down. useful during scheduled maintenance.
Greetings, On our mailing lists, we prefer that replies be in-line and ask that users not top-post. Please see my response, in-line, below. * Azimuddin Mohammed (azimeiu@gmail.com) wrote: > So untill my slave comes up master does not commit any transaction which > means technically my db is non operative? That's correct, which is why it's encouraged to have multiple replicas configured when using synchronous replication. In v10, it's possible to specify how many synchronous replicas are required to have acknowledged a given transaction before a COMMIT is returned to the applicaiton. Please review the documentation here: https://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION Thanks! Stephen
Вложения
Greetings, On our mailing lists, we prefer that replies be in-line and ask that users not top-post. Please see my response, in-line, below. * Azimuddin Mohammed (azimeiu@gmail.com) wrote: > So untill my slave comes up master does not commit any transaction which > means technically my db is non operative? That's correct, which is why it's encouraged to have multiple replicas configured when using synchronous replication. In v10, it's possible to specify how many synchronous replicas are required to have acknowledged a given transaction before a COMMIT is returned to the applicaiton. Please review the documentation here: https://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION Thanks! Stephen
Вложения
On Thu, Jan 25, 2018 at 08:21:43PM -0500, Stephen Frost wrote: > That's correct, which is why it's encouraged to have multiple replicas > configured when using synchronous replication. In v10, it's possible to > specify how many synchronous replicas are required to have acknowledged > a given transaction before a COMMIT is returned to the applicaiton. > Please review the documentation here: > > https://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION Be careful about the performance impact if there is network latency between a primary and its standbys. One small correction to what Stephen says here. It is possible to define multiple synchronous standbys in v9.6. v10 has added the possibility to define quorum groups. Note that the grammar as been kept backward-compatible across versions. -- Michael
Вложения
On Thu, Jan 25, 2018 at 08:21:43PM -0500, Stephen Frost wrote: > That's correct, which is why it's encouraged to have multiple replicas > configured when using synchronous replication. In v10, it's possible to > specify how many synchronous replicas are required to have acknowledged > a given transaction before a COMMIT is returned to the applicaiton. > Please review the documentation here: > > https://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION Be careful about the performance impact if there is network latency between a primary and its standbys. One small correction to what Stephen says here. It is possible to define multiple synchronous standbys in v9.6. v10 has added the possibility to define quorum groups. Note that the grammar as been kept backward-compatible across versions. -- Michael
Вложения
Greetings Michael, * Michael Paquier (michael.paquier@gmail.com) wrote: > On Thu, Jan 25, 2018 at 08:21:43PM -0500, Stephen Frost wrote: > > That's correct, which is why it's encouraged to have multiple replicas > > configured when using synchronous replication. In v10, it's possible to > > specify how many synchronous replicas are required to have acknowledged > > a given transaction before a COMMIT is returned to the applicaiton. > > Please review the documentation here: > > > > https://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION > > Be careful about the performance impact if there is network latency > between a primary and its standbys. One small correction to what Stephen > says here. It is possible to define multiple synchronous standbys in > v9.6. v10 has added the possibility to define quorum groups. Note that > the grammar as been kept backward-compatible across versions. Ah, yeah, I was thinking of quorum groups when writing that but you're right that 9.6 added support for multiple synchronous standbys. Older versions also supported having multiple synchronous standbys configured but were hard-wired to accept the commit with just one of them acknowledging it (in a priorty order based on the order of them as defined in synchronous_standby_names). Thanks for the clarification! Stephen
Вложения
Greetings Michael, * Michael Paquier (michael.paquier@gmail.com) wrote: > On Thu, Jan 25, 2018 at 08:21:43PM -0500, Stephen Frost wrote: > > That's correct, which is why it's encouraged to have multiple replicas > > configured when using synchronous replication. In v10, it's possible to > > specify how many synchronous replicas are required to have acknowledged > > a given transaction before a COMMIT is returned to the applicaiton. > > Please review the documentation here: > > > > https://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION > > Be careful about the performance impact if there is network latency > between a primary and its standbys. One small correction to what Stephen > says here. It is possible to define multiple synchronous standbys in > v9.6. v10 has added the possibility to define quorum groups. Note that > the grammar as been kept backward-compatible across versions. Ah, yeah, I was thinking of quorum groups when writing that but you're right that 9.6 added support for multiple synchronous standbys. Older versions also supported having multiple synchronous standbys configured but were hard-wired to accept the commit with just one of them acknowledging it (in a priorty order based on the order of them as defined in synchronous_standby_names). Thanks for the clarification! Stephen