BDR
Sorry if this question was asked before. As I understand currently
BDR does not support the replicating nodes to run different major
versions, like
9.4 <-> 9.5.
Is this in the works?
thanks
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Jun 10, 2016 at 2:12 PM, Rakesh Kumar <rakeshkumar464a3@gmail.com>
wrote:
Sorry if this question was asked before. As I understand currently
BDR does not support the replicating nodes to run different major
versions, like
9.4 <-> 9.5.Is this in the works?
This seems relevant...
http://bdr-project.org/docs/stable/logical-vs-physical.html
But you question seems vague since BDR is a concept for which many
implementations exist.
David J.
This seems relevant...
thanks. very useful.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 11 June 2016 at 02:26, David G. Johnston <david.g.johnston@gmail.com>
wrote:
On Fri, Jun 10, 2016 at 2:12 PM, Rakesh Kumar <rakeshkumar464a3@gmail.com>
wrote:Sorry if this question was asked before. As I understand currently
BDR does not support the replicating nodes to run different major
versions, like
9.4 <-> 9.5.Is this in the works?
This seems relevant...
http://bdr-project.org/docs/stable/logical-vs-physical.html
But you question seems vague since BDR is a concept for which many
implementations exist.
I think they're specifically referring to 2ndQ's BDR project here, rather
than bi-directional logical replication general.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 11 June 2016 at 02:12, Rakesh Kumar <rakeshkumar464a3@gmail.com> wrote:
Sorry if this question was asked before. As I understand currently
BDR does not support the replicating nodes to run different major
versions, like
9.4 <-> 9.5.Is this in the works?
Not with BDR between 9.4 and 9.5, no, as there will not be a 9.5 version of
BDR. It'll be skipping straight to 9.6.
pglogical, a simplified and streamlined version of the logical replication
facilities used in BDR, can replicate from 9.4 to 9.5 (or to/from any other
combo of verisons 9.4+). It doesn't support multimaster or DDL replication
like BDR does, though.
You can also look into Londiste and Slony-I.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
http://bdr-project.org/docs/next/logical-vs-physical.html
"It (BDR) has significant advantages - and some disadvantages - when
compared to PostgreSQL's older physical (block-based) streaming or
archive-based replication with warm or hot standby"
What exactly is block based? Changes are recorded in the redo log,
right? Does that mean that in streaming replication, from redo log the
server applies changes at the block level of the data-file. That would
also mean that at any time, both primary and standby would be exactly
same, block by block.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Block based replication is the replication mechanism postgres incorporates natively. It's, in brief, sending all the file-level changes to all the slaves, so the data folder is always the same. It's like having a replicated folder, not including logs and some other things.
The disadvantage of block level replication, according to BDR, it that, when you have an open transaction, all DML is written to disk, even when the transaction is not committed. In a large transaction, all the date would be send to the slaves, even when, at the end, the transaction is rolled back. With BDR, the transaction is sent to the other masters only once it's committed.
Of course, this can be a problem in both cases, depending on your environment. With block level replication, you can get unnecessary traffic for transactions that would be finally rolled back(in contrast with BDR, which will send the whole transaction once it's committed); on BDR, you will get traffic peaks for some large transactions, as the whole transaction is sent once it's committed(in contrast to block level replication, which would send changes as they are being executed). The later can also cause some delay, depending on the connection between the servers:
Regards,
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51) 954183248
Website: www.ocs.pe
----- Original Message -----
From: "Rakesh Kumar" <rakeshkumar464a3@gmail.com>
Cc: "PostgreSql-general" <pgsql-general@postgresql.org>
Sent: Monday, 13 June, 2016 07:13:09
Subject: Re: [GENERAL] BDR
http://bdr-project.org/docs/next/logical-vs-physical.html
"It (BDR) has significant advantages - and some disadvantages - when
compared to PostgreSQL's older physical (block-based) streaming or
archive-based replication with warm or hot standby"
What exactly is block based? Changes are recorded in the redo log,
right? Does that mean that in streaming replication, from redo log the
server applies changes at the block level of the data-file. That would
also mean that at any time, both primary and standby would be exactly
same, block by block.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general