Database Reference
In-Depth Information
PostgreSQL has included some form of native replication since Version 8.2, though that
support has steadily improved over time. External projects and tools have always been a
heavy part of the PostgreSQL landscape, with most of them being written and supported by
very strong PostgreSQL technical developers. Some people with a negative viewpoint have
observed that this weakens PostgreSQL or emphasizes shortcomings. My view would be that
PostgreSQL has been lucky enough to be supported by a huge range of replication tools,
together offering a wide set of supported use cases from which to build practical solutions.
That view extends throughout this chapter on replication, with around half of the recipes
mentioning tools that are not part of the core PostgreSQL project.
All of the tools mentioned in this chapter are maintained and actively enhanced by current
core PostgreSQL developers. The pace of change in this area is high, and it is likely that some
of the restrictions mentioned here could well be removed by the time you read this. Please
double-check the documentation for each tool or project.
Which
is
best?
is a question that gets asked many times. The answer varies on the exact
circumstances. In many cases, people use one technique on one server and a different
technique to protect other servers. Even the developers of particular tools use the other tools
when it is appropriate. Use the right tools for the job. All of the tools and techniques listed
in this chapter have been recommended by me at some time, in relevant circumstances. If
something isn't mentioned here by me that does probably imply it is less favorable for various
reasons, and there are some tools and techniques that I would personally avoid altogether in
their present form or level of maturity.
Understanding replication concepts
Replication technology can be confusing. You might be forgiven for thinking that people have a
reason to keep it that way. My observation is that there are many techniques, each with their
own advocates, and the strengths and weaknesses are often hotly debated.
There are some simple underlying concepts that can help us to understand the various
options available. The terms used here are designed to avoid favoring any particular
technique, as well as using standard industry terms when available.
How it works...
Database replication is the term we use to describe the technology for maintaining a copy
of a set of data on a remote system.
There are usually two main reasons for wanting to do this, and often those reasons
are combined:
F
High availability: Reducing the chances of data unavailability by having multiple
systems each holding a full copy of the data.
