Wednesday, August 16

Tag: Hot Standby

When autovacuum does not vacuum

2ndQuadrant, PostgreSQL, Tomas' PlanetPostgreSQL
A few weeks ago I explained basics of autovacuum tuning. At the end of that post I promised to look into problems with vacuuming soon. Well, it took a bit longer than I planned, but here we go. To quickly recap, autovacuum is a background process cleaning up dead rows, e.g. old deleted row versions. You can also perform the cleanup manually by running VACUUM, but autovacuum does that automatically depending on the amount of dead rows in the table, at the right moment - not too often but frequently enough to keep the amount of "garbage" under control. (more…)
Evolution of Fault Tolerance in PostgreSQL: Synchronous Commit

Evolution of Fault Tolerance in PostgreSQL: Synchronous Commit

2ndQuadrant, Featured, Gulcin's PlanetPostgreSQL, PostgreSQL
PostgreSQL is an awesome project and it evolves at an amazing rate. We’ll focus on evolution of fault tolerance capabilities in PostgreSQL throughout its versions with a series of blog posts. This is the fourth post of the series and we’ll talk about synchronous commit and its effects on fault tolerance and dependability of PostgreSQL. If you would like to witness the evolution progress from the beginning, please check the first three blog posts of the series below. Each post is independent, so you don't actually need to read one to understand another. Evolution of Fault Tolerance in PostgreSQL  Evolution of Fault Tolerance in PostgreSQL: Replication Phase  Evolution of Fault Tolerance in PostgreSQL: Time Travel Synchronous Commit By default, PostgreSQL (more…)
Evolution of Fault Tolerance in PostgreSQL: Time Travel

Evolution of Fault Tolerance in PostgreSQL: Time Travel

2ndQuadrant, Featured, Gulcin's PlanetPostgreSQL, PostgreSQL
PostgreSQL is an awesome project and it evolves at an amazing rate. We’ll focus on evolution of fault tolerance capabilities in PostgreSQL throughout its versions with a series of blog posts. This is the third post of the series and we’ll talk about timeline issues and their effects on fault tolerance and dependability of PostgreSQL. If you would like to witness the evolution progress from the beginning, please check the first two blog posts of the series: Evolution of Fault Tolerance in PostgreSQL  Evolution of Fault Tolerance in PostgreSQL: Replication Phase  Timelines The ability to restore the database to a previous point in time creates some complexities which we’ll cover some of the cases by explaining failover (Fig. 1), switchover (Fig. 2) and pg_rewind (Fig (more…)
Evolution of Fault Tolerance in PostgreSQL: Replication Phase

Evolution of Fault Tolerance in PostgreSQL: Replication Phase

2ndQuadrant, Featured, Gulcin's PlanetPostgreSQL, PostgreSQL
PostgreSQL is an awesome project and it evolves at an amazing rate. We’ll focus on evolution of fault tolerance capabilities in PostgreSQL throughout its versions with a series of blog posts. This is the second post of the series and we'll talk about replication and its importance on fault tolerance and dependability of PostgreSQL. If you would like to witness the evolution progress from the beginning, please check the first blog post of the series: Evolution of Fault Tolerance in PostgreSQL PostgreSQL Replication Database replication is the term we use to describe the technology used to maintain a copy of a set of data on a remote system.  Keeping a reliable copy of a running system is one of the biggest concerns of redundancy and we all like maintainable, easy-to-use and (more…)
Getting WAL files from Barman with ‘get-wal’

Getting WAL files from Barman with ‘get-wal’

Barman, Gabriele's PlanetPostgreSQL
Barman 1.5.0 enhances the robustness and business continuity capabilities of PostgreSQL clusters, integrating the get-wal command with any standby server's restore_command. In this blog article I will go over the reasons behind this feature and briefly describe it. One of the initial ideas we had in mind when conceiving Barman was to make it, one day, a very large basin of WAL files, collected from one or more PostgreSQL servers within the same organisation. The internal codename of this feature was "WAL hub" and, in our mind, its main purpose was to allow any application (e.g. standby) to easily request and receive any WAL file for a given server, by enhancing Barman's command line interface and, ultimately, by implementing server support for PostgreSQL's streaming (more…)

Trade-offs in Hot Standby Deployments

Greg's PlanetPostgreSQL, PostgreSQL
The new Hot Standby feature in the upcoming PostgreSQL 9.0 allows running queries against standby nodes that previously did nothing but execute a recovery process. Two common expectations I've heard from users anticipating this feature is that it will allow either distributing short queries across both nodes, or allow running long reports against the standby without using resources on the master. These are both possible to do right now, but unless you understand the trade-offs involved in how Hot Standby works there can be some unanticipated behavior here. Standard Long-running Queries One of the traditional problems in a database using MVCC, like PostgreSQL, is that a long-running query has to keep open a resource--referred to as a snapshot in the current Postgres implementation--to (more…)