提交 841e4b20 编写于 作者: P Peter Eisentraut

Put the disk information all in one chapter.

上级 cda776e6
<!--
$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;
&regress;
&release;
......
<!--
$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
......
<!-- $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">
......
<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:
-->
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册