← Back to branch summary

~ubuntu-branches/ubuntu/oneiric/postgresql-9.1/oneiric-security

« back to all changes in this revision

Viewing changes to doc/src/sgml/html/wal-reliability.html

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2011-05-11 10:41:53 UTC
  • Revision ID: james.westby@ubuntu.com-20110511104153-psbh2o58553fv1m0
Tags: upstream-9.1~beta1
Import upstream version 9.1~beta1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/sgml/html/wal-reliability.html
 
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 
2
<HTML
 
3
><HEAD
 
4
><TITLE
 
5
>Reliability</TITLE
 
6
><META
 
7
NAME="GENERATOR"
 
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
 
9
REV="MADE"
 
10
HREF="mailto:pgsql-docs@postgresql.org"><LINK
 
11
REL="HOME"
 
12
TITLE="PostgreSQL 9.1beta1 Documentation"
 
13
HREF="index.html"><LINK
 
14
REL="UP"
 
15
TITLE="Reliability and the Write-Ahead Log"
 
16
HREF="wal.html"><LINK
 
17
REL="PREVIOUS"
 
18
TITLE="Reliability and the Write-Ahead Log"
 
19
HREF="wal.html"><LINK
 
20
REL="NEXT"
 
21
TITLE="Write-Ahead Logging (WAL)"
 
22
HREF="wal-intro.html"><LINK
 
23
REL="STYLESHEET"
 
24
TYPE="text/css"
 
25
HREF="stylesheet.css"><META
 
26
HTTP-EQUIV="Content-Type"
 
27
CONTENT="text/html; charset=ISO-8859-1"><META
 
28
NAME="creation"
 
29
CONTENT="2011-04-27T21:20:33"></HEAD
 
30
><BODY
 
31
CLASS="SECT1"
 
32
><DIV
 
33
CLASS="NAVHEADER"
 
34
><TABLE
 
35
SUMMARY="Header navigation table"
 
36
WIDTH="100%"
 
37
BORDER="0"
 
38
CELLPADDING="0"
 
39
CELLSPACING="0"
 
40
><TR
 
41
><TH
 
42
COLSPAN="5"
 
43
ALIGN="center"
 
44
VALIGN="bottom"
 
45
><A
 
46
HREF="index.html"
 
47
>PostgreSQL 9.1beta1 Documentation</A
 
48
></TH
 
49
></TR
 
50
><TR
 
51
><TD
 
52
WIDTH="10%"
 
53
ALIGN="left"
 
54
VALIGN="top"
 
55
><A
 
56
TITLE="Reliability and the Write-Ahead Log"
 
57
HREF="wal.html"
 
58
ACCESSKEY="P"
 
59
>Prev</A
 
60
></TD
 
61
><TD
 
62
WIDTH="10%"
 
63
ALIGN="left"
 
64
VALIGN="top"
 
65
><A
 
66
TITLE="Reliability and the Write-Ahead Log"
 
67
HREF="wal.html"
 
68
>Fast Backward</A
 
69
></TD
 
70
><TD
 
71
WIDTH="60%"
 
72
ALIGN="center"
 
73
VALIGN="bottom"
 
74
>Chapter 29. Reliability and the Write-Ahead Log</TD
 
75
><TD
 
76
WIDTH="10%"
 
77
ALIGN="right"
 
78
VALIGN="top"
 
79
><A
 
80
TITLE="Reliability and the Write-Ahead Log"
 
81
HREF="wal.html"
 
82
>Fast Forward</A
 
83
></TD
 
84
><TD
 
85
WIDTH="10%"
 
86
ALIGN="right"
 
87
VALIGN="top"
 
88
><A
 
89
TITLE="Write-Ahead Logging (WAL)"
 
90
HREF="wal-intro.html"
 
91
ACCESSKEY="N"
 
92
>Next</A
 
93
></TD
 
94
></TR
 
95
></TABLE
 
96
><HR
 
97
ALIGN="LEFT"
 
98
WIDTH="100%"></DIV
 
99
><DIV
 
100
CLASS="SECT1"
 
101
><H1
 
102
CLASS="SECT1"
 
103
><A
 
104
NAME="WAL-RELIABILITY"
 
105
>29.1. Reliability</A
 
106
></H1
 
107
><P
 
108
>   Reliability is an important property of any serious database
 
109
   system, and <SPAN
 
110
CLASS="PRODUCTNAME"
 
111
>PostgreSQL</SPAN
 
112
> does everything possible to
 
113
   guarantee reliable operation. One aspect of reliable operation is
 
114
   that all data recorded by a committed transaction should be stored
 
115
   in a nonvolatile area that is safe from power loss, operating
 
116
   system failure, and hardware failure (except failure of the
 
117
   nonvolatile area itself, of course).  Successfully writing the data
 
