January 8th, 2010 by depesz | Tags: , , , , , , , , | 1 comment »
Did it help? If yes - maybe you can help me? Donate BTC to 19zPa5diT2LZqGtTi8f8bfApLn8rw9zBHx

On 19th of December Simon Riggs committed a patch that will quite likely be the single most-talked-about change in PostgreSQL 8.5:

Log Message:
-----------
Allow read only connections during recovery, known as Hot Standby.
 
Enabled by recovery_connections = on (default) and forcing archive recovery
using a recovery.conf. Recovery processing now emulates the original
transactions as they are replayed, providing full locking and MVCC behaviour
for read only queries. Recovery must enter consistent state before
connections are allowed, so there is a delay, typically short, before
connections succeed. Replay of recovering transactions can conflict and in
some cases deadlock with queries during recovery; these result in query
cancellation after max_standby_delay seconds have expired. Infrastructure
changes have minor effects on normal running, though introduce four new
types of WAL record.
 
New test mode "make standbycheck" allows regression tests of
static command behaviour on a standby server while in recovery. Typical and
extreme dynamic behaviours have been checked via code inspection and manual
testing. Few port specific behaviours have been utilised, though primary
testing has been on Linux only so far.
 
This commit is the basic patch. Additional changes will follow in this
release to enhance some aspects of behaviour, notably improved handling of
conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL
are also required.
 
Simon Riggs, with significant and lengthy review by Heikki Linnakangas,
including streamlined redesign of snapshot creation and two-phase commit.
 
Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure,
Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas,
Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other
community members.

I assume you do know that you can have warm standby setup with PostgreSQL, for some time now. While this is great for failover, it has the drawback of not letting you properly use your hardware – it has to be “unused", and then it gets used only when problem happens.

Now, with Simon patch it is no longer the case – we can have queries running on slave database.

Let's see how that works.

I've set up 2 Pg instances, with WAL replication (if you don't know how to do it – it is pretty well described in docs, and this post is about new feature so I will skip instructions on how to make wal replication running).

Instance #1 – master, has datadir /home/pgdba/data and port 5850.

Instance #2 – slave, has datadir /home/pgdba/data2 and port 5851.

I ran a load-generator on master, which makes writes all the time – making master generate new wal segments approximately 1 segment every 12 seconds.

The great thing is that the “selects on slave" are enabled by default. So I can:

=$ psql -p 5851 -c "select count(*) from test01";
count
-------
72523
(1 row)

And it works :)

We can see that there is lag in replication:

=$ psql -p 5850 -c "select count(*) from test01"; psql -p 5851 -c "select count(*) from test01";
count
-------
73578
(1 row)
 
count
-------
73390
(1 row)

(my load generator only inserts new data).

So, generally it works.

There are some limitations though – 3 parameters:

  • max_connections
  • max_prepared_transactions
  • max_locks_per_transaction

have to be set to be at least the same as on master – and I would say, that preferably higher.

Now. What are the limitations? Well, simply put – if it writes anything, you can't use it. Full list of what's possible, and what not is in Hot Standby Docs – also check it just to get a better grip on how it works, and what are caveats.

For me, this single change means that for a lot of places I know Slony (and other replication engines based on triggers) lost ground. There are still usecases when trigger based replication will be fine (for example when you want to replicate only some of tables or databases from single instance of PostgreSQL), but for cases when you have dedicated DB server for single (or couple, but closely related) database – Hot Standby is better in practically every imaginable way. And this is great win.

Thank you Simon, and everybody else who helped with this achievement. Now, if we'd only could get streamed replication ;-P

  1. One comment

  2. # Matthew
    Jan 8, 2010

    Excellent. I will convert my Drupal databases from MySQL to PostgreSQL if Streaming Replication and Hot Standby are in this next release. The other features in 8.5 are OK, but not that game changing.

    To help prepare for these features, started to test Ubercart and other Drupal modules with PostgreSQL. I already sent one patch in. But if Streaming Replication does not make it to 8.5, then I will have to stay on MySQL for now and re-test with PostgreSQL with the new Drupal code at the time when Streaming Replication does look like it will make it.

Leave a comment