begriffs open source - ai-pg/blob - full-docs/txt/different-replication-solutions.txt

   1
   2 26.1. Comparison of Different Solutions #
   3
   4    Shared Disk Failover
   5           Shared disk failover avoids synchronization overhead by having
   6           only one copy of the database. It uses a single disk array that
   7           is shared by multiple servers. If the main database server
   8           fails, the standby server is able to mount and start the
   9           database as though it were recovering from a database crash.
  10           This allows rapid failover with no data loss.
  11
  12           Shared hardware functionality is common in network storage
  13           devices. Using a network file system is also possible, though
  14           care must be taken that the file system has full POSIX behavior
  15           (see Section 18.2.2.1). One significant limitation of this
  16           method is that if the shared disk array fails or becomes
  17           corrupt, the primary and standby servers are both nonfunctional.
  18           Another issue is that the standby server should never access the
  19           shared storage while the primary server is running.
  20
  21    File System (Block Device) Replication
  22           A modified version of shared hardware functionality is file
  23           system replication, where all changes to a file system are
  24           mirrored to a file system residing on another computer. The only
  25           restriction is that the mirroring must be done in a way that
  26           ensures the standby server has a consistent copy of the file
  27           system — specifically, writes to the standby must be done in the
  28           same order as those on the primary. DRBD is a popular file
  29           system replication solution for Linux.
  30
  31    Write-Ahead Log Shipping
  32           Warm and hot standby servers can be kept current by reading a
  33           stream of write-ahead log (WAL) records. If the main server
  34           fails, the standby contains almost all of the data of the main
  35           server, and can be quickly made the new primary database server.
  36           This can be synchronous or asynchronous and can only be done for
  37           the entire database server.
  38
  39           A standby server can be implemented using file-based log
  40           shipping (Section 26.2) or streaming replication (see
  41           Section 26.2.5), or a combination of both. For information on
  42           hot standby, see Section 26.4.
  43
  44    Logical Replication
  45           Logical replication allows a database server to send a stream of
  46           data modifications to another server. PostgreSQL logical
  47           replication constructs a stream of logical data modifications
  48           from the WAL. Logical replication allows replication of data
  49           changes on a per-table basis. In addition, a server that is
  50           publishing its own changes can also subscribe to changes from
  51           another server, allowing data to flow in multiple directions.
  52           For more information on logical replication, see Chapter 29.
  53           Through the logical decoding interface (Chapter 47), third-party
  54           extensions can also provide similar functionality.
  55
  56    Trigger-Based Primary-Standby Replication
  57           A trigger-based replication setup typically funnels data
  58           modification queries to a designated primary server. Operating
  59           on a per-table basis, the primary server sends data changes
  60           (typically) asynchronously to the standby servers. Standby
  61           servers can answer queries while the primary is running, and may
  62           allow some local data changes or write activity. This form of
  63           replication is often used for offloading large analytical or
  64           data warehouse queries.
  65
  66           Slony-I is an example of this type of replication, with
  67           per-table granularity, and support for multiple standby servers.
  68           Because it updates the standby server asynchronously (in
  69           batches), there is possible data loss during fail over.
  70
  71    SQL-Based Replication Middleware
  72           With SQL-based replication middleware, a program intercepts
  73           every SQL query and sends it to one or all servers. Each server
  74           operates independently. Read-write queries must be sent to all
  75           servers, so that every server receives any changes. But
  76           read-only queries can be sent to just one server, allowing the
  77           read workload to be distributed among them.
  78
  79           If queries are simply broadcast unmodified, functions like
  80           random(), CURRENT_TIMESTAMP, and sequences can have different
  81           values on different servers. This is because each server
  82           operates independently, and because SQL queries are broadcast
  83           rather than actual data changes. If this is unacceptable, either
  84           the middleware or the application must determine such values
  85           from a single source and then use those values in write queries.
  86           Care must also be taken that all transactions either commit or
  87           abort on all servers, perhaps using two-phase commit (PREPARE
  88           TRANSACTION and COMMIT PREPARED). Pgpool-II and Continuent
  89           Tungsten are examples of this type of replication.
  90
  91    Asynchronous Multimaster Replication
  92           For servers that are not regularly connected or have slow
  93           communication links, like laptops or remote servers, keeping
  94           data consistent among servers is a challenge. Using asynchronous
  95           multimaster replication, each server works independently, and
  96           periodically communicates with the other servers to identify
  97           conflicting transactions. The conflicts can be resolved by users
  98           or conflict resolution rules. Bucardo is an example of this type
  99           of replication.
 100
 101    Synchronous Multimaster Replication
 102           In synchronous multimaster replication, each server can accept
 103           write requests, and modified data is transmitted from the
 104           original server to every other server before each transaction
 105           commits. Heavy write activity can cause excessive locking and
 106           commit delays, leading to poor performance. Read requests can be
 107           sent to any server. Some implementations use shared disk to
 108           reduce the communication overhead. Synchronous multimaster
 109           replication is best for mostly read workloads, though its big
 110           advantage is that any server can accept write requests — there
 111           is no need to partition workloads between primary and standby
 112           servers, and because the data changes are sent from one server
 113           to another, there is no problem with non-deterministic functions
 114           like random().
 115
 116           PostgreSQL does not offer this type of replication, though
 117           PostgreSQL two-phase commit (PREPARE TRANSACTION and COMMIT
 118           PREPARED) can be used to implement this in application code or
 119           middleware.
 120
 121    Table 26.1 summarizes the capabilities of the various solutions listed
 122    above.
 123
 124    Table 26.1. High Availability, Load Balancing, and Replication Feature
 125    Matrix
 126    Feature Shared Disk File System Repl. Write-Ahead Log Shipping Logical
 127    Repl. Trigger-Based Repl. SQL Repl. Middle-ware Async. MM Repl. Sync.
 128    MM Repl.
 129    Popular examples NAS DRBD built-in streaming repl. built-in logical
 130    repl., pglogical Londiste, Slony pgpool-II Bucardo
 131    Comm. method shared disk disk blocks WAL logical decoding table rows
 132    SQL table rows table rows and row locks
 133    No special hardware required   • • • • • • •
 134    Allows multiple primary servers       •   • • •
 135    No overhead on primary •   • •   •
 136    No waiting for multiple servers •   with sync off with sync off •   •
 137    Primary failure will never lose data • • with sync on with sync on   •
 138      •
 139    Replicas accept read-only queries     with hot standby • • • • •
 140    Per-table granularity       • •   • •
 141    No conflict resolution necessary • • •   • •   •
 142
 143    There are a few solutions that do not fit into the above categories:
 144
 145    Data Partitioning
 146           Data partitioning splits tables into data sets. Each set can be
 147           modified by only one server. For example, data can be
 148           partitioned by offices, e.g., London and Paris, with a server in
 149           each office. If queries combining London and Paris data are
 150           necessary, an application can query both servers, or
 151           primary/standby replication can be used to keep a read-only copy
 152           of the other office's data on each server.
 153
 154    Multiple-Server Parallel Query Execution
 155           Many of the above solutions allow multiple servers to handle
 156           multiple queries, but none allow a single query to use multiple
 157           servers to complete faster. This solution allows multiple
 158           servers to work concurrently on a single query. It is usually
 159           accomplished by splitting the data among servers and having each
 160           server execute its part of the query and return results to a
 161           central server where they are combined and returned to the user.
 162           This can be implemented using the PL/Proxy tool set.
 163
 164    It should also be noted that because PostgreSQL is open source and
 165    easily extended, a number of companies have taken PostgreSQL and
 166    created commercial closed-source solutions with unique failover,
 167    replication, and load balancing capabilities. These are not discussed
 168    here.