118
   to the computer's permanent storage (disk drive or equivalent)
 
119
   ordinarily meets this requirement.  In fact, even if a computer is
 
120
   fatally damaged, if the disk drives survive they can be moved to
 
121
   another computer with similar hardware and all committed
 
122
   transactions will remain intact.
 
123
  </P
 
124
><P
 
125
>   While forcing data to the disk platters periodically might seem like
 
126
   a simple operation, it is not. Because disk drives are dramatically
 
127
   slower than main memory and CPUs, several layers of caching exist
 
128
   between the computer's main memory and the disk platters.
 
129
   First, there is the operating system's buffer cache, which caches
 
130
   frequently requested disk blocks and combines disk writes. Fortunately,
 
131
   all operating systems give applications a way to force writes from
 
132
   the buffer cache to disk, and <SPAN
 
133
CLASS="PRODUCTNAME"
 
134
>PostgreSQL</SPAN
 
135
> uses those
 
136
   features.  (See the <A
 
137
HREF="runtime-config-wal.html#GUC-WAL-SYNC-METHOD"
 
138
>wal_sync_method</A
 
139
> parameter
 
140
   to adjust how this is done.)
 
141
  </P
 
142
><P
 
143
>   Next, there might be a cache in the disk drive controller; this is
 
144
   particularly common on <ACRONYM
 
145
CLASS="ACRONYM"
 
146
>RAID</ACRONYM
 
147
> controller cards. Some of
 
148
   these caches are <I
 
149
CLASS="FIRSTTERM"
 
150
>write-through</I
 
151
>, meaning writes are sent
 
152
   to the drive as soon as they arrive. Others are
 
153
   <I
 
154
CLASS="FIRSTTERM"
 
155
>write-back</I
 
156
>, meaning data is sent to the drive at
 
157
   some later time. Such caches can be a reliability hazard because the
 
158
   memory in the disk controller cache is volatile, and will lose its
 
159
   contents in a power failure.  Better controller cards have
 
160
   <I
 
161
CLASS="FIRSTTERM"
 
162
>battery-backup units</I
 
163
> (<ACRONYM
 
164
CLASS="ACRONYM"
 
165
>BBU</ACRONYM
 
166
>s), meaning
 
167
   the card has a battery that
 
168
   maintains power to the cache in case of system power loss.  After power
 
169
   is restored the data will be written to the disk drives.
 
170
  </P
 
171
><P
 
172
>   And finally, most disk drives have caches. Some are write-through
 
173
   while some are write-back, and the same concerns about data loss
 
174
   exist for write-back drive caches as for disk controller
 
175
   caches.  Consumer-grade IDE and SATA drives are particularly likely
 
176
   to have write-back caches that will not survive a power failure.  Many
 
177
   solid-state drives (SSD) also have volatile write-back caches.
 
178
  </P
 
179
><P
 
180
>   These caches can typically be disabled; however, the method for doing
 
181
   this varies by operating system and drive type:
 
182
  </P
 
183
><P
 
184
></P
 
185
><UL
 
186
><LI
 
187
><P
 
188
>        On <SPAN
 
189
CLASS="PRODUCTNAME"
 
190
>Linux</SPAN
 
191
>, IDE drives can be queried using
 
192
        <TT
 
193
CLASS="COMMAND"
 
194
>hdparm -I</TT
 
195
>; write caching is enabled if there is
 
196
        a <TT
 
197
CLASS="LITERAL"
 
198
>*</TT
 
199
> next to <TT
 
200
CLASS="LITERAL"
 
201
>Write cache</TT
 
202
>.  <TT
 
203
CLASS="COMMAND"
 
204
>hdparm -W</TT
 
205
>
 
206
        can be used to turn off write caching.  SCSI drives can be queried
 
207
        using <A
 
208
HREF="http://sg.danny.cz/sg/sdparm.html"
 
209
TARGET="_top"
 
210
><SPAN
 
211
CLASS="APPLICATION"
 
212
>sdparm</SPAN
 
213
></A
 
214
>.
 
215
        Use <TT
 
216
CLASS="COMMAND"
 
217
>sdparm --get=WCE</TT
 
218
> to check
 
219
        whether the write cache is enabled and <TT
 
220
CLASS="COMMAND"
 
221
>sdparm --clear=WCE</TT
 
222
>
 
223
        to disable it.
 
224
      </P
 
225
></LI
 
226
><LI
 
227
><P
 
228
>        On <SPAN
 
229
CLASS="PRODUCTNAME"
 
230
>FreeBSD</SPAN
 
231
>, IDE drives can be queried using
 
232
        <TT
 
233
CLASS="COMMAND"
 
234
>atacontrol</TT
 
235
> and write caching turned off using
 
236
        <TT
 
237
CLASS="LITERAL"
 
238
>hw.ata.wc=0</TT
 
