Put the disk information all in one chapter.
This commit is contained in:
Peter Eisentraut
parent
cda776e613
commit
841e4b2089
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.38 2002/09/25 21:16:10 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.39 2002/10/16 22:06:33 petere Exp $
|
||||
-->
|
||||
|
||||
<book id="admin">
|
||||
@ -34,7 +34,6 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.38 2002/09/25 21:16:10
|
||||
&monitoring;
|
||||
&diskusage;
|
||||
&wal;
|
||||
&recovery;
|
||||
®ress;
|
||||
&release;
|
||||
|
||||
|
||||
@ -1,12 +1,20 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.5 2002/09/21 18:32:52 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.6 2002/10/16 22:06:33 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="diskusage">
|
||||
<title>Monitoring Disk Usage</title>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<sect1 id="disk-usage">
|
||||
<title>Monitoring Disk Usage</Title>
|
||||
<title>Determining Disk Usage</Title>
|
||||
|
||||
<indexterm zone="disk-usage">
|
||||
<primary>disk usage</primary>
|
||||
@ -96,6 +104,40 @@ play-# ORDER BY relpages DESC;
|
||||
shows disk usage for each database.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="disk-full">
|
||||
<title>Disk Full Failure</title>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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 <application>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 <application>initdb</> documentation and <xref
|
||||
linkend="manage-ag-alternate-locs"> for more information.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
Some file systems perform badly when they are almost full, so do
|
||||
not wait until the disk is full to take action.
|
||||
</para>
|
||||
</tip>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.23 2002/09/25 21:16:10 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.24 2002/10/16 22:06:33 petere Exp $ -->
|
||||
|
||||
<!entity history SYSTEM "history.sgml">
|
||||
<!entity info SYSTEM "info.sgml">
|
||||
@ -49,7 +49,6 @@
|
||||
<!entity maintenance SYSTEM "maintenance.sgml">
|
||||
<!entity manage-ag SYSTEM "manage-ag.sgml">
|
||||
<!entity monitoring SYSTEM "monitoring.sgml">
|
||||
<!entity recovery SYSTEM "recovery.sgml">
|
||||
<!entity regress SYSTEM "regress.sgml">
|
||||
<!entity release SYSTEM "release.sgml">
|
||||
<!entity runtime SYSTEM "runtime.sgml">
|
||||
|
||||
@ -1,104 +0,0 @@
|
||||
<chapter Id="failure">
|
||||
<title>Database Failures</title>
|
||||
|
||||
<para>
|
||||
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 <emphasis>before</emphasis> the failure occurs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<sect1 id="failure-disk-full">
|
||||
<title>Disk Filled</title>
|
||||
|
||||
<para>
|
||||
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 <xref linkend="wal-configuration">) and then restart the
|
||||
<application>postmaster</application> to recover from this condition.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="failure-disk-failed">
|
||||
<title>Disk Failed</title>
|
||||
|
||||
<para>
|
||||
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
|
||||
<application>pg_dumpall</application>, and updates to the database
|
||||
occurring after the database installation was dumped will be lost.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<!--
|
||||
<sect1>
|
||||
<title>File Corrupted</title>
|
||||
|
||||
<para>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Table Corrupted</title>
|
||||
|
||||
<para>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title></title>
|
||||
|
||||
<para>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title></title>
|
||||
|
||||
<para>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title></title>
|
||||
|
||||
<para>
|
||||
</para>
|
||||
</sect1>
|
||||
-->
|
||||
|
||||
</chapter>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
mode:sgml
|
||||
sgml-omittag:nil
|
||||
sgml-shorttag:t
|
||||
sgml-minimize-attributes:nil
|
||||
sgml-always-quote-attributes:t
|
||||
sgml-indent-step:1
|
||||
sgml-indent-data:t
|
||||
sgml-parent-document: ("postgres.sgml" "set" "book" "chapter")
|
||||
sgml-default-dtd-file:"./reference.ced"
|
||||
sgml-exposed-tags:nil
|
||||
sgml-local-ecat-files:nil
|
||||
End:
|
||||
-->
|
||||
Loading…
x
Reference in New Issue
Block a user