Monitoring Disk Usage
+ This chapter discusses how to monitor the disk usage of a PostgreSQL
+ database system. In the current release, the database administrator
+ does not have much control over the on-disk storage layout, so this
+ chapter is mostly informative and can give you some ideas how to
+ manage the disk usage with operating system tools.
+
+
-
<span class="marked">Monitor</span>ing Disk Usage
+
<span class="marked">Determin</span>ing Disk Usage
shows disk usage for each database.
+
+
+
Disk Full Failure
+
+ The most important disk monitoring task of a database administrator
+ is to make sure the disk doesn't grow full. A filled data disk may
+ result in subsequent corruption of database indexes, but not of the
+ fundamental data tables. If the WAL files are on the same disk (as
+ is the case for a default configuration) then a filled disk during
+ database initialization may result in corrupted or incomplete WAL
+ files. This failure condition is detected and the database server
+ will refuse to start up.
+
+
+ If you cannot free up additional space on the disk by deleting
+ other things you can move some of the database files to other file
+ systems and create a symlink from the original location. But
+ note that
pg_dump cannot save the location layout+ information of such a setup; a restore would put everything back in
+ one place. To avoid running out of disk space, you can place the
+ WAL files or individual databases in other locations while creating
+ them. See the
initdb documentation and
+ linkend="manage-ag-alternate-locs"> for more information.
+
+
+
+ Some file systems perform badly when they are almost full, so do
+ not wait until the disk is full to take action.
+
+
+
+
-
+++ /dev/null
-
-
Database Failures
-
- Database failures (or the possibility of such) must be assumed to be
- lurking, ready to strike at some time in the future. A prudent
- database administrator will plan for the inevitability of failures
- of all possible kinds, and will have appropriate plans and
- procedures in place before the failure occurs.
-
-
- Database recovery is necessary in the event of hardware or software
- failure. There are several categories of failures; some of these
- require relatively minor adjustments to the database, while others
- may depend on the existence of previously prepared database dumps
- and other recovery data sets. It should be emphasized that if your
- data is important and/or difficult to regenerate, then you should
- have considered and prepared for various failure scenarios.
-
-
-
-
Disk Filled
-
- A filled data disk may result in subsequent corruption of database
- indexes, but not of the fundamental data tables. If the WAL files
- are on the same disk (as is the case for a default configuration)
- then a filled disk during database initialization may result in
- corrupted or incomplete WAL files. This failure condition is
- detected and the database will refuse to start up. You must free
- up additional space on the disk (or move the WAL area to another
- disk; see ) and then restart the
-
postmaster to recover from this condition.
-
-
-
-
-
Disk Failed
-
- Failure of any disk (or of a logical storage device such as a RAID
- subsystem) involved with an active database will require
- that the database be recovered from a previously prepared database
- dump. This dump must be prepared using
-
pg_dumpall, and updates to the database
- occurring after the database installation was dumped will be lost.
-
-
-
-
-
-
-
-
projects / postgresql.git / commitdiff