Re: pgsql: Mention tablespaces as a problem for using file - Mailing list pgsql-committers

From Bruce Momjian
Subject Re: pgsql: Mention tablespaces as a problem for using file
Date
Msg-id 200503171538.j2HFcT411160@candle.pha.pa.us
Whole thread Raw
In response to Re: pgsql: Mention tablespaces as a problem for using file system snapshots.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I assume many more people are using tablespaces than moving pg_xlog.
>
> I don't believe that premise.  Relocating xlog is an essential step
> for high-performance databases ... using tablespaces isn't.
>
> > You want two examples in that sentence?
>
> I think the xlog case needs to be mentioned, and I think there needs to
> be specific reference to a multi-volume situation.  "Using tablespaces"
> doesn't necessarily mean the database is spread across multiple disks.
>
> In short, I thought the original wording was better.
>

OK, I broke out the examples into a separate sentence.  I also update
the rsync mention.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.58
diff -c -c -r2.58 backup.sgml
*** doc/src/sgml/backup.sgml    17 Mar 2005 05:10:11 -0000    2.58
--- doc/src/sgml/backup.sgml    17 Mar 2005 15:26:23 -0000
***************
*** 364,372 ****
    </para>

    <para>
!    If your database is spread across multiple volumes (for example,
!    if you are using tablespaces) there may not be any way
!    to obtain exactly-simultaneous frozen snapshots of all the volumes.
     Read your file system documentation very carefully before trusting
     to the consistent-snapshot technique in such situations.  The safest
     approach is to shut down the database server for long enough to
--- 364,374 ----
    </para>

    <para>
!    If your database is spread across multiple file systems there may not
!    be any way to obtain exactly-simultaneous frozen snapshots of all
!    the volumes.  For example, if your data files and WAL log on different
!    file disks, or if tablespaces are on different file systems, it might
!    not be possible to use snapshots because the snapshots must be simultaneous.
     Read your file system documentation very carefully before trusting
     to the consistent-snapshot technique in such situations.  The safest
     approach is to shut down the database server for long enough to
***************
*** 375,385 ****

    <para>
     Another option is to use <application>rsync</> to perform a file
!    system backup.  First, while the database server is running,
!    run <application>rsync</>, then shut down the database
!    server and perform a second <application>rsync</>, then
!    restart the database server.  This allows a file system backup to be
!    performed with minimal downtime.
    </para>

    <para>
--- 377,388 ----

    <para>
     Another option is to use <application>rsync</> to perform a file
!    system backup.  This is done by first running <application>rsync</>
!    while the database server is running, then shutting down the database
!    server just long enough to do a second <application>rsync</>.  The
!    second <application>rsync</> will be much quicker than the first,
!    but will be consistent because the server was down.  This method
!    allows a file system backup to be performed with minimal downtime.
    </para>

    <para>

pgsql-committers by date:

Previous
From: tgl@svr1.postgresql.org (Tom Lane)
Date:
Subject: pgsql: Update obsolete comment.
Next
From: momjian@svr1.postgresql.org (Bruce Momjian)
Date:
Subject: pgsql: Update file system snapshot docs.