l.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Craig Ringer
Sent: Thursday, October 26, 2017 7:24 PM
To: Zhu, Joshua
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] BDR question on dboid conflicts
On 27 October 2017 at 01:15, Zhu, Joshua wrote:
> Database oid is used in both bdr.b
On 27 October 2017 at 01:15, Zhu, Joshua wrote:
> Database oid is used in both bdr.bdr_nodes, as node_dboid, and
> bdr.bdr_connections, as conn_dboid, also used in construction of replication
> slot names.
Correct. However, it's used in conjunction with the sysid and node timeline ID.
> I notice
Database oid is used in both bdr.bdr_nodes, as node_dboid, and
bdr.bdr_connections, as conn_dboid, also used in construction of replication
slot names.
I noticed that when trying to join a bdr group, if the database oid on the new
node happens to be the same as that of an node already in the bd
On 12 October 2017 at 11:03, Andres Freund wrote:
> On 2017-10-12 10:25:43 +0800, Craig Ringer wrote:
>> On 4 October 2017 at 00:21, milist ujang wrote:
>> > On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>> >>
>> >>
>> >> Can you get stacks please?
>> >>
>> >> Use -g
>> >
>> >
>> > # Event
On 2017-10-12 10:25:43 +0800, Craig Ringer wrote:
> On 4 October 2017 at 00:21, milist ujang wrote:
> > On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
> >>
> >>
> >> Can you get stacks please?
> >>
> >> Use -g
> >
> >
> > # Events: 2K cpu-clock
> > #
> > # Overhead Command Shared Obje
On 4 October 2017 at 00:21, milist ujang wrote:
> On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>>
>>
>> Can you get stacks please?
>>
>> Use -g
>
>
> # Events: 2K cpu-clock
> #
> # Overhead Command Shared ObjectSymbol
> # .
Hi Craig,
Anyway, this OS is guess OS in vmware (vsphere).
Thank for your response and help.
On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>
>
> Can you get stacks please?
>
> Use -g
>
# Events: 2K cpu-clock
#
# Overhead Command Shared ObjectSymbol
# ...
On 3 October 2017 at 19:45, milist ujang wrote:
> Hi all,
>
> I've an environment 9.4 + bdr:
> PostgreSQL 9.4.4
>
You're on a pretty old postgres-bdr. Update. You're missing a lot of fixes
from mainline.
> This is consolidation databases, in this machine there are around 250+ wal
> sender pro
Hi all,
I've an environment 9.4 + bdr:
PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.7.2-5) 4.7.2, 64-bit
kernel version:
3.2.0-4-amd64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux
This is consolidation databases, in this machine there are around 250+ wal
sender processes.
Hi Craig,
So, is it safe to drop those list from this query output?
select riname from pg_replication_identifier where riname not in
(select external_id from pg_replication_identifier_progress);
I cannot read pg_get_replication_identifier_progress function, is it likely
c function?
On Fri, S
On 15 September 2017 at 11:46, milist ujang wrote:
> Hi Craig,
>
> Thanks again for pointing to inactive replication slot.
> After inactive replication slot been dropped, the relfrozenxid now moving.
>
> I wonder if replication identifier will have some issue if left
> un-chained? since at other
Hi Craig,
Thanks again for pointing to inactive replication slot.
After inactive replication slot been dropped, the relfrozenxid now moving.
I wonder if replication identifier will have some issue if left
un-chained? since at other side there are inactive replication identifier.
On Fri, Sep 1
On 14 September 2017 at 13:35, milist ujang wrote:
> HI list,
>
> I have a database with bdr environment which keep alerting these messages
> in log file:
>
> HINT: Close open transactions soon to avoid wraparound problems.
> WARNING: oldest xmin is far in the past
>
Do you have any idle/old r
HI list,
I have a database with bdr environment which keep alerting these messages
in log file:
HINT: Close open transactions soon to avoid wraparound problems.
WARNING: oldest xmin is far in the past
Querying pg_stat_activity where state='active';
datname | template1
query
On 11 September 2017 at 09:32, milist ujang wrote:
> Hi all,
>
> Based on the docs and look at the processes, it seems 1 wal sender on each
> node per group.
>
> If there is scenario of consolidating many databases (say hundreds) into 1
> database (in this central cluster there are hundreds wal s
Hi all,
Based on the docs and look at the processes, it seems 1 wal sender on each
node per group.
If there is scenario of consolidating many databases (say hundreds) into 1
database (in this central cluster there are hundreds wal sender), what is
the limit number of groups?
I wonder if anyone h
On 7 September 2017 at 21:16, milist ujang wrote:
> Hi Craig,
>
> On Wed, Sep 6, 2017 at 4:07 PM, Craig Ringer
> wrote:
>
>>
>> You could drop and re-create the replication slot, I guess. But your
>> nodes would be hopelessly out of sync and need manual resync (with data
>> replication disabled)
Hi Craig,
On Wed, Sep 6, 2017 at 4:07 PM, Craig Ringer wrote:
>
> You could drop and re-create the replication slot, I guess. But your nodes
> would be hopelessly out of sync and need manual resync (with data
> replication disabled) of one node vs another.
>
Thanks for pointing to replication s
On 6 September 2017 at 08:47, milist ujang wrote:
> Hi Craig
>
> On Wed, Sep 6, 2017 at 7:21 AM, Craig Ringer
> wrote:
>>
>>
>> BDR can, see bdr.skip_changes_upto .
>>
>> Unluckily my bdr is 0.9.3
>
>
>> But PostgreSQL's logical decoding requires a contiguous WAL stream to
>> maintain a valid ca
Hi Craig
On Wed, Sep 6, 2017 at 7:21 AM, Craig Ringer wrote:
>
>
> BDR can, see bdr.skip_changes_upto .
>
> Unluckily my bdr is 0.9.3
> But PostgreSQL's logical decoding requires a contiguous WAL stream to
> maintain a valid catalog_xmin and restart_lsn, so it'll still fail to
> advance. So you
On 6 September 2017 at 01:52, milist ujang wrote:
> Hi all,
>
> due to space issue and high volume transaction, some wal segments removed
> from pg_xlog on bdr environment.
>
What, you deleted them?
> I had played streams and goldengate (oracle product) , that at capture
> side we can move for
Hi all,
due to space issue and high volume transaction, some wal segments removed
from pg_xlog on bdr environment.
warning log at node1 saying "requested WAL segment . has already been
removed" following Connection reset by peer.
log at node2 :
Sending replication command: START_REPLICATION
neral
Subject: Re: [GENERAL] BDR replication port
That's weird. Another idea: Do changes on that server get replicated to the
other servers? I'm not sure if incomming connections are used to receive WAL or
to send it.
Regards,
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
- Original Message -
From: "Zhu, Joshua"
To: "Alvaro Aguayo Garcia-Rada"
Cc: "PostgreSql-general"
Sent: Friday, 25 August, 2017 18:35:21
Subject: RE: [GENERAL] BDR replication port
Thought about t
: [GENERAL] BDR replication port
Just a guess: How did you blocked the port? Depending on that, you could be
blocking only new connections, but connections already established would
continue to transmit data; remember BDR only reconnects when connection is lost.
Alvaro Aguayo
Jefe de Operaciones
.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
- Original Message -
From: "Zhu, Joshua"
To: "PostgreSql-general"
Sent: Friday, 25 August, 2017 16:49:44
Subject: [GENERAL] BDR replication port
Hi, I am exper
Hi, I am experimenting how network configuration impacts BDR replication, ran
into something that I can't explain, and wonder if someone can shed light.
Here it goes:
With a four node BDR group configured and running (all using default port
5432), I purposely blocked port 5432 on one of the n
On 14 July 2017 at 00:09, Zhu, Joshua wrote:
>
>
> Found these log entries from one of the other node:
>
>
>
> t=2017-07-13 08:35:34 PDT p=27292 a=DEBUG: 0: found valid replication
> identifier 15
>
> t=2017-07-13 08:35:34 PDT p=27292 a=LOCATION:
> bdr_establish_connection_and_slot, bdr.c:60
Ringer [mailto:cr...@2ndquadrant.com]
Sent: Wednesday, July 12, 2017 11:59 PM
To: Zhu, Joshua
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] BDR node removal and rejoin
On 13 July 2017 at 01:56, Zhu, Joshua
mailto:j...@vormetric.com>> wrote:
Thanks for the clarification.
Looks lik
On 13 July 2017 at 01:56, Zhu, Joshua wrote:
> Thanks for the clarification.
>
>
>
> Looks like I am running into a different issue: while trying to pin down
> precisely the steps (and the order in which to perform them) needed to
> remove/rejoin a node, the removal/rejoining exercise was repeate
[mailto:cr...@2ndquadrant.com]
Sent: Wednesday, July 12, 2017 1:59 AM
To: Zhu, Joshua
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] BDR node removal and rejoin
On 11 July 2017 at 05:49, Zhu, Joshua
mailto:j...@vormetric.com>> wrote:
An update… after manually removing the record for
On 11 July 2017 at 05:49, Zhu, Joshua wrote:
> An update… after manually removing the record for ‘node4’ from
> bdr.bdr_nodes, corresponding record in bdr.bdr_connections, and associated
> replication slot (with pg_drop_replication_slot), rejoining was successful.
>
>
>
> I was under the impressi
An update... after manually removing the record for 'node4' from bdr.bdr_nodes,
corresponding record in bdr.bdr_connections, and associated replication slot
(with pg_drop_replication_slot), rejoining was successful.
I was under the impression that there is no need to perform manual cleanup
befo
Hi, I am having difficulty removing a node from a BDR group (with nodes node1
through node5) then rejoin the group.
Prior to removing a node, the BDR is running fine, query on bdr.bdr_nodes table
shows all nodes having the status 'r'.
Here is what I have done for removing node5 and rejoining:
> However if I perform any INSERT, UPDATE or DELETE operations on
> DB2 and these changes propagate over to DB1 via BDR I do not see DB1 firing
> any triggers. Is this intended behavior?
Yes.
> My current understanding is that
> BDR is unable to invoke Postgres triggers as it operates on the row
rds,
>
> 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: "jamesadams89"
> To: "
ite: www.ocs.pe
- Original Message -
From: "jamesadams89"
To: "PostgreSql-general"
Sent: Wednesday, 26 April, 2017 07:48:03
Subject: [GENERAL] BDR replication and table triggers
Hi,
I have some questions regarding how BDR interacts with triggers.
I have two databases t
Hi,
I have some questions regarding how BDR interacts with triggers.
I have two databases that are both joined to the same BDR group and
correctly replicating between one another sharing a table created as:
create table testtable(
key varchar(16) NOT NULL PRIMARY KEY,
data jsonb
2017-02-11 1:34 GMT+01:00 Tanner Kerr :
> I have two databases being replicated across three nodes with bdr. The
> third node filled up and crashed. I removed this node from the group
> successfully, but now I'm having trouble rejoining it. I'm able to re-join
> the one database no problem. Howeve
I have two databases being replicated across three nodes with bdr. The
third node filled up and crashed. I removed this node from the group
successfully, but now I'm having trouble rejoining it. I'm able to re-join
the one database no problem. However, trying to do a bdr join on the other
causes th
On 12 October 2016 at 00:55, Sylvain MARECHAL
wrote:
> Le 07/10/2016 à 23:54, Natan Abolafya a écrit :
>
> Is it possible to change the dsn connection string of a node without leaving
> the group? I couldn’t find the related documentation unfortunately.
>
> We’re using BDR in a dynamic environment
Le 07/10/2016 à 23:54, Natan Abolafya a écrit :
Hi
Is it possible to change the dsn connection string of a node without
leaving the group? I couldn’t find the related documentation
unfortunately.
We’re using BDR in a dynamic environment where the hostname/ip of a
node may be changed any ti
Hi
Is it possible to change the dsn connection string of a node without leaving
the group? I couldn't find the related documentation unfortunately.
We're using BDR in a dynamic environment where the hostname/ip of a node may
be changed any time. Leaving and rejoining the BDR group seems to be
On 31 August 2016 at 22:38, Salvatore Tomaselli
wrote:
> Hello,
>
> I have been looking around in the documentation and I didn't find anything,
> so I wonder if there is support in bdr for having transactions that happen
> while the global lock is acquired and get replicated everywhere before th
Hello,
I have been looking around in the documentation and I didn't find anything, so
I wonder if there is support in bdr for having transactions that happen while
the global lock is acquired and get replicated everywhere before the
transaction ends.
Is there a way to achieve this?
Best
--
Hello all,
After uninstalling a BDR node, it becomes not possible to join it again.
The following log appears in loop:
<<<
2016-08-25 10:17:08 [ll101] postgres info [11709]: [14620-1] LOG: starting
background worker process "bdr (6287997142852742670,1,19526,)->bdr
(6223672436788445259,2," #local4
El 20/07/16 a las 20:06, Jonathan Eastgate escribió:
>
> I assume that once BDR is enabled on a database that any additional
> schemas added post config are automatically included in BDR replication?
All DDLs (CREATE SCHEMA ...) will be replicated to the other nodes, but
if you are asking if the
Thanks guys.
Very helpful - I was thinking we may need to look at moving to schemas
instead of individual db's.
I assume that once BDR is enabled on a database that any additional schemas
added post config are automatically included in BDR replication?
And so you see any issues having potentiall
On 20 July 2016 at 13:22, Jonathan Eastgate
wrote:
> Hi everyone.
>
> We've been testing BDR on and off for the last 2 years and are keen to
> start looking at implementing it in production as it seems 0.93 has
> resolved most of the issues we faced with it in the early days.
>
> However there is
Hello. BDR works on a per-database basis, so there's nothing like what you are
looking for. However, if you initialize a BDR custer with bdr_init_copy, you
will get all existing databases added to replication. Then, as part of the
creation of new databases, you can use bdr_group_join function, w
Hi everyone.
We've been testing BDR on and off for the last 2 years and are keen to
start looking at implementing it in production as it seems 0.93 has
resolved most of the issues we faced with it in the early days.
However there is still one item that makes it a difficult proposition...
DSN con
Hello,
In my 2-node BDR setup if I make changes in db schema I am seeing below
error or after few reboots I get into below inconsistent state during DDL
replay. Is there any way to ignore ItemAlreadyExists error during DDL
replay ?
global lock of DDL replication is switched off in configuration.
umar"
Cc: "PostgreSql-general"
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)
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 i
On 11 June 2016 at 02:12, Rakesh Kumar 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
On 11 June 2016 at 02:26, David G. Johnston
wrote:
> On Fri, Jun 10, 2016 at 2:12 PM, Rakesh Kumar
> 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 thi
> This seems relevant...
>
> http://bdr-project.org/docs/stable/logical-vs-physical.html
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 Fri, Jun 10, 2016 at 2:12 PM, Rakesh Kumar
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
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 subscript
There appears to be absolutely zero documentation regarding the expected
format of a custom conflict handler function.
I'm attempting to define a custom conflict handler for a test bdr
cluster. When I tried to register a generic function with no parameters
I get a somewhat useful error message
Thanks a lot Martin for your replies.
On Sun, May 29, 2016 at 11:50 PM, Martín Marqués
wrote:
> Hi,
>
> El 29/05/16 a las 06:01, Nikhil escribió:
> >
> > *Nik>> skip_ddl_locking is set to True in my configuration. As this
> > was preventing single*
> >
> > *node from doing DDL operatio
Hi,
El 29/05/16 a las 06:01, Nikhil escribió:
>
> *Nik>> skip_ddl_locking is set to True in my configuration. As this
> was preventing single*
>
> *node from doing DDL operation (if one is down majority is not there
> for doing DDL on available node)*
Well, you have to be prepared to
Please see my replies inline.
On Sat, May 28, 2016 at 8:08 PM, Martín Marqués
wrote:
> El 28/05/16 a las 08:57, Nikhil escribió:
> > Once the node which was down is brought back the replication slot is not
> > turned active. The reason being replication slot is trying to create a
> > partition t
El 28/05/16 a las 08:57, Nikhil escribió:
> Once the node which was down is brought back the replication slot is not
> turned active. The reason being replication slot is trying to create a
> partition table which already exists. Because of this error replication
> slot is stuck in inactive mode. I
El 28/05/16 a las 08:57, Nikhil escribió:
> Once the node which was down is brought back the replication slot is not
> turned active. The reason being replication slot is trying to create a
> partition table which already exists. Because of this error replication
> slot is stuck in inactive mode. I
Once the node which was down is brought back the replication slot is not
turned active. The reason being replication slot is trying to create a
partition table which already exists. Because of this error replication
slot is stuck in inactive mode. Is there any way to ignore this error?
On 28-May-20
El 27/05/16 a las 06:33, Nikhil escribió:
> Hello,
>
>
> I have a BDR setup with two nodes. If I bring one node down i am seeing that
> the replication slot is becoming inactive with below error.
If you take down one of the nodes of a BDR mesh, the replication slots
from each of the upstream nod
Hello,
I have a BDR setup with two nodes. If I bring one node down i am seeing that
the replication slot is becoming inactive with below error.
<10.106.43.152(43253)nsxpostgres798452016-05-25 23:58:19 GMTnsxdb%DETAIL:
streaming transactions committing after 0/111A91
48, reading WAL from 0/110F0
On 28 April 2016 at 02:47, Will McCormick wrote:
> So if I wanted to extend a column from 100 characters to 255 characters is
> this permitted? The fact that I'm not making a change and the BDR kicked me
> out makes me skeptical.
>
Off the top of my head I'm not sure and would need to test. Ther
If you change the length of a character varying, it should work. I'm almost
sure I have done that before on my BDR cluster.
It may work as long as it does not require a full table rewrite. I think, the
length change for a character varying won't need a full table rewrite, as the
length is only
So if I wanted to extend a column from 100 characters to 255 characters is
this permitted? The fact that I'm not making a change and the BDR kicked me
out makes me skeptical.
On Wed, Apr 27, 2016 at 11:56 AM, Craig Ringer
wrote:
> On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <
> aagu...@
On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <
aagu...@opensysperu.com> wrote:
> Based on my experience, I can say BDR does not performs pre-DDL checks.
> For example, if you try to CREATE TABLE with the name of an existing table,
> BDR will acquire lock anyway, and then will fail when exe
Based on my experience, I can say BDR does not performs pre-DDL checks. For
example, if you try to CREATE TABLE with the name of an existing table, BDR
will acquire lock anyway, and then will fail when executing the DDL statement
on the first node, because the table already exists.
In your case
I guess the only viable option would be to the check explicitly ourselves.
On Wed, Apr 27, 2016 at 11:25 AM, Will McCormick
wrote:
> But this is the exact column definition that exists on the table when I
> execute the statement
>
> It's like it does not check the pre-existing state of the
But this is the exact column definition that exists on the table when I
execute the statement
It's like it does not check the pre-existing state of the column. Our code
is expecting a column already exists error but this error predicates that.
On Wed, Apr 27, 2016 at 10:21 AM, Adrian Klaver
On 04/27/2016 07:13 AM, Will McCormick wrote:
Why does this not work? From what I read only default values should
cause issue. I'm on release 9.4.4:
bms=# ALTER TABLE trap ALTER COLUMN trap_timestamp TYPE TIMESTAMP WITH
TIME ZONE;
ERROR: ALTER TABLE ... ALTER COLUMN TYPE may only affect UNLOGG
Why does this not work:
Hi All,
And sorry about that damn thumb pad! Premature send!
On Wed, Apr 27, 2016 at 10:15 AM, Adrian Klaver
wrote:
> On 04/27/2016 07:11 AM, Will McCormick wrote:
>
>> Why does this not work:
>>
>>
> Because it is NULL :)?
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
On 04/27/2016 07:11 AM, Will McCormick wrote:
Why does this not work:
Because it is NULL :)?
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-genera
Why does this not work? From what I read only default values should cause
issue. I'm on release 9.4.4:
bms=# ALTER TABLE trap ALTER COLUMN trap_timestamp TYPE TIMESTAMP WITH TIME
ZONE;
ERROR: ALTER TABLE ... ALTER COLUMN TYPE may only affect UNLOGGED or
TEMPORARY
tables when BDR is active; trap
On interface down:
--
<10.102.31.213(27599)postgres13082016-04-19 06:31:36
GMTprocess_journal%LOG: terminating walsender process due to replication
timeout
Once interface is brought back
425906 <12692016-04-19 08:32:58 GMT%LOG: starting
2016-04-19 6:51 GMT+02:00 Nikhil :
> Hello,
>
> I have a 2 node BDR group and replication is happening properly. if i
> bring down one of the node's interface, after sometime the replication
> slots are becoming inactive (pg_replication_slots view). Then if i bring
> back interface slots are not t
Hello,
What do you see on each node's log after enablibg interfaces?
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
Sent from my Sony Xperia™ smartphone
Nikhil wr
Hello,
I have a 2 node BDR group and replication is happening properly. if i bring
down one of the node's interface, after sometime the replication slots are
becoming inactive (pg_replication_slots view). Then if i bring back
interface slots are not turning active automatically and replication sto
"volga629"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 02:41:17
Subject: Re: [GENERAL] bdr replication
We are overlaping mails :P
What I don't understand is the need of a shared storage in this case. It would
be a lot better to h
ia-Rada"
To: "volga629"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 02:41:17
Subject: Re: [GENERAL] bdr replication
We are overlaping mails :P
What I don't understand is the need of a shared storage in this case. It would
On 3/30/2016 10:41 PM, Alvaro Aguayo Garcia-Rada wrote:
What I don't understand is the need of a shared storage in this case. It would
be a lot better to have the data folder inside each server virtual disk to
avoid troubles with the shared storage; I really see no reason for such
configuratio
M: #034252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
- Original Message -
From: "Slava Bendersky"
To: "Alvaro Aguayo Garcia-Rada"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 12:28:09 AM
Subject: Re: [GENER
question how to restore BDR replication
correctly.
volga629
From: "Alvaro Aguayo Garcia-Rada"
To: "volga629"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 02:19:42
Subject: Re: [GENERAL] bdr replication
What's the purpose o
I.R.L.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
- Original Message -
From: "Slava Bendersky"
To: "John R Pierce"
Cc: "pgsql-general"
Sent: Wednesday, 30 March, 2016 10:57:13 PM
Subject: Re: [GENERA
e"
Cc: "pgsql-general"
Sent: Thursday, 31 March, 2016 00:57:13
Subject: Re: [GENERAL] bdr replication
In my case only virtual hosts are use share storage (feed from glusterfs), but
actual virtual machines have own separate disks and all PostgreSQL run on
separate data director
0:34:55
Subject: Re: [GENERAL] bdr replication
On 3/30/2016 8:09 PM, Slava Bendersky wrote:
> Is any share storage technology recommended for PostgreSQL in virtual
> environment ?
> Ok what I will do is going take backups, shutdown both virtual servers
> and place all vm use loca
On 3/30/2016 8:09 PM, Slava Bendersky wrote:
Is any share storage technology recommended for PostgreSQL in virtual
environment ?
Ok what I will do is going take backups, shutdown both virtual servers
and place all vm use local disk on server only.
'share storage technology'... um.thats
Cc: "pgsql-general"
Sent: Wednesday, 30 March, 2016 23:57:28
Subject: Re: [GENERAL] bdr replication
On 31 March 2016 at 10:43, Slava Bendersky < volga...@skillsearch.ca > wrote:
Hello Craig,
The current setup is two server which run libvirt and for storage which run
gluste
On 31 March 2016 at 10:43, Slava Bendersky wrote:
> Hello Craig,
> The current setup is two server which run libvirt and for storage which
> run glusterfs (storage server feed two virtual servers). Right now is no
> fencing in place. Each of the nodes have one PostgreSQL vm with bdr.
>
That's
9"
Cc: "pgsql-general"
Sent: Wednesday, 30 March, 2016 23:20:49
Subject: Re: [GENERAL] bdr replication
On 31 March 2016 at 09:38, Slava Bendersky < volga...@skillsearch.ca > wrote:
Hello Everyone,
I am looking for suggestion how to recover bdr replication.
The shor
On 31 March 2016 at 09:38, Slava Bendersky wrote:
> Hello Everyone,
> I am looking for suggestion how to recover bdr replication.
> The short story we have 2 virtual nodes with share storage.
>
Can you describe the "shared storage" setup in more detail?
In general, with PostgreSQL "shared stora
Hello Everyone,
I am looking for suggestion how to recover bdr replication.
The short story we have 2 virtual nodes with share storage. Share storage lost
power and after I brought all online bdr doesn't work properly.
Here are some log
2016-03-30 20:47:26 EDT postgres@10.12.160.2(43714):fre
On 3/14/2016 2:43 PM, Roland van Laar wrote:
However my instances are not on the same server and I attempted to
simply add a host=(the ip) but that failed.
There are a couple of other factors:
- is postgres running on an external available ip?
- is there a replication user with a password?
3:
On 15 March 2016 at 05:17, Dustin Kempter
wrote:
> However my instances are not on the same server and I attempted to simply
> add a host=(the ip) but that failed. Please help
>
Review the logs on both hosts to see any errors during setup.
Note that you will need to drop and re-create the datab
1 - 100 of 378 matches
Mail list logo
