Re: replication

On 4/25/25 14:50, Marc Millas wrote: Hello, One of my customers tells me he did a replication with the master on a debian 10 and the slave on a debian 12, both with a pg13.20, one on a pgdg110+1, the other a pgdg120.1 is this a good idea ??? (I don't think so...) Sorry I dont quite get t

Re: Replication slot WAL reservation

> On Mar 25, 2025, at 13:58, Phillip Diffley wrote: > > Oh I see! I was conflating the data I see coming out of a replication slot > with the internal organization of the WAL. I think the more specific question > I am trying to answer is, as a consumer of a replication slot, how do I > reas

Re: Replication slot WAL reservation

> You're looking for Standby Status Update Awesome! I completely missed that. > Transactions are always presented to the output plugin in commit order Ok great. I think that is what I needed to know. Just to confirm, it sounds like the order messages are sent from the output plugin is what matt

Re: Replication slot WAL reservation

> On Mar 26, 2025, at 07:55, Phillip Diffley wrote: > Just to confirm, it sounds like the order messages are sent from the output > plugin is what matters here. When you update confirmed_flush_lsn to LSN "A", > any messages that were sent by the output plugin after the message with LSN > "A"

Re: Replication slot WAL reservation

> On Mar 25, 2025, at 20:56, Phillip Diffley wrote: > > Is there a message type that is used to confirm what logs have been > successfully consumed? You're looking for Standby Status Update: https://www.postgresql.org/docs/current/protocol-replication.html#PROTOCOL-REPLICATION-STAN

Re: Replication slot WAL reservation

> You shouldn't need to manually advance the replication slot. > The client is also expected to send back regular messages letting the publisher / primary know that it has successfully consumed up to a particular point I was thinking of these as the same thing, but it sounds like they are differen

Re: Replication slot WAL reservation

Oh I see! I was conflating the data I see coming out of a replication slot with the internal organization of the WAL. I think the more specific question I am trying to answer is, as a consumer of a replication slot, how do I reason about what replication records will be made unavailable when I conf

Re: Replication slot WAL reservation

Missed this question! > On Mar 25, 2025, at 09:56, Phillip Diffley wrote: > But when processing data from a replication slot, we confirm rows that have > been processed and can be deleted from the WAL based on the LSN (eg. with > pg_replication_slot_advance). How does postgres identify what par

Re: Replication slot WAL reservation

> On Mar 25, 2025, at 09:56, Phillip Diffley wrote: > 1. Every DML operation (insert, update, delete, truncate) will have a row in > the WAL and that row will have an LSN assigned to it. > 2. The LSNs are assigned when the operation happens. > 3. Operations within a transaction are written to

Re: Replication lag in Postgres

Hi, I recommend the following configurations/options in this case: • wal_sender_timeout: This setting determines how long the primary server waits for the standby server to acknowledge receipt of WAL data. Adjusting this can help ensure timely data transfer. • wal_keep_size: Ensures that enough

Re: Replication lag in Postgres

Thank you for the information Laurenz Albe On Fri, Jul 12, 2024 at 9:13 PM Laurenz Albe wrote: > On Fri, 2024-07-12 at 20:41 +0530, Mukesh Tanuku wrote: > > I have a question with postgres HA setup. > > We are setting up a 2 node postgres cluster with async streaming > replication, we want to >

Re: Replication lag in Postgres

On Fri, 2024-07-12 at 20:41 +0530, Mukesh Tanuku wrote: > I have a question with postgres HA setup. > We are setting up a 2 node postgres cluster with async streaming replication, > we want to > define a RPO (Recovery point objective) in case of primary failure.  > > How can we best define the RP

Re: Replication After manual Failover

How were you replicating? What was the status of the replication? On Tue, Jun 25, 2024 at 1:20 PM Yongye Serkfem wrote: > Hello Engineer, > Below is the error message I am getting after failing over to the standby > and reconfiguring the former master as the new standby. Any help will be > appr

Re: Replication After manual Failover

On Tue, Jun 25, 2024 at 2:39 PM Muhammad Ikram wrote: > Hi, > > Please reinitialize using pg_basebackup > Might not be possible during a switchover. > or use pg_rewind > > > > Muhammad Ikram > Bitnine Global > > > On Tue, 25 Jun 2024 at 22:20, Yongye Serkfem wrote: > >> Hello Engineer, >> Bel

Re: Replication After manual Failover

Hi, Please reinitialize using pg_basebackup or use pg_rewind Muhammad Ikram Bitnine Global On Tue, 25 Jun 2024 at 22:20, Yongye Serkfem wrote: > Hello Engineer, > Below is the error message I am getting after failing over to the standby > and reconfiguring the former master as the new stand

Re: Replication using mTLS issue

Hi Tom, thanks for the response! So the same user is able to connect using a non replication connection using the same mtls certificate and pg_ident.conf map. So it seems like the cert & map are working for this user. hostssl all pgrepmgr_nonprod 100.0.0.0/8 cert map=pgrepmgr_nonprod_map This ab

Re: Replication using mTLS issue

Drew Zoellner writes: > So the same user is able to connect using a non replication connection > using the same mtls certificate and pg_ident.conf map. So it seems like the > cert & map are working for this user. Hmph. I tried to reproduce your problem, and it works for me: I can create a replic

Re: Replication using mTLS issue

Drew Zoellner writes: > Hi Postgres team, I’m receiving an issue matching pg_hba rules that I can’t > seem to sort out. I am trying to use mtls certificate authentication for > physical replication connections but keep receiving the following error… > pg_receivewal: error: FATAL: no pg_hba.conf

Re: replication slot "pg_1015733_sync_1014718_7358407382484881476" does not exist

Hi Avi, Based on the slot name this is an initial sync worker being created by the Logical Replication supervisor. Subscriber started an initial sync either failed to create the slot and now thinks it exists and keeps trying to drop it on the publisher or another process dropped the slot on the p

Re: replication not replicating

On Tue, Jan 16, 2024 at 7:33 PM Brad White wrote: > On Tue, Jan 16, 2024 at 6:24 PM Ron Johnson > wrote: > >> On Tue, Jan 16, 2024 at 6:26 PM Brad White wrote: >> >>> On Tue, Jan 16, 2024 at 4:35 PM Ron Johnson >>> wrote: >>> > What database version? >>> v15 >>> >>> Streamin

Re: replication not replicating

On Tue, Jan 16, 2024 at 6:24 PM Ron Johnson wrote: > On Tue, Jan 16, 2024 at 6:26 PM Brad White wrote: > >> On Tue, Jan 16, 2024 at 4:35 PM Ron Johnson >> wrote: >> >>> What database version? >>> >> v15 >> >> >>> Streaming or Logical replication? >>> >> IDK >> >>> Using a slot? >>> >> No.

Re: replication not replicating

On Tue, Jan 16, 2024 at 6:26 PM Brad White wrote: > On Tue, Jan 16, 2024 at 4:35 PM Ron Johnson > wrote: > >> On Tue, Jan 16, 2024 at 4:10 PM Brad White wrote: >> >>> Errors from the primary >>> >>> 2024-01-15 00:00:51.157 CST [2660] ERROR: requested WAL segment >>> 0001000200A2 ha

Re: replication isn't replicating

On Tue, Jan 16, 2024 at 3:53 PM Emanuel Calvo <3man...@gmail.com> wrote: > > El mar, 16 ene 2024 a las 22:47, Brad White () > escribió: > >> Errors from the Primary server >> >> 2024-01-15 00:01:06.166 CST [1428] ERROR: requested WAL segment >> 0001000200A2 has already been removed >>

Re: replication not replicating

On Tue, Jan 16, 2024 at 4:35 PM Ron Johnson wrote: > On Tue, Jan 16, 2024 at 4:10 PM Brad White wrote: > >> Errors from the primary >> >> 2024-01-15 00:00:51.157 CST [2660] ERROR: requested WAL segment >> 0001000200A2 has already been removed >> 2024-01-15 00:00:51.157 CST [2660] ST

Re: replication not replicating

On Tue, Jan 16, 2024 at 4:10 PM Brad White wrote: > Errors from the primary > > 2024-01-15 00:00:51.157 CST [2660] ERROR: requested WAL segment > 0001000200A2 has already been removed > 2024-01-15 00:00:51.157 CST [2660] STATEMENT: START_REPLICATION > 2/A200 TIMELINE 1 > 2024-01

Re: replication isn't replicating

El mar, 16 ene 2024 a las 22:47, Brad White () escribió: > Errors from the Primary server > > 2024-01-15 00:01:06.166 CST [1428] ERROR: requested WAL segment > 0001000200A2 has already been removed > 2024-01-15 00:01:06.166 CST [1428] STATEMENT: START_REPLICATION > 2/A200 TIMELIN

Re: replication isn't replicating

Sorry for the repeat. It looked like it hadn't been sent. 😔 >

Re: replication strange behavior

Hi, In the master pg_hba.conf file, standby server hostname name is not being read even with the domain name, but server ip is working fine. output of /etc/hosts is given below 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdom

Re: replication strange behavior

On Thu, Nov 30, 2023 at 3:41 PM Atul Kumar wrote: > Hi, > > I have postgres 12 running in centos 7. > > I have configured streaming replication between one master and one standby > server. > > In the pg_hba.conf file of the master server, I have put the standby > server's hostname instead of IP a

Re: replication primary writting infinite number of WAL files

Peter J. Holzer (2023. nov. 26., V, 12:30): > > > nov 24 10:20:19 docker02 33d8b96b9062[1200]: 2023-11-24 10:20:19.691 CET > [35] > LOG: checkpoints are occurring too frequently (23 seconds apart) > > nov 24 10:20:42 docker02 33d8b96b9062[1200]: 2023-11-24 10:20:42.938 CET > [35] > LOG: checkpo

Re: replication primary writting infinite number of WAL files

On 2023-11-24 22:05:12 +0100, Les wrote: > And there is nothing in the logs in that time period besides "checkpoints > are happening too frequently"? > > > > Here are all the logs we have from that minute. > > ╰─# journalctl CONTAINER_ID=33d8b96b9062 --since '2023-11-24 10:18:00' --unti

Re: replication primary writting infinite number of WAL files

On 11/24/23 14:01, Les wrote: A single sequence for all id columns across all tables? How is the sequence value landing in the id column? In most cases it is by using "nextval(seq_name)" in the SQL statement. But sometimes the sequence value is taken first, and then multiple inserts

Re: replication primary writting infinite number of WAL files

> > > A single sequence for all id columns across all tables? > > How is the sequence value landing in the id column? > In most cases it is by using "nextval(seq_name)" in the SQL statement. But sometimes the sequence value is taken first, and then multiple inserts are sent with fixed increasing va

Re: replication primary writting infinite number of WAL files

On 11/24/23 1:05 PM, Les wrote: >> Sequence is incremented by 100,  so for example, between 2023-11-24 >> 10:20:00 and 2023-11-24 10:21:00 it went up 62188671 steps. I think it >> is not possible to insert 62188671 rows into a table. A psql function >> might be able

Re: replication primary writting infinite number of WAL files

> > > >> Sequence is incremented by 100, so for example, between 2023-11-24 > >> 10:20:00 and 2023-11-24 10:21:00 it went up 62188671 steps. I think it > >> is not possible to insert 62188671 rows into a table. A psql function > >> might be able to increment a sequence 62M times / minute, I'm not

Re: replication primary writting infinite number of WAL files

On 11/24/23 09:51, Adrian Klaver wrote: On 11/24/23 09:32, Les wrote: Please Reply All to include list Ccing list to get information back there. Adrian Klaver > (2023. nov. 24., P, 17:50):     On 11/24/23 03:39, Les wrote: > The only exception is a se

Re: replication primary writting infinite number of WAL files

> > > > I have no explanation for that, except a coincidence. > Replication slots don't generate WAL. > The problem stopped exactly when I dropped the slot. It happened three times in a row. :-(

Re: replication primary writting infinite number of WAL files

On 11/24/23 09:32, Les wrote: Please Reply All to include list Ccing list to get information back there. Adrian Klaver > (2023. nov. 24., P, 17:50): On 11/24/23 03:39, Les wrote: > The only exception is a sequence > value that was moved millio

Re: replication primary writting infinite number of WAL files

On Fri, 2023-11-24 at 16:59 +0100, Les wrote: > > > Laurenz Albe   (2023. nov. 24., P, 16:00): > > On Fri, 2023-11-24 at 12:39 +0100, Les wrote: > > > Under normal circumstances, the number of write operations is relatively > > > low, with an > > > average of 4-5 MB/sec total write speed on the

Re: replication primary writting infinite number of WAL files

On 11/24/23 03:39, Les wrote: Hello, Yesterday, the primary server suddenly started writing to the pg_wal directory at a crazy pace, 1.5GB/sec, but sometimes it went up to over 3GB/sec. The pg_wal started fattening up and didn't stop until it ran out of disk space. It happened so fast that we

Re: replication primary writting infinite number of WAL files

On Fri, 24 Nov 2023, 17:12 Ron Johnson, wrote: > On Fri, Nov 24, 2023 at 11:00 AM Les wrote: > [snip] > >> Writing of WAL files continued after we shut down all clients, and >> restarted the primary PostgreSQL server. >> >> The order was: >> >> 1. shut down all clients >> 2. stop the primary >>

Re: replication primary writting infinite number of WAL files

On Fri, Nov 24, 2023 at 11:00 AM Les wrote: [snip] > Writing of WAL files continued after we shut down all clients, and > restarted the primary PostgreSQL server. > > The order was: > > 1. shut down all clients > 2. stop the primary > 3. start the primary > 4. primary started to write like mad ag

Re: replication primary writting infinite number of WAL files

Laurenz Albe (2023. nov. 24., P, 16:00): > On Fri, 2023-11-24 at 12:39 +0100, Les wrote: > > Under normal circumstances, the number of write operations is relatively > low, with an > > average of 4-5 MB/sec total write speed on the disk associated with the > data directory. > > Yesterday, the pr

Re: replication primary writting infinite number of WAL files

On Fri, 2023-11-24 at 12:39 +0100, Les wrote: > Under normal circumstances, the number of write operations is relatively low, > with an > average of 4-5 MB/sec total write speed on the disk associated with the data > directory. > Yesterday, the primary server suddenly started writing to the pg_wa

Re: replication primary writting infinite number of WAL files

> > > First I was also thinking about vacuum. But removing a replication > > slot should have no effect on vacuum on the primary (AFAIK). Please > > correct me if I'm wrong. > > > > yeah, depends. there are 2 processes: > > * 1 process generating the wal's, maybe a VACUUM > * an inactive slot hold

Re: replication primary writting infinite number of WAL files

Am 24.11.23 um 13:52 schrieb Les: Andreas Kretschmer wrote (2023. nov. 24., P, 13:22): Am 24.11.23 um 12:39 schrieb Les: > > Hello, > please check the database log, a VACUUM can also lead to massive wal generation. Can you find other related messages? by the wa

Re: replication primary writting infinite number of WAL files

Andreas Kretschmer wrote (2023. nov. 24., P, 13:22): > > > Am 24.11.23 um 12:39 schrieb Les: > > > > Hello, > > > > please check the database log, a VACUUM can also lead to massive wal > generation. Can you find other related messages? by the way, the picture > is hard to read, please post text i

Re: replication primary writting infinite number of WAL files

Am 24.11.23 um 12:39 schrieb Les: Hello, Yesterday we were faced with a problem that we do not understand and cannot solve ourselves. We have a postgresql cluster using repmgr, which has three members. The version of all instances (currently) is "PostgreSQL 14.5 (Debian 14.5-2.pgdg110+2)

Re: Replication between different 15.x minor versions ok?

On Wed, 2023-06-28 at 12:01 +0200, David Tinker wrote: > Is it ok to use physical replication between different 15.x minor releases > (on Ubuntu 22.04)? I haven't been able to find a definitive answer. Yes, that is OK. Yours, Laurenz Albe

Re: Replication between different 15.x minor versions ok?

Streaming replication between minor versions works perfectly fine. However, it's better to use same versions but different minor versions also work. Sent from Outlook for Android From: David Tinker Sent: Wednesday, June 28, 2023 3:02:22 p

Re: Replication between Master PostgreSQL database version 9.6.1 and Standby/Slave PostgreSQL database version 10.17.

> On Oct 6, 2022, at 10:20, Kaushal Shriyan wrote: > > I am not sure if I understand the difference between binary and logical > replication between PostgreSQL Master and Standby/Slave server. It's best to review the documentation here: https://www.postgresql.org/docs/10/logical-rep

Re: Replication between Master PostgreSQL database version 9.6.1 and Standby/Slave PostgreSQL database version 10.17.

Thanks Christophe for the email and appreciate it. I am not sure if I understand the difference between binary and logical replication between PostgreSQL Master and Standby/Slave server. Please guide me. Thanks in advance. Best Regards, Kaushal On Wed, Oct 5, 2022 at 11:02 PM Christophe Pettus

Re: Replication between Master PostgreSQL database version 9.6.1 and Standby/Slave PostgreSQL database version 10.17.

> On Oct 5, 2022, at 09:32, Kaushal Shriyan wrote: > > Hi, > > Is replication possible between PostgreSQL support Master database running > 9.6.1 version which is a lower version to Standby/Slave running version > 10.17? Binary replication is not possible between different major versions.

Re: Replication with Patroni not working after killing secondary and starting again

> Does https://patroni.readthedocs.io/en/latest/replication_modes.html help? Thanks. I have found the same meanwhile. The effects I experienced were caused by the fact that Patroni configures async replication by default. After changing it to sync everything worked as expected

Re: Replication with Patroni not working after killing secondary and starting again

On 2022-05-04 10:21:56 +0200, Zb B wrote: > Apparently there is something wrong with my cluster. How to debug i?. > Do I need to configure anything so the replication is synchronous? Does https://patroni.readthedocs.io/en/latest/replication_modes.html help? hp -- _ | Peter J. Holzer

Re: Replication with Patroni not working after killing secondary and starting again

> What does `patronictl list` show during that interval? Well. I can't repeat the situation anymore. Now the replication starts immediately after starting the patroni on secondary. I did several switchover commands meanwhile though Meanwhile I did another test where I run a Java app with a large

Re: Replication with Patroni not working after killing secondary and starting again

On 2022-04-28 11:09:12 +0200, Zb B wrote: > > When the secondary starts up it should continue replicating from where > > it stopped. However, it can only do this if the necessary information is > > still available. If WAL files have been deleted in the mean time. it > > can't replay them. There sho

Re: Replication with Patroni not working after killing secondary and starting again

> When the secondary starts up it should continue replicating from where > it stopped. However, it can only do this if the necessary information is > still available. If WAL files have been deleted in the mean time. it > can't replay them. There should be error messages in your logs on what > went

Re: Replication with Patroni not working after killing secondary and starting again

On 2022-04-27 15:27:34 +0200, Zb B wrote: > Hi, > I am new to Patroni and PostgreSQL.We have set up a cluster with etcd (3 > nodes), Patroni (2 nodes) and PostgreSQL (2 nodes) with replication from > primary to secondary. Pretty much the setup we have. > Seemed to be working fine and we started s

Re: Replication between different architectures

Tom Lane wrote: "Phil Endecott" writes: Is replication going to work from an x86-64 master to an arm64 replica? The hard part of this is usually whether the operating systems are identical. If they have different locale data, you may find that indexes on text columns appear out-of-order and

Re: Replication between different architectures

"Phil Endecott" writes: > Is replication going to work from an x86-64 master to an > arm64 replica? The hard part of this is usually whether the operating systems are identical. If they have different locale data, you may find that indexes on text columns appear out-of-order and therefore corrup

Re: Replication between different architectures

On Wed, Oct 13, 2021 at 05:09:36PM +0100, Phil Endecott wrote: > Is replication going to work from an x86-64 master to an > arm64 replica? Hi, tested, works well. Best regards, depesz

Re: Replication sequence

Thank you! Il giorno mar 16 feb 2021 alle ore 13:38 Jehan-Guillaume de Rorthais < j...@dalibo.com> ha scritto: > On Tue, 16 Feb 2021 13:10:54 +0100 > Paolo Saudin wrote: > > > Il giorno mar 16 feb 2021 alle ore 10:51 Jehan-Guillaume de Rorthais < > > [...] > > > > [...] > > [...] > > [...] >

Re: Replication sequence

On Tue, 16 Feb 2021 13:10:54 +0100 Paolo Saudin wrote: > Il giorno mar 16 feb 2021 alle ore 10:51 Jehan-Guillaume de Rorthais < > [...] > > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > Thank you very much! > So in case the primary server crashes, and the bac

Re: Replication sequence

Il giorno mar 16 feb 2021 alle ore 10:51 Jehan-Guillaume de Rorthais < j...@dalibo.com> ha scritto: > On Mon, 15 Feb 2021 18:55:14 +0100 > Paolo Saudin wrote: > > > Hi all, > > I have two servers, a primary and a secondary one with a streaming > replica > > setup. > > Today I noticed that some se

Re: Replication sequence

On Mon, 15 Feb 2021 18:55:14 +0100 Paolo Saudin wrote: > Hi all, > I have two servers, a primary and a secondary one with a streaming replica > setup. > Today I noticed that some sequences are not lined-up, the replica ones are > well ahead, while the records number is the same. How is it possibl

Re: Replication sequence

Il giorno lun 15 feb 2021 alle ore 20:40 Loles ha scritto: > One thing is the number of records in the table and another is the current > value of the sequence. > > Execute: > > select max (field) from bobo.menu_pages; > > In both master and slave server. > > What give you back? > > "field" is th

Re: Replication sequence

One thing is the number of records in the table and another is the current value of the sequence. Execute: select max (field) from bobo.menu_pages; In both master and slave server. What give you back? "field" is the data that belongs to the sequence. El lun., 15 feb. 2021 18:55, Paolo Saudi

Re: Replication conflicts despite hot_standby_feedback = on?

On Wed, Jun 3, 2020 at 2:05 PM Laurenz Albe wrote: > > On Wed, 2020-06-03 at 13:41 +0200, Julien Rouhaud wrote: > > > I'm seeing the following at a customer site: > > > > > > SELECT confl_tablespace, confl_lock, confl_snapshot, confl_bufferpin, > > > confl_deadlock > > > FROM pg_stat_database_con

Re: Replication conflicts despite hot_standby_feedback = on?

On Wed, 2020-06-03 at 13:41 +0200, Julien Rouhaud wrote: > > I'm seeing the following at a customer site: > > > > SELECT confl_tablespace, confl_lock, confl_snapshot, confl_bufferpin, > > confl_deadlock > > FROM pg_stat_database_conflicts > > WHERE datname = 'something' \gx > > > > -[ RECORD 1 ]

Re: Replication conflicts despite hot_standby_feedback = on?

On Wed, Jun 3, 2020 at 1:07 PM Laurenz Albe wrote: > > I'm seeing the following at a customer site: > > SELECT confl_tablespace, confl_lock, confl_snapshot, confl_bufferpin, > confl_deadlock > FROM pg_stat_database_conflicts > WHERE datname = 'something' \gx > > -[ RECORD 1 ]+-- > confl_t

Re: Replication issue

On 4/17/20 7:47 AM, Sonam Sharma wrote: Yes, you are right. It's for connection failover from application end. I have set up db replication using repmgr. Version : 9.5 Can you reach the database crowd at host 172.29.195.216:50001 using psql or some other client? On Fri, Apr 17, 2020, 8:

Re: Replication issue

Yes, you are right. It's for connection failover from application end. I have set up db replication using repmgr. Version : 9.5 On Fri, Apr 17, 2020, 8:15 PM Julien Rouhaud wrote: > On Fri, Apr 17, 2020 at 4:02 PM Adrian Klaver > wrote: > > > > On 4/17/20 6:31 AM, Sonam Sharma wrote: > > > I

Re: Replication issue

On Fri, Apr 17, 2020 at 4:02 PM Adrian Klaver wrote: > > On 4/17/20 6:31 AM, Sonam Sharma wrote: > > I have setup db replication. And added below parameter in jdbc file . > > The connection is failing and it's throwing error like db doesn't exist > > on secondary server. > > > > jdbc:postgresql://

Re: Replication issue

On 4/17/20 6:31 AM, Sonam Sharma wrote: I have setup db replication. And added below parameter in jdbc file . The connection is failing and it's throwing error like db doesn't exist on secondary server. jdbc:postgresql://:50001,172.29.195.216:50001/crowd?targetServerType=master&reWriteBatchedI

Re: Replication: slave server has 3x size of production server?

On Sat, 22 Feb 2020 19:23:05 + Edson Richter wrote: [...] > Actually, standby server is sending wals to a backup (barman) server: > > archive_mode = always # enables archiving; off, on, or always > (change requires restart) archive_command = 'rsync -e "ssh -2 -C -p 2022" -az > %p ba

RE: Replication: slave server has 3x size of production server?

De: Adrian Klaver Enviado: domingo, 23 de fevereiro de 2020 15:42 Para: Edson Richter ; pgsql-general Assunto: Re: Replication: slave server has 3x size of production server? On 2/23/20 8:04 AM, Edson Richter wrote

Re: Replication: slave server has 3x size of production server?

On 2/23/20 8:04 AM, Edson Richter wrote: *De:* Adrian Klaver *Enviado:* sábado, 22 de fevereiro de 2020 20:34 *Para:* Edson Richter ; pgsql-general *Assunto:* Re: Replication: slave server has 3x

RE: Replication: slave server has 3x size of production server?

De: Adrian Klaver Enviado: sábado, 22 de fevereiro de 2020 20:34 Para: Edson Richter ; pgsql-general Assunto: Re: Replication: slave server has 3x size of production server? On 2/22/20 2:51 PM, Edson Richter wrote: > > Yes, it is working. Last X'

Re: Replication: slave server has 3x size of production server?

On 2/22/20 2:51 PM, Edson Richter wrote: Yes, it is working. Last X'log file is present on all thee servers. Also, comparting last transaction number on master and slave shows that all are in sync. Last, but not least, select max(id) from a busy table shows same id (when queried almost simult

RE: Replication: slave server has 3x size of production server?

De: Adrian Klaver Enviado: sábado, 22 de fevereiro de 2020 18:12 Para: Edson Richter ; pgsql-general Assunto: Re: Replication: slave server has 3x size of production server? On 2/22/20 11:23 AM, Edson Richter wrote

Re: Replication: slave server has 3x size of production server?

On 2/22/20 11:23 AM, Edson Richter wrote: *De:* Adrian Klaver *Enviado:* sábado, 22 de fevereiro de 2020 16:16 *Para:* Edson Richter ; pgsql-general *Assunto:* Re: Replication: slave server has 3x

RE: Replication: slave server has 3x size of production server?

De: Adrian Klaver Enviado: sábado, 22 de fevereiro de 2020 16:16 Para: Edson Richter ; pgsql-general Assunto: Re: Replication: slave server has 3x size of production server? On 2/22/20 11:03 AM, Edson Richter wrote

Re: Replication: slave server has 3x size of production server?

On 2/22/20 11:03 AM, Edson Richter wrote: Streaming replication. Initiated via pg_basebackup. Settings on master server: # - Sending Server(s) - # Set these on the master and on any standby that will send replica

RE: Replication: slave server has 3x size of production server?

De: Adrian Klaver Enviado: sábado, 22 de fevereiro de 2020 15:50 Para: Edson Richter ; pgsql-general Assunto: Re: Replication: slave server has 3x size of production server? On 2/22/20 10:05 AM, Edson Richter wrote

Re: Replication: slave server has 3x size of production server?

On 2/22/20 10:05 AM, Edson Richter wrote: *De:* Adrian Klaver *Enviado:* sábado, 22 de fevereiro de 2020 14:33 *Para:* Edson Richter ; pgsql-general *Assunto:* Re: Replication: slave server has 3x

RE: Replication: slave server has 3x size of production server?

De: Adrian Klaver Enviado: sábado, 22 de fevereiro de 2020 14:33 Para: Edson Richter ; pgsql-general Assunto: Re: Replication: slave server has 3x size of production server? On 2/22/20 9:25 AM, Edson Richter wrote: > Hi! > > I've a database clus

Re: Replication: slave server has 3x size of production server?

On 2/22/20 9:25 AM, Edson Richter wrote: Hi! I've a database cluster created at 9.6.10 linux x64 server rhel. I made progressive upgrades, first upgrading slave and then upgrading master. Actually both are running 9.6.17. Current production server has 196Gb in size. Nevertheless, the replicate

Re: Replication of Replication

On Fri, Oct 18, 2019 at 05:54:34PM -0400, Edilmar Alves wrote: I have 3 servers running CentOS+PG 11 (postgresql11-server-11.5-1PGDG.rhel7.x86_64): - s1: main db + publication - s2: subscription of the main db all works fine until here... Now, I tried to config this: - s2: publication of the sam

Re: replication topography

On Wed, Feb 27, 2019 at 12:59 PM Julie Nishimura wrote: > Hello Steve, > Thanks a lot for your info yesterday, it was very useful. If I run this > command on some of the servers and the results look like this, what would > it tell you? > > select * from pg_extension ; >extname| extowner

Re: replication topography

On 2/26/19 2:40 PM, Julie Nishimura wrote: Hello everybody, I've inherited big complicated postgresql kingdon with multiple servers in it, some of them are replicated, some of them are not, and there is Bunch of them. What would you be your suggestion, how should I start my investigation wha

Re: replication topography

Ouch. I'm sure others will have ideas to add but here are a few to start with. I would start by cataloging the instances. I hope you at least have a list of the servers - if not you may need to do network scans with nmap and even then may not locate all of them. On each instance I'd use some combi

Re: Replication

On 26 February 2019 10:41:19 CET, Sonam Sharma wrote: >Hi, > >Can we do master to master replication in Postgres. > Not in core, but with BDR. Andreas -- 2ndQuadrant - The PostgreSQL Support Company

Re: Replication

> On Feb 26, 2019, at 9:41 AM, Sonam Sharma wrote: > > Hi, > > Can we do master to master replication in Postgres. Look at https://bucardo.org/Bucardo/ , BDR (e.g. https://www.2ndquadrant.com/en/resources/postgres-bdr-2ndquadrant/ ), RubyRep or any of the other multimaster solutions at ht

Re: Replication

No - because there's no "out-of-the box" solution that creates two replicas, both writable. It's said on https://www.postgresql.org/docs/11/different-replication-solutions.html Yes - because with current postgres features (logical rep, partitions, foreign tables, ...) you can create solutions that

Re: replication lag despite corrective config

How big have been the delays after the new settings? I guess significantly lower than before, right? how much have they decreased? Am Mi., 21. Nov. 2018 um 13:18 Uhr schrieb Rene Romero Benavides < rene.romer...@gmail.com>: > You're welcome. > Since last Saturday when you addressed the 10 hour de

Re: replication lag despite corrective config

You're welcome. Since last Saturday when you addressed the 10 hour delay, with the new settings, have you seen more of such delay incidents? what the previous settings were? Beware that hot_standby_feedback = on and such long queries in the replica can increase bloat in the master, are you measurin

Re: replication lag despite corrective config

Hi Rene, On 11/19/18 8:46 PM, Rene Romero Benavides wrote: Not sure about the root cause but I can make these observations and raise some questions: 1) 9.6.6 is five bug fix versions behind Valid point to raise. 2) 300GB is so big a table, wouldn't make sense to you to partition it ? 2a) or i

Re: replication lag despite corrective config

On 11/19/18 11:09 PM, Laurenz Albe wrote: With these settings, any conflicting query will be canceled after five minutes. Perhaps your actual settings are different. What do you get for SELECT * FROM pg_settings WHERE name = 'max_standby_streaming_delay'; Hi Laurenz, thanks for backing up m

Re: replication lag despite corrective config

On Mon, 2018-11-19 at 17:46 -0800, Wyatt Alt wrote: > I've been struggling to eliminate replication lag on a Postgres 9.6.6 > instance on Amazon RDS. I believe the lag is caused by early cleanup > conflicts from vacuums on the master, because I can reliably resolve > it by killing long-running quer

  1   2   >