239
> in <TT
 
240
CLASS="FILENAME"
 
241
>/boot/loader.conf</TT
 
242
>;
 
243
        SCSI drives use <TT
 
244
CLASS="COMMAND"
 
245
>sdparm</TT
 
246
>.
 
247
      </P
 
248
></LI
 
249
><LI
 
250
><P
 
251
>        On <SPAN
 
252
CLASS="PRODUCTNAME"
 
253
>Solaris</SPAN
 
254
>, the disk write cache is controlled by
 
255
        <A
 
256
HREF="http://www.sun.com/bigadmin/content/submitted/format_utility.jsp"
 
257
TARGET="_top"
 
258
><TT
 
259
CLASS="LITERAL"
 
260
>format -e</TT
 
261
></A
 
262
>.
 
263
        (The Solaris <ACRONYM
 
264
CLASS="ACRONYM"
 
265
>ZFS</ACRONYM
 
266
> file system is safe with disk write-cache
 
267
        enabled because it issues its own disk cache flush commands.)
 
268
      </P
 
269
></LI
 
270
><LI
 
271
><P
 
272
>        On <SPAN
 
273
CLASS="PRODUCTNAME"
 
274
>Windows</SPAN
 
275
>, if <TT
 
276
CLASS="VARNAME"
 
277
>wal_sync_method</TT
 
278
> is
 
279
        <TT
 
280
CLASS="LITERAL"
 
281
>open_datasync</TT
 
282
> (the default), write caching can be disabled
 
283
        by unchecking <TT
 
284
CLASS="LITERAL"
 
285
>My Computer\Open\<TT
 
286
CLASS="REPLACEABLE"
 
287
><I
 
288
>disk drive</I
 
289
></TT
 
290
>\Properties\Hardware\Properties\Policies\Enable write caching on the disk</TT
 
291
>.
 
292
        Alternatively, set <TT
 
293
CLASS="VARNAME"
 
294
>wal_sync_method</TT
 
295
> to
 
296
        <TT
 
297
CLASS="LITERAL"
 
298
>fsync</TT
 
299
> or <TT
 
300
CLASS="LITERAL"
 
301
>fsync_writethrough</TT
 
302
>, which prevent
 
303
        write caching.
 
304
      </P
 
305
></LI
 
306
><LI
 
307
><P
 
308
>        On <SPAN
 
309
CLASS="PRODUCTNAME"
 
310
>Mac OS X</SPAN
 
311
>, write caching can be prevented by
 
312
        setting <TT
 
313
CLASS="VARNAME"
 
314
>wal_sync_method</TT
 
315
> to <TT
 
316
CLASS="LITERAL"
 
317
>fsync_writethrough</TT
 
318
>.
 
319
      </P
 
320
></LI
 
321
></UL
 
322
><P
 
323
>   Recent SATA drives (those following <ACRONYM
 
324
CLASS="ACRONYM"
 
325
>ATAPI-6</ACRONYM
 
326
> or later)
 
327
   offer a drive cache flush command (<TT
 
328
CLASS="COMMAND"
 
329
>FLUSH CACHE EXT</TT
 
330
>),
 
331
   while SCSI drives have long supported a similar command
 
332
   <TT
 
333
CLASS="COMMAND"
 
334
>SYNCHRONIZE CACHE</TT
 
335
>.  These commands are not directly
 
336
   accessible to <SPAN
 
337
CLASS="PRODUCTNAME"
 
338
>PostgreSQL</SPAN
 
339
>, but some file systems
 
340
   (e.g., <ACRONYM
 
341
CLASS="ACRONYM"
 
342
>ZFS</ACRONYM
 
343
>, <ACRONYM
 
344
CLASS="ACRONYM"
 
345
>ext4</ACRONYM
 
346
>) can use them to flush
 
347
   data to the platters on write-back-enabled drives.  Unfortunately, such
 
348
   file systems behave suboptimally when combined with battery-backup unit
 
349
   (<ACRONYM
 
350
CLASS="ACRONYM"
 
351
>BBU</ACRONYM
 
352
>) disk controllers.  In such setups, the synchronize
 
353
   command forces all data from the controller cache to the disks,
 
354
   eliminating much of the benefit of the BBU.  You can run the
 
355
   <A
 
356
HREF="pgtestfsync.html"
 
357
>Section F.34</A
 
358
> module to see
 
359
   if you are affected.  If you are affected, the performance benefits
 
360
   of the BBU can be regained by turning off write barriers in
 
361
   the file system or reconfiguring the disk controller, if that is
 
362
   an option.  If write barriers are turned off, make sure the battery
 
363
   remains functional; a faulty battery can potentially lead to data loss.
 
364
   Hopefully file system and disk controller designers will eventually
 
365
   address this suboptimal behavior.
 
366
  </P
 
367
><P
 
