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
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.
Hello.
I have translated this post into Spanish.
http://blogadminsistemas.blogspot.com.es/2016/08/esperando-85-hot-standby-waiting-for-85.html
Thank you for your blog. It’s excellent in my opinion.