pdf viewer in asp net c# : Add picture to pdf Library software API .net windows winforms sharepoint postgresql-9.4-A465-part2989

Chapter 24. Backup and Restore
WAL data generated by previous timelines. It is in fact possible to archive many different timelines.
While that might seem like a useless feature, it’s often a lifesaver. Consider the situation where you
aren’t quite sure what point-in-time to recover to, and so have to do several point-in-time recoveries
by trial and error until you find the best place to branch off from the old history. Without timelines
this process wouldsoongenerate anunmanageable mess. With timelines, youcan recover toany prior
state, including states in timeline branches that you abandoned earlier.
Every time a new timeline is created, PostgreSQL creates a “timeline history” file that shows which
timeline it branched off from and when. These history files are necessary to allow the system to
pick the right WAL segment files when recovering from an archive that contains multiple timelines.
Therefore, they are archived into the WAL archive area just like WAL segment files. The history files
are just small text files, so it’s cheap and appropriate to keep them around indefinitely (unlike the
segment files which are large). You can, if you like, add comments to a history file to record your
own notes about how and why this particular timeline was created. Such comments will be especially
valuable whenyou have a thicket of different timelines as a result of experimentation.
The default behavior of recovery is to recover alongthe same timeline that was current when the base
backup was taken. If you wish torecover into some child timeline (that is, youwant to return to some
state that was itself generated after a recovery attempt), you need to specify the target timeline ID in
recovery.conf
.You cannot recover intotimelines that branched off earlier than the base backup.
24.3.6. Tips and Examples
Some tips for configuring continuous archiving are given here.
24.3.6.1. Standalone Hot Backups
It is possible to use PostgreSQL’s backup facilities to produce standalone hot backups. These are
backups that cannot be used for point-in-time recovery, yet are typically much faster to backup and
restore than pg_dump dumps. (They are also much larger than pg_dump dumps, so in some cases the
speed advantage might be negated.)
As withbase backups, theeasiestwaytoproduce a standalone hot backupis to usethepg_basebackup
tool. If you include the
-X
parameter whencallingit, allthe transaction logrequired to use the backup
will be included in the backup automatically, and no special action is required to restore the backup.
If more flexibility in copying the backup files is needed, a lower level process can be used for stan-
dalone hot backups as well. To prepare for low level standalone hot backups, set
wal_level
to
archive
or higher,
archive_mode
to
on
,andset upan
archive_command
thatperforms archiving
only when a switch file exists. For example:
archive_command = ’test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)’
This command will perform archiving when
/var/lib/pgsql/backup_in_progress
exists, and
otherwise silently return zero exit status (allowing PostgreSQL torecycle the unwanted WAL file).
With this preparation, a backup can be taken using a script like the following:
touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup(’hot_backup’);"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
578
Add picture to pdf - insert images into PDF in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Sample C# code to add image, picture, logo or digital photo into PDF document page using PDF page editor control
add an image to a pdf; how to add image to pdf in preview
Add picture to pdf - VB.NET PDF insert image library: insert images into PDF in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Guide VB.NET Programmers How to Add Images in PDF Document
add jpg to pdf form; how to add jpg to pdf file
Chapter 24. Backup and Restore
The switch file
/var/lib/pgsql/backup_in_progress
is created first, enabling archiving of
completed WAL files to occur. After the backup the switch file is removed. Archived WAL files
are then added to the backup so that both base backupand all required WAL files are part of the same
tar file. Please remember to add error handling to your backup scripts.
24.3.6.2. Compressed Archive Logs
If archive storage size is a concern, you can use gzip to compress the archive files:
archive_command = ’gzip < %p > /var/lib/pgsql/archive/%f’
You will then need to use gunzip during recovery:
restore_command = ’gunzip < /mnt/server/archivedir/%f > %p’
24.3.6.3.
archive_command
Scripts
Many people choose to use scripts to define their
archive_command
, so that their
postgresql.conf
entry looks very simple:
archive_command = ’local_backup_script.sh "%p" "%f"’
Using a separate script file is advisable any time you want to use more than a single command in the
archiving process. This allows all complexity to be managed within the script, which can be written
in a popular scripting language such as bash or perl.
Examples of requirements that might be solved within a script include:
Copying data to secure off-site data storage
Batching WAL files so that they are transferred everythree hours, rather than one at a time
Interfacing with other backup and recovery software
Interfacing with monitoring software to report errors
Tip: Whenusing an
archive_command
script, it’s desirable to enable logging_collector. Any mes-
sages written to stderr from the script will then appear in the database server log, allowing com-
plex configurations to be diagnosed easily if they fail.
24.3.7. Caveats
At this writing, there are several limitations of the continuous archiving technique. These will proba-
bly be fixed in future releases:
Operations onhash indexes are notpresently WAL-logged, so replay will not update these indexes.
This will mean that any new inserts will be ignored by the index, updated rows will apparently
579
C# TIFF: How to Insert & Burn Picture/Image into TIFF Document
Support adding image or picture to an existing or new new REImage(@"c:\ logo.png"); // add the image powerful & profession imaging controls, PDF document, tiff
add signature image to pdf; adding an image to a pdf file
VB.NET Image: Image Cropping SDK to Cut Out Image, Picture and
VB.NET image cropper control SDK; VB.NET image cropping method to crop picture / photo; you can adjust the size of created cropped image file, add antique effect
how to add an image to a pdf file in acrobat; add photo to pdf in preview
Chapter 24. Backup and Restore
disappear and deleted rows will still retain pointers. In other words, if you modify a table with
ahash index on it then you will get incorrect query results on a standby server. When recovery
completes it is recommended that you manually REINDEX each such index after completing a
recovery operation.
If a CREATE DATABASE command is executed while a base backup is being taken, and then the
template database that the
CREATE DATABASE
copied is modified while the base backup is still
in progress, it is possible that recovery will cause those modifications to be propagated into the
created database as well. This is of course undesirable. To avoid this risk, it is best not to modify
any template databases while taking a base backup.
CREATE TABLESPACE commands are WAL-logged with the literal absolute path, andwill there-
fore be replayed as tablespace creations with the same absolute path. This might be undesirable
if the log is being replayed on a different machine. It can be dangerous even if the log is being
replayed on the same machine, but into a new data directory: the replay will still overwrite the
contents of the original tablespace. To avoid potential gotchas of this sort, the best practice is to
take a new base backup after creating or dropping tablespaces.
It should also be noted that the default WAL format is fairly bulky since it includes many disk page
snapshots. These page snapshots are designed to support crash recovery, since we might need to fix
partially-written disk pages. Depending on your system hardware and software, the risk of partial
writes might be small enough to ignore, in which case you can significantly reduce the total vol-
ume of archived logs by turning off page snapshots using the full_page_writes parameter. (Read the
notes and warnings in Chapter 29 before you do so.) Turning off page snapshots does not prevent
use of the logs for PITR operations. An area for future development is to compress archived WAL
data by removing unnecessary page copies even when
full_page_writes
is on. In the meantime,
administrators mightwishto reduce the number of page snapshots includedinWAL byincreasing the
checkpoint interval parameters as much as feasible.
580
VB.NET TIFF: How to Draw Picture & Write Text on TIFF Document in
drawing As RaterEdgeDrawing = New RaterEdgeDrawing() drawing.Picture = "RasterEdge" drawing provide powerful & profession imaging controls, PDF document, tiff
add image in pdf using java; how to add photo to pdf in preview
VB.NET Image: VB.NET Codes to Add Antique Effect to Image with .
mature technology to replace a picture's original colors add the glow and noise, and add a little powerful & profession imaging controls, PDF document, image
add png to pdf preview; how to add an image to a pdf in acrobat
Chapter 25. High Availability, Load Balancing,
and Replication
Database servers can work together to allow a second server to take over quickly if the primary
server fails (high availability), or to allow several computers to serve the same data (load balancing).
Ideally, databaseservers couldworktogether seamlessly. Web servers serving static web pages can be
combined quite easilybymerelyload-balancing web requests to multiple machines. Infact, read-only
database servers can be combined relatively easily too. Unfortunately, most database servers have a
read/write mix of requests, andread/write servers are muchharder tocombine. This is because though
read-onlydata needs tobe placed on each server only once, a write to any server has to be propagated
to all servers so that future read requests to those servers return consistent results.
This synchronization problem is the fundamental difficulty for servers working together. Because
there is no single solution that eliminates the impact of the sync problem for all use cases, there are
multiple solutions. Each solution addresses this problem in a different way, and minimizes its impact
for a specific workload.
Some solutions deal with synchronization by allowing only one server to modify the data. Servers
that can modify data are called read/write, master or primary servers. Servers that track changes in
the master are called standby or slave servers. A standby server that cannot be connected to until it is
promoted to a master server is called a warm standby server, and one thatcan accept connections and
serves read-only queries is called a hot standby server.
Some solutions are synchronous, meaning that a data-modifying transaction is not considered com-
mitteduntilallservers havecommitted the transaction. This guarantees thata failover willnotloseany
data and that all load-balancedservers will returnconsistentresults nomatter which server is queried.
In contrast, asynchronous solutions allow some delay between the time of a commit and its propa-
gation to the other servers, opening the possibility that some transactions might be lost in the switch
to a backup server, and that load balanced servers might return slightly stale results. Asynchronous
communication is used when synchronous would be too slow.
Solutions can also be categorized by their granularity. Some solutions can deal only with an entire
database server, while others allow control at the per-table or per-database level.
Performance must be consideredin any choice. There is usuallya trade-off between functionality and
performance. For example, a fully synchronous solution over a slow network might cut performance
by more than half, while an asynchronous one might have a minimal performance impact.
The remainder of this section outlines various failover, replication, and load balancing solutions. A
glossary
1
is also available.
25.1. Comparison of Different Solutions
Shared Disk Failover
Shared disk failover avoids synchronization overhead by having only one copy of the database.
It uses a single disk array that is shared by multiple servers. If the main database server fails,
the standby server is able to mount and start the database as though it were recovering from a
database crash. This allows rapid failover with no data loss.
Shared hardware functionality is common in network storage devices. Using a network file sys-
tem is also possible, though care must be taken that the file system has full POSIXbehavior (see
1. http://www.postgres-r.org/documentation/terms
581
VB.NET Image: Image Scaling SDK to Scale Picture / Photo
Framework application; VB.NET sample code for how to scale image / picture; Frequently asked questions about RasterEdge VB.NET image scaling control SDK add-on.
adding a jpg to a pdf; add an image to a pdf with acrobat
VB.NET Image: Create Code 11 Barcode on Picture & Document Using
file, apart from above mentioned .NET core imaging SDK and .NET barcode creator add-on, you also need to buy .NET PDF document editor add-on, namely, RasterEdge
adding images to pdf; add photo to pdf for
Chapter 25. High Availability, LoadBalancing, and Replication
Section 17.2.2). One significant limitation of this method is that if the shared disk array fails or
becomes corrupt, the primary and standby servers are both nonfunctional. Another issue is that
the standby server shouldnever access the shared storage while the primary server is running.
File System (Block-Device) Replication
Amodified version of sharedhardware functionality is file system replication, where allchanges
to a file system are mirrored to a file system residing on another computer. The only restriction
is that the mirroring must be done in a way that ensures the standby server has a consistent copy
of the file system — specifically, writes to the standby must be done in the same order as those
on the master. DRBD is a popular file system replication solution for Linux.
Transaction Log Shipping
Warm andhotstandby servers canbe kept currentby reading astream of write-ahead log (WAL)
records. If the mainserver fails, the standby contains almost all of thedataof the mainserver, and
can be quickly made the new master database server. This can be synchronous or asynchronous
andcan only be done for the entire database server.
Astandby server can be implemented using file-based log shipping (Section 25.2) or streaming
replication (see Section 25.2.5), or a combination of both. For information on hot standby, see
Section 25.5.
Trigger-Based Master-Standby Replication
Amaster-standby replication setup sends all data modification queries to the master server. The
master server asynchronously sends data changes to the standby server. The standby can an-
swer read-only queries while the master server is running. The standby server is ideal for data
warehouse queries.
Slony-I is an example of this type of replication, with per-table granularity, and support for
multiple standby servers. Because it updates the standby server asynchronously (in batches),
there is possible data loss during fail over.
Statement-Based Replication Middleware
With statement-based replication middleware, a program intercepts every SQL query and sends
it to one or all servers. Each server operates independently. Read-write queries must be sent to
all servers, so that every server receives any changes. But read-only queries can be sent to just
one server, allowing the read workload to be distributed among them.
If queries are simply broadcast unmodified, functions like
random()
,
CURRENT_TIMESTAMP
,
and sequences can have different values on different servers. This is because each server op-
erates independently, and because SQL queries are broadcast (and not actual modified rows).
If this is unacceptable, either the middleware or the application must query such values from a
single server and then use those values in write queries. Another option is to use this replica-
tion option with a traditional master-standby setup, i.e. data modification queries are sent only
to the master and are propagated to the standby servers via master-standby replication, not by
the replication middleware. Care must also be taken that all transactions either commit or abort
on all servers, perhaps using two-phase commit (PREPARE TRANSACTION and COMMIT
PREPARED. Pgpool-II and Continuent Tungsten are examples of this type of replication.
Asynchronous Multimaster Replication
For servers that are not regularly connected, like laptops or remote servers, keeping data con-
sistent among servers is a challenge. Using asynchronous multimaster replication, each server
works independently, and periodically communicates with the other servers to identify conflict-
ing transactions. The conflicts can be resolved by users or conflict resolution rules. Bucardo is
an example of this type of replication.
582
C# Word - Paragraph Processing in C#.NET
Add references: C# users can set paragraph properties and create content such as run, footnote, endnote and picture in a paragraph.
acrobat add image to pdf; add image pdf
VB.NET Image: Image Resizer Control SDK to Resize Picture & Photo
NET Method to Resize Image & Picture. Here we this VB.NET image resizer control add-on, can provide powerful & profession imaging controls, PDF document, image
add multiple jpg to pdf; add picture to pdf file
Chapter 25. High Availability, LoadBalancing, and Replication
Synchronous Multimaster Replication
In synchronous multimaster replication, each server can accept write requests, and modified data
is transmitted from the original server to every other server before each transaction commits.
Heavy write activity can cause excessive locking, leading to poor performance. In fact, write
performance is often worse than that of a single server. Read requests can be sent to any server.
Some implementations use shared disk to reduce the communication overhead. Synchronous
multimaster replication is best for mostly read workloads, though its big advantage is that any
server can accept write requests — there is no need to partition workloads between master and
standby servers, and because the data changes are sent from one server to another, there is no
problem with non-deterministic functions like
random()
.
PostgreSQL does not offer this type of replication, thoughPostgreSQL two-phasecommit (PRE-
PARE TRANSACTION and COMMIT PREPARED) can be used to implement this in applica-
tion code or middleware.
Commercial Solutions
Because PostgreSQL is open source and easily extended, a number of companies have taken
PostgreSQL and created commercial closed-source solutions with unique failover, replication,
andload balancing capabilities.
Table 25-1 summarizes the capabilities of the various solutions listed above.
Table 25-1. High Availability, Load Balancing, and Replication Feature Matrix
Feature
Shared
Disk
Failover
File
System
Replica-
tion
Transaction
Log
Shipping
Trigger-
Based
Master-
Standby
Replica-
tion
Statement-
Based
Replica-
tion
Middle-
ware
Asynchronous
Multi-
master
Replica-
tion
Synchronous
Multi-
master
Replica-
tion
Most
Common
Implemen-
tation
NAS
DRBD
Streaming
Repl.
Slony
pgpool-II
Bucardo
Communication
Method
shared
disk
disk
blocks
WAL
table rows
SQL
table rows
table rows
and row
locks
Nospecial
hardware
required
Allows
multiple
master
servers
Nomaster
server
overhead
583
Chapter 25. High Availability, LoadBalancing, and Replication
Feature
Shared
Disk
Failover
File
System
Replica-
tion
Transaction
Log
Shipping
Trigger-
Based
Master-
Standby
Replica-
tion
Statement-
Based
Replica-
tion
Middle-
ware
Asynchronous
Multi-
master
Replica-
tion
Synchronous
Multi-
master
Replica-
tion
No
waiting for
multiple
servers
with sync
off
Master
failure will
never lose
data
with sync
on
Standby
accept
read-only
queries
with hot
Per-table
granularity
No
conflict
resolution
necessary
There are a few solutions that do not fit into the above categories:
Data Partitioning
Data partitioning splits tables into data sets. Each set can be modified by only one server. For
example, data can be partitioned by offices, e.g., London and Paris, with a server in each office.
If queries combining LondonandParis data are necessary, anapplicationcan query bothservers,
or master/standby replication can be used to keep a read-only copy of the other office’s data on
each server.
Multiple-Server Parallel Query Execution
Many of the above solutions allow multiple servers to handle multiple queries, but none allow
asingle query to use multiple servers to complete faster. This solution allows multiple servers
to work concurrently on a single query. It is usually accomplished by splitting the data among
servers and having each server execute its part of the query and return results to a central server
where theyare combined andreturned to the user. Pgpool-II has this capability. Also, this can be
implemented using the PL/Proxy tool set.
25.2. Log-Shipping Standby Servers
Continuous archiving can be used to create a high availability (HA) cluster configuration with one
or more standby servers ready to take over operations if the primary server fails. This capability is
widely referred to as warm standby or log shipping.
584
Chapter 25. High Availability, LoadBalancing, and Replication
The primary and standby server work together to provide this capability, though the servers are only
looselycoupled. The primaryserver operates incontinuous archivingmode, while eachstandbyserver
operates in continuous recovery mode, reading the WAL files from the primary. No changes to the
database tables are required to enable this capability, so it offers low administration overhead com-
pared to some other replication solutions. This configuration also has relatively low performance
impact onthe primary server.
Directly moving WAL records from one database server to another is typically described as log ship-
ping. PostgreSQL implements file-based log shipping by transferring WAL records one file (WAL
segment) at a time. WAL files (16MB) can be shipped easily and cheaply over any distance, whether
it be to an adjacent system, another system at the same site, or another system on the far side of the
globe. The bandwidth required for this technique varies according to the transaction rate of the pri-
mary server. Record-based log shipping is more granular and streams WAL changes incrementally
over a network connection(see Section 25.2.5).
It should be noted that log shipping is asynchronous, i.e., the WAL records are shipped after transac-
tion commit. As aresult, thereis awindow for data loss shouldtheprimaryserver suffer a catastrophic
failure; transactions not yet shipped will be lost. The size of the data loss window in file-based log
shipping can be limited by use of the
archive_timeout
parameter, which can be set as low as a
few seconds. However such a low setting will substantially increase the bandwidth required for file
shipping. Streaming replication (see Section 25.2.5) allows a much smaller window of data loss.
Recovery performance is sufficiently good that the standby will typically be only moments away
from full availability once it has been activated. As a result, this is called a warm standby configura-
tion which offers high availability. Restoring a server from an archived base backup and rollforward
will take considerably longer, so that technique only offers a solution for disaster recovery, not high
availability. A standby server can also be used for read-only queries, in which case it is called a Hot
Standby server. See Section 25.5 for more information.
25.2.1. Planning
It is usually wise to create the primary and standby servers so that they are as similar as possible,
at least from the perspective of the database server. In particular, the path names associated with
tablespaces will be passed across unmodified, so both primary and standby servers must have the
samemountpaths for tablespaces if thatfeature is used. Keepinmindthatif CREATE TABLESPACE
is executed on the primary, any new mount point needed for it must be created on the primary and
all standby servers before the command is executed. Hardware need not be exactly the same, but
experience shows that maintaining two identical systems is easier than maintaining two dissimilar
ones over the lifetime of the application and system. In any case the hardware architecture must be
the same — shipping from, say, a 32-bit to a 64-bit system will not work.
In general, log shipping between servers running different major PostgreSQL release levels is not
possible. It is the policy of the PostgreSQL Global Development Group not to make changes to disk
formats during minor release upgrades, so it is likely that running different minor release levels on
primary and standby servers will work successfully. However, no formal support for that is offered
andyouare advised to keep primaryandstandby servers atthesamerelease levelas muchas possible.
When updating to a new minor release, the safest policy is to update the standby servers first — a new
minor release is more likely to be able to read WAL files from a previous minor release than vice
versa.
585
Chapter 25. High Availability, LoadBalancing, and Replication
25.2.2. Standby Server Operation
In standby mode, the server continuously applies WAL received from the master server. The standby
server can read WAL from a WAL archive (see restore_command) or directly from the master over
aTCP connection (streaming replication). The standby server will also attempt to restore any WAL
found in the standby cluster’s
pg_xlog
directory. That typically happens after a server restart, when
the standby replays again WAL thatwas streamed from the master before the restart, but you can also
manually copy files to
pg_xlog
at any time to have them replayed.
At startup, the standby begins by restoring all WAL available in the archive location, calling
restore_command
.Once it reaches the end of WAL available there and
restore_command
fails,
it tries to restore any WAL available in the
pg_xlog
directory. If that fails, and streaming replication
has been configured, the standby tries to connect to the primary server and start streaming WAL
from the last valid record found in archive or
pg_xlog
.If that fails or streaming replication is not
configured, or if the connection is later disconnected, the standby goes back to step 1 and tries to
restore the file from the archive again. This loop of retries from the archive,
pg_xlog
, and via
streaming replication goes on until the server is stopped or failover is triggered by a trigger file.
Standby mode is exited and the server switches to normal operation when
pg_ctl promote
is run
or a trigger file is found (
trigger_file
). Before failover, any WAL immediately available in the
archive or in
pg_xlog
will be restored, but no attempt is made to connect to the master.
25.2.3. Preparing the Master for Standby Servers
Set up continuous archiving on the primary to an archive directory accessible from the standby, as
described in Section 24.3. The archive location should be accessible from the standby even when the
master is down, i.e. it should reside on the standby server itself or another trusted server, not on the
master server.
If you want to use streaming replication, set up authentication on the primary server to allow replica-
tion connections from the standby server(s); thatis, create arole and provide a suitable entry or entries
in
pg_hba.conf
withthedatabase field set to
replication
.Alsoensure
max_wal_senders
is set
to a sufficiently large value in the configuration file of the primary server. If replication slots will be
used, ensure that
max_replication_slots
is set sufficiently high as well.
Take a base backup as described in Section 24.3.2 to bootstrap the standbyserver.
25.2.4. Setting Up a Standby Server
To set up the standby server, restore the base backup taken from primary server (see Section
24.3.4). Create a recovery command file
recovery.conf
in the standby’s cluster data directory,
and turn on
standby_mode
. Set
restore_command
to a simple command to copy files from
the WAL archive. If you plan to have multiple standby servers for high availability purposes, set
recovery_target_timeline
to
latest
,to make the standby server follow the timeline change
that occurs at failover to another standby.
Note: Do not use pg_standby or similar tools with the built-in standby mode described here.
restore_command
should return immediately if the file does not exist; the server will retry the
command again if necessary. See Section 25.4 for using tools like pg_standby.
586
Chapter 25. High Availability, LoadBalancing, and Replication
If you want to use streaming replication, fill in
primary_conninfo
with a libpq connection string,
including the host name (or IP address) and any additional details needed to connect to the primary
server. If the primary needs a password for authentication, the password needs to be specified in
primary_conninfo
as well.
If you’re setting up the standby server for high availability purposes, set up WAL archiving, connec-
tions and authentication like the primary server, because the standby server will work as a primary
server after failover.
If you’re usinga WAL archive, its size can be minimized usingthearchive_cleanup_commandparam-
eter to remove files that are nolonger required by the standby server. The pg_archivecleanuputilityis
designed specificallyto be used with
archive_cleanup_command
in typical single-standbyconfig-
urations, see pg_archivecleanup. Note however, that if you’re using the archive for backup purposes,
youneedtoretainfiles needed torecover from at least the latest basebackup, evenif they’re nolonger
needed by the standby.
Asimple example of a
recovery.conf
is:
standby_mode = ’on’
primary_conninfo = ’host=192.168.1.50 port=5432 user=foo password=foopass’
restore_command = ’cp /path/to/archive/%f %p’
archive_cleanup_command = ’pg_archivecleanup /path/to/archive %r’
You can have any number of standby servers, but if you use streaming replication, make sure you set
max_wal_senders
high enough in the primary to allowthem to be connected simultaneously.
25.2.5. Streaming Replication
Streaming replication allows a standby server to stay more up-to-date than is possible withfile-based
log shipping. The standby connects to the primary, which streams WAL records to the standby as
they’re generated, without waiting for the WAL file to be filled.
Streaming replication is asynchronous by default (see Section 25.2.8), in which case there is a small
delay between committing a transaction in the primary and the changes becoming visible in the
standby. This delay is however much smaller than with file-based log shipping, typically under one
secondassumingthe standbyis powerfulenoughto keepupwith the load. With streaming replication,
archive_timeout
is not required to reduce the data loss window.
If you use streaming replication without file-based continuous archiving, the server might recycle
old WAL segments before the standby has received them. If this occurs, the standby will need to be
reinitialized from a new base backup. You can avoid this by setting
wal_keep_segments
to a value
large enough to ensure that WAL segments are not recycled too early, or by configuring a replication
slot for the standby. If you set up a WAL archive that’s accessible from the standby, these solutions
are not required, since the standby can always use the archive to catch up provided it retains enough
segments.
To use streaming replication, set up a file-based log-shipping standby server as described in Sec-
tion 25.2. The step that turns a file-based log-shipping standby into streaming replication standby is
setting
primary_conninfo
setting in the
recovery.conf
file to point to the primary server. Set
listen_addresses and authentication options (see
pg_hba.conf
)on the primary so that the standby
server canconnecttothe
replication
pseudo-databaseonthe primary server (see Section25.2.5.1).
587
Documents you may be interested
Documents you may be interested