368
>   When the operating system sends a write request to the storage hardware,
 
369
   there is little it can do to make sure the data has arrived at a truly
 
370
   non-volatile storage area. Rather, it is the
 
371
   administrator's responsibility to make certain that all storage components
 
372
   ensure data integrity.  Avoid disk controllers that have non-battery-backed
 
373
   write caches.  At the drive level, disable write-back caching if the
 
374
   drive cannot guarantee the data will be written before shutdown.
 
375
   If you use SSDs, be aware that many of these do not honor cache flush
 
376
   commands by default.
 
377
   You can test for reliable I/O subsystem behavior using <A
 
378
HREF="http://brad.livejournal.com/2116715.html"
 
379
TARGET="_top"
 
380
><TT
 
381
CLASS="FILENAME"
 
382
>diskchecker.pl</TT
 
383
></A
 
384
>.
 
385
  </P
 
386
><P
 
387
>   Another risk of data loss is posed by the disk platter write
 
388
   operations themselves. Disk platters are divided into sectors,
 
389
   commonly 512 bytes each.  Every physical read or write operation
 
390
   processes a whole sector.
 
391
   When a write request arrives at the drive, it might be for some multiple
 
392
   of 512 bytes (<SPAN
 
393
CLASS="PRODUCTNAME"
 
394
>PostgreSQL</SPAN
 
395
> typically writes 8192 bytes, or
 
396
   16 sectors, at a time), and the process of writing could fail due
 
397
   to power loss at any time, meaning some of the 512-byte sectors were
 
398
   written while others were not.  To guard against such failures,
 
399
   <SPAN
 
400
CLASS="PRODUCTNAME"
 
401
>PostgreSQL</SPAN
 
402
> periodically writes full page images to
 
403
   permanent WAL storage <SPAN
 
404
CLASS="emphasis"
 
405
><I
 
406
CLASS="EMPHASIS"
 
407
>before</I
 
408
></SPAN
 
409
> modifying the actual page on
 
410
   disk. By doing this, during crash recovery <SPAN
 
411
CLASS="PRODUCTNAME"
 
412
>PostgreSQL</SPAN
 
413
> can
 
414
   restore partially-written pages from WAL.  If you have file-system software
 
415
   that prevents partial page writes (e.g., ZFS),  you can turn off
 
416
   this page imaging by turning off the <A
 
417
HREF="runtime-config-wal.html#GUC-FULL-PAGE-WRITES"
 
418
>full_page_writes</A
 
419
> parameter. Battery-Backed Unit
 
420
   (BBU) disk controllers do not prevent partial page writes unless
 
421
   they guarantee that data is written to the BBU as full (8kB) pages.
 
422
  </P
 
423
></DIV
 
424
><DIV
 
425
CLASS="NAVFOOTER"
 
426
><HR
 
427
ALIGN="LEFT"
 
428
WIDTH="100%"><TABLE
 
429
SUMMARY="Footer navigation table"
 
430
WIDTH="100%"
 
431
BORDER="0"
 
432
CELLPADDING="0"
 
433
CELLSPACING="0"
 
434
><TR
 
435
><TD
 
436
WIDTH="33%"
 
437
ALIGN="left"
 
438
VALIGN="top"
 
439
><A
 
440
HREF="wal.html"
 
441
ACCESSKEY="P"
 
442
>Prev</A
 
443
></TD
 
444
><TD
 
445
WIDTH="34%"
 
446
ALIGN="center"
 
447
VALIGN="top"
 
448
><A
 
449
HREF="index.html"
 
450
ACCESSKEY="H"
 
451
>Home</A
 
452
></TD
 
453
><TD
 
454
WIDTH="33%"
 
455
ALIGN="right"
 
456
VALIGN="top"
 
457
><A
 
458
HREF="wal-intro.html"
 
459
ACCESSKEY="N"
 
460
>Next</A
 
461
></TD
 
462
></TR
 
463
><TR
 
464
><TD
 
465
WIDTH="33%"
 
466
ALIGN="left"
 
467
VALIGN="top"
 
468
>Reliability and the Write-Ahead Log</TD
 
469
><TD
 
470
WIDTH="34%"
 
471
ALIGN="center"
 
472
VALIGN="top"
 
473
><A
 
474
HREF="wal.html"
 
475
ACCESSKEY="U"
 
476
>Up</A
 
477
></TD
 
478
><TD
 
479
WIDTH="33%"
 
480
ALIGN="right"
 
481
VALIGN="top"
 
482
>Write-Ahead Logging (<ACRONYM
 
483
CLASS="ACRONYM"
 
484
>WAL</ACRONYM
 
485
>)</TD
 
486
></TR
 
487
></TABLE
 
488
></DIV
 
489
></BODY
 
490
></HTML
 
491
>
 
 
b'\\ No newline at end of file'