Ekaterina Amez Gonzalez writes:
> I tried what was suggested: reindexing and running "refresh collation"
> alter after that and everything seems to work ok so this looks like an easy
> wat to migrate from one server to another. Plus I feel more comfortable
> using streaming replication than logica
Hi Vamsi,
We have been doing these steps to setup streaming replication
--Primay-Server
CREATE ROLE repl REPLICATION LOGIN PASSWORD 'your_password';
postgresql.conf
listen_addresses = '*'
wal_level = replica
archive_mode = on
archive_command = 'copy %p \\path_to_archive\\%f'
max_wal_senders =
On 7/25/22 15:36, Kelly Burkhart wrote:
I have a primary and backup database running 12.10 and synced with
streaming replication. I have a simple table that is returning
different results for the same query in the primary vs backup database.
On the primary DB:
> select tag::bytea, * from se
> On Nov 4, 2021, at 12:16, Alanoly Andrews wrote:
>
> Thanks, Ninad, for the response.
> So, am I to understand that when there is a long-running query on the
> subscriber, the vacuumed data updates from the publisher are held over on the
> subscriber until the query completes? If so, where
disk space (either on the publisher or on the
subscriber)?
Regards.
Alanoly Andrews.
From: Ninad Shah [mailto:nshah.postg...@gmail.com]
Sent: Thursday, November 4, 2021 2:20 PM
To: Alanoly Andrews
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Streaming replication versus Logical replication
Yes, it is going to resolve the issue because streaming is completely a
slave(with few exceptions). Even the VACUUM operation gets replicated
through the master, which is not a case with logical replication. In
logical replication, only data from a few tables gets replicated. In terms
of database a
it does work well for logical replication.
still its sad that it doesnt work for physical replication as, then, how to
ensure continuous availability for generic apps ??
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Wed, Oct 6, 2021 at 5:03 PM Guillaume Lelarge
wrote:
> Le mer.
Le mer. 6 oct. 2021 à 13:46, Thomas Kellerer a écrit :
> Marc Millas schrieb am 06.10.2021 um 13:43:
> > on release 10, I remember reading something like: streaming replication
> is NOW upward compatible.
> > which could be understood as: its possible to have a master in rel 10
> and a slave in
Marc Millas schrieb am 06.10.2021 um 13:43:
> on release 10, I remember reading something like: streaming replication is
> NOW upward compatible.
> which could be understood as: its possible to have a master in rel 10 and a
> slave in rel 11.
No, that's not possible.
For streaming replication
On 16/06/2021 20:31, Alexey Bashtanov wrote:
I had it "latest" as well.
I'll try to reproduce it again tomorrow. replica -v -d
"dbname=postgres port=5432" -U postgres
I cannot quite reproduce it artificially.
One more piece of detail: in the chain
serverA->serverB->serverC->serverD when serv
I had it "latest" as well.
I'll try to reproduce it again tomorrow.
On 16/06/2021 17:20, Vijaykumar Jain wrote:
What is your recovery_target_timeline set to on replicas ?
I just did a primary -> replica -> cascading replica setup. and then
promoted replica as new primary.
cascading replica was
What is your recovery_target_timeline set to on replicas ?
I just did a primary -> replica -> cascading replica setup. and then
promoted replica as new primary.
cascading replica was working fine, no restarts required.
for me recovery_target_timeline was set to 'latest'
i have pg14beta installed
On 2021-02-22 23:02:12 +0530, Atul Kumar wrote:
> As I am new to postgres, could you help me to in how to check collation
show LC_COLLATE;
> and what is de_DE locale ?
The locale (i.e. language specific rules (sorting, formatting of
numbers, dates, etc.) for German ("de") as spoken in Germany ("
Hi Tom,
As I am new to postgres, could you help me to in how to check collation and
what is de_DE locale ?
Regards
On Monday, February 22, 2021, Tom Lane wrote:
> Ganesh Korde writes:
> > On Mon, 22 Feb 2021, 11:48 am Atul Kumar, wrote:
> >> I have postgres 9.6 cluster running on Cento
On 2021-02-22 10:36:56 -0500, Tom Lane wrote:
> The other thing you have to worry about is whether the collations you
> use sort the same on both systems ... if they don't, you'll have
> effectively-corrupt indexes on text columns on the standby.
>
> According to
>
> https://wiki.postgresql.org/w
Ganesh Korde writes:
> On Mon, 22 Feb 2021, 11:48 am Atul Kumar, wrote:
>> I have postgres 9.6 cluster running on Centos 6.8, so I just wanted to
>> know that can I configure streaming replication with same postgres version
>> i.e 9.6 running on centos 7.
> Should not be a problem if both OS arc
Should not be a problem if both OS archtecture (32 bit/ 64 bit) are same.
On Mon, 22 Feb 2021, 11:48 am Atul Kumar, wrote:
> Hi,
>
>
> I have postgres 9.6 cluster running on Centos 6.8, so I just wanted to
> know that can I configure streaming replication with same postgres version
> i.e 9.6 run
On 3/16/20 2:57 AM, Nicola Contu wrote:
I was able to make pg_basebackup working using --max-rate=128M
Still don't understand why. I guess it is related to the encryption and
slowness of the disk..
Do you have any idea?
I think your explanation fits. Encryption/decryption have overhead.
I
I was able to make pg_basebackup working using --max-rate=128M
Still don't understand why. I guess it is related to the encryption and
slowness of the disk..
Do you have any idea?
Il giorno ven 13 mar 2020 alle ore 16:15 Adrian Klaver <
adrian.kla...@aklaver.com> ha scritto:
> On 3/13/20 4:11 AM
On 3/13/20 4:11 AM, Nicola Contu wrote:
So in the logs I now see this :
2020-03-13 11:03:42 GMT [10.150.20.22(45294)] [27804]: [1-1]
db=[unknown],user=replicator LOG: terminating walsender process due to
replication timeout
Yeah that's been showing up the log snippets you have been posting.
So in the logs I now see this :
2020-03-13 11:03:42 GMT [10.150.20.22(45294)] [27804]: [1-1]
db=[unknown],user=replicator LOG: terminating walsender process due to
replication timeout
So I tried increasing the wal_sender_timeout to 300s but it did not help
Il giorno gio 12 mar 2020 alle ore 15:
The encryption is at os level. So the drives are encrypted with a password
where the db saves data
Il gio 12 mar 2020, 15:51 Adrian Klaver ha
scritto:
> On 3/12/20 4:31 AM, Nicola Contu wrote:
> > The replicator is ok and the replicated as well.
> > %Cpu(s): 0.2 us, 1.0 sy, 0.0 ni, 94.8 id,
On 3/12/20 4:31 AM, Nicola Contu wrote:
The replicator is ok and the replicated as well.
%Cpu(s): 0.2 us, 1.0 sy, 0.0 ni, 94.8 id, 4.0 wa, 0.0 hi, 0.0 si,
0.0 st
CPU is really low on both.
I am running pg_basebackup again everytime.
Any other suggestions?
I have to believe their is
The replicator is ok and the replicated as well.
%Cpu(s): 0.2 us, 1.0 sy, 0.0 ni, 94.8 id, 4.0 wa, 0.0 hi, 0.0 si,
0.0 st
CPU is really low on both.
I am running pg_basebackup again everytime.
Any other suggestions?
Il giorno mer 11 mar 2020 alle ore 23:13 Adrian Klaver <
adrian.kla...@
On 3/11/20 2:12 PM, Nicola Contu wrote:
CPU load on the server to be built? No.
CPU load, I/O load on the servers in the replication chain.
Basically you just recently, it seems, imposed extra overhead to the
process by encrypting/decrypting. From what I gather from earlier post
then your re
CPU load on the server to be built? No.
System logs don't show anything relevant unfortunately
Il mer 11 mar 2020, 21:34 Adrian Klaver ha
scritto:
> On 3/11/20 11:59 AM, Nicola Contu wrote:
> > I am actually cascading.
> > The master is in nyh, the first slave is in Dallas and the one having
> >
On 3/11/20 11:59 AM, Nicola Contu wrote:
I am actually cascading.
The master is in nyh, the first slave is in Dallas and the one having
problems is in Dallas as well on the same switch of the one replicating
from the master.
It always worked not sure what is wrong now. We just encrypted disks
I am actually cascading.
The master is in nyh, the first slave is in Dallas and the one having
problems is in Dallas as well on the same switch of the one replicating
from the master.
It always worked not sure what is wrong now. We just encrypted disks on all
servers
Il mer 11 mar 2020, 18:57 Ad
On 3/11/20 2:54 AM, Nicola Contu wrote:
These are the lines before
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [1-1]
db=cmdv3,user=zabbix_check ERROR: recovery is in progress
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [2-1]
db=cmdv3,user=zabbix_check HINT: WAL control functi
These are the lines before
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [1-1]
db=cmdv3,user=zabbix_check ERROR: recovery is in progress
2020-03-11 09:05:08 GMT [127.0.0.1(40214)] [43853]: [2-1]
db=cmdv3,user=zabbix_check HINT: WAL control functions cannot be executed
during recovery.
2020
On 3/10/20 8:17 AM, Nicola Contu wrote:
Please post to list also.
Ccing list.
What came immediately before the temporary file error?
2020-03-10 15:10:17 GMT [[local]] [28171]: [1-1]
db=postgres,user=postgres LOG: temporary file: path
"base/pgsql_tmp/pgsql_tmp28171.0", size 382474936
2020-0
On 3/10/20 2:26 AM, Nicola Contu wrote:
Hello,
I have two servers connected to the same switch running postgres 11.5
I am trying to replicate one of those servers after a planned work on
the master, so the replica has been lost. It has always worked but now I
get this :
pg_basebackup: could
Double check all the info is correct on the primary_conninfo line:
primary_conninfo = 'host=primary host port=5432 user=replication
password=replication'
And check your logs. It probably says something like cannot connect to host
primary.
From: Daulat Ram [mailto:daulat@exponential.com]
S
Greetings,
* Zachary Hanson-Hart (zac...@temple.edu) wrote:
>I know that the requirement for replication is that a user be allowed to
> connect to the "replication" database. My question is how to configure the
> streaming replication client to use a particular authentication method. I
> hav
Maeldron T. wrote:
> I’m a bit stuck with a few LOG messages. The one in the subject disturbs me
> the most.
>
> (FreeBSD 11.2, PostgreSQL 10.6)
>
> When I restart the hot standby, sometimes I see
>
> 2019-02-13 21:17:31 CET LOG: redo starts at 0/488A2748
> 2019-02-13 21:17:31 CET LOG: invali
On Thu, May 24, 2018 at 10:21:33AM +0200, talk to ben wrote:
> - Doing Streaming Replication between different minor version of PG is
> possible but not recommended [2]
Standbys need to be updated first, hence be careful that the primary is
not updated before the standbys or WAL generated on the
Hi,
- Doing Streaming Replication between different minor version of PG is
possible but not recommended [2]
- Doing Streaming Replication between different OSes is not recommended
pre ICU (pg10), please check you glibc versions. [1]
[1]
https://www.postgresql.org/message-id/ba6132e
Thanks Ian, thank you for pointing out the obvious.
It appears that Debian's *pg_dropcluster* command had unexpected
consequences you live, you pull out your hair in frustration and you
learn.
I now have streaming replication working as we expected, can you confirm
that my *(somewhat unusual s
On 05/21/2018 07:18 PM, Jonatan Evald Buus wrote:
> Hi there,
>
> I'm trying to configure streaming replication between a Red Hat server
> running PostGreSQL 9.2.2 and a Debian server running PostGreSQL 9.2.24
> with Hot Standby enabled.
>
> While the base backup works fine using /pg_basebackup/,
Hi Tim,
You have to enable hot_standby=on parameter on the replica server. See the
below link.
https://wiki.postgresql.org/wiki/Hot_Standby
Regards,
Ibrahim.
2018-01-30 21:16 GMT+03:00 Tim Bowden :
> I've inherited a PG 9.4.4 install on Win 2008 that I'm wanting to
> stream from (abt 80Gb on dis
40 matches
Mail list logo
