Streaming replication slots in PostgreSQL 9.4

Streaming replication Slots is a pending feature in PostgreSQL 9.4, as part of the logical changeset extraction feature.

What is they for, what does need to know, what changes?

What is replication slots?

Streaming replication slots is a new facility introduced in PostgreSQL 9.4. They was a persistent record of the state of a replica that was kept on the master server even when the replica was OFFL INE and disconnected.

They aren ' t used for physical replication by default, so you'll only have dealing with them if you enable their use. This post explains what they does, why they ' re useful for physical replication, and why they ' re necessary for logical replic ation.

Why slots?

As part of the ongoing work Andres have been doing on log-streaming logical replication, changeset extraction, and bidirect ional replication, there ' s been the need to better control WAL retention.

As streaming replication currently works, the master doesn ' t make any effort to retain extra WAL-a standby that ' s fall En behind. If the standby gets too far behind, the master would delete WAL segments the standby still needs to replay, and the standby Cannot recover. You get a error like:

ERROR:  requested WAL segment 00000001000000010000002D has already been removed

to prevent this, you is currently expected to configure continuous archiving and provide a Restore_command to give the replica access to the archive, or being willing to re-create a standby that falls behind.

A less reliable alternative are to set wal_keep_segments to a "high enough" value to ensure that the replica never Falls too far behind–but there ' s no real-to-guess what's high enough, and the higher the value is set the greater The risk the master is able to run out of space in Pg_xlog. So generally archiving is preferred.

The master could retain WAL for a replica while it's connected, but as soon as the replica disconnects for any reason the Master forgets all about it. As transient disconnects is common, this means there ' s not much point in trying to retain WAL just for connected replicas .

We ' ve gotten away with the because the option of falling back to continuous archiving have been available for when The master discards WAL the replicas still need. When the combined with or scripts likewal-e, a shared network file system, or a shared host to SCP archives To/from, It ' s done the job pretty well. It's a bit confusing for new users and it works well.

With log streaming logical replication we can ' t fall back on continuous archiving anymore, because the master must rea D WAL and decode it to send the resultsto the replicas; It can ' t just send raw WAL records. Replicas cannot just read raw WAL from the master and extract what they require themselves because only the master have a R Ecord of transaction ID statuses, the local OIDs of objects, etc.

We could just teach the master to run Restore_command (something people seem to assume happens anyway) –but that Could get very inefficient when many replicas want the same WAL archive. We ' d need a caching system and other complexity. It also doesn ' t get rid of the need for the admin to manage retention for archived WAL.

Unlike with physical replication, the option of just re-seeding a replica the have fallen too far behind are not acceptable For logical replication. There may and databases on the replica host, that contain their own original data. In the bidirectional replication case, the replica database may also contain newdata is yet replicated to other nodes. So we can ' t just write the replica off and make a new pg_basebackupfrom the master or re-rsync it's like we have Physcial replication.

The introduction of slots is intended to deal with this issue by giving the master persistent knowledge of the state of Replicas, even when they is disconnected. While it's added for logical replication, the concept are useful in physical replication as well, as it lets the master R Etain as much WAL as is required by all it standbys  and no more . There ' s no guesswork like there are with  wal_keep_segments . There ' s no need to set up a separate WAL archiving system and manage retention in it. So long as you have enough space in  pg_xlog  for The extra WAL, it just works. If a replica disconnects the master can keep WAL for it until it reconnects and replays the Wal.

The downside of this approach are that it adds another-in-the-unbounded WAL growth to fill pg_xlog –when a repli CA cannot receive or replay Wal fast enough or remains offline for a long time, the master would keep on retaining WAL unti L Pg_xlog fills up and it starts reporting errors to clients. This can already happen in a master with long checkpoint intervals under heavy load, but it's much easer to trigger with s Lots as a replica that goes ofline indefinitely would cause Pg_xlog to fill up.

While monitoring and adjustment of Pg_xlog capacity are already necessary for a busy PostgreSQL server, it's much More so for a server, which is using the slots to manage WAL retention for replication.

Operational impact

By default, physical replication won't use slots. Nothing changes. You must use the WAL archiving on top of the streaming to ensure reliable replication.

You can enable the use of replication slots for physical replication with the primary-slotname parameter in r Ecovery.conf. The physical replication slot must already has been created on the master with the pg_create_p Hysical_replication_slot (...) function; See the Docs.

When using the slots to manage physical replication, WAL archiving are no longer required for replication (though your may wish To retain it for PITR anyway). You don ' t need-deal with the difficulties of managing WAL retention amongst multiple replicas Line, with replay positions that is not known to the master when offline. You don ' t need to manage the space in the archive store.

Instead, need to keep a eye on space in Pg_xlog. WAL retention is managed automatically for you, and you must ensure there ' s enough space available.

If A replica is retired from service or unrecoverably lost due to failure of the host, you must manually remove the slot F Rom the master because the master won ' t delete any xlog until. If you had a system where the master produces xlog rapidly, this could require a lot of pg_xlog space or Fairly quick action. A monitoring system like Icinga or Zabbix is strongly recommended.

A replica that's unable to keep up the master must being fixed or retired to prevent the master from running out of Xlog Spa Ce.

With slots your no longer need to monitor the replicas to determine their state, as-accurate and up-to-date information is Always available in the pg_replication_slots view. So any need to does is monitor the master's Pg_xlog space and the status of all replication slots.

Any wal_keep_segments parameter is respected as a minimum for wal retention.

So:using slots for physical replication is a trade-off. You don ' t need archiving anymore, and you had to monitor the state of the system more closely to avoid disrupting the MAS ter.

Future work

To reduce the need for a large pg_xlog space allocation on what could is expensive high-performance storage, in F Uture slots May is extended to support moving WAL-a separate location once it's no longer required for the master ' s own Checkpointing.

Reference:

http://blog.2ndquadrant.com/postgresql-9-4-slots/

Streaming replication slots in PostgreSQL 9.4