Tom Lane wrote:
> Bruce Momjian <[email protected]> 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
[email protected] | (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>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
