# 29.1\. 可靠性 可靠性是任何嚴肅的數據庫系統的重要屬性，PostgreSQL盡一切可能來保證可靠的操作。 可靠性操作的一個方面是所有已提交的數據都應該存儲在一個非易失的區域，這樣就不會因為電力失效、 操作系統崩潰、硬件失效(除了非易失區域自身失效之外)等原因導致數據丟失。向計算機的永久存儲 (磁盤驅動器或者等效的東西)成功寫入數據通常可以滿足這個要求。實際上，即使計算機完全失效， 只要磁盤驅動器生存下來，那么它們就可以移動到另外一臺類似硬件的計算機上， 而所有已經提交的事務將保持原狀。 周期性地強制數據寫入磁盤盤片看上去像一件簡單的操作，但實際上不是。 因為磁盤驅動器比內存和 CPU 要慢許多，在計算機的主存和磁盤盤片之間存在多層緩沖。 首先，有操作系統的緩沖區內存，它緩沖常用的磁盤塊并且組合對磁盤寫入的請求。幸運的是， 所有操作系統都給予應用一個強制從緩沖區寫入磁盤的方法，PostgreSQL 使用了該特性(參閱[wal_sync_method](#calibre_link-1432)參數)。 然后，在磁盤驅動器的控制器上可能還有一個緩沖；特別是在RAID控制卡上更為常見。 這些緩沖區中，有些是_透過式寫入_，意思是寫入動作在到達的同時寫入到磁盤上。 其它則是_回寫式寫入_，意思是數據將在稍后寫入驅動器。這樣的緩沖區是可靠性的危害， 因為磁盤控制器上的內存是易失的，在發生電力失效的情況下會丟失其中的內容。 好一些的控制器卡備有_電池備份單元_(BBUs)， 可以在系統電力失效的情況下提供電力。在電力恢復之后，這些數據將會被寫入磁盤驅動器。 最后，大多數磁盤驅動器自身也有緩沖區。有些是透過式的，有些是回寫式的。 和磁盤控制器一樣，回寫式的磁盤緩沖區也存在數據丟失的問題。 消費級別的 IDE 和 SATA 驅動器特別容易包含回寫式緩沖，在掉電的情況下很容易丟失數據。 很多固態磁盤(SSD)也有易失的回寫式緩沖。 這些緩存通常可以禁用；然而，這樣做的方法會因操作系統和驅動類型而不同。 * 在Linux上，IDE和SATA驅動器可以使用`hdparm -I`查詢； 如果在`Write cache`后面有一個`*`則寫緩存是開啟的。`hdparm -W 0` 可以用來關閉寫緩存。SCSI驅動器可以使用[sdparm](http://sg.danny.cz/sg/sdparm.html) 查詢。使用`sdparm --get=WCE`來檢查寫緩存是否打開，使用`sdparm --clear=WCE` 來關閉寫緩存。 * 在FreeBSD上，IDE驅動器可以使用`atacontrol`查詢， 寫緩存在`/boot/loader.conf`里用`hw.ata.wc=0`來關閉； SCSI驅動器可以使用`camcontrol identify`查詢，寫緩存也同時查詢， 并且當可用時使用 `sdparm`改變狀態。 * 在Solaris上，磁盤寫緩存通過`format -e`來控制。 （Solaris ZFS文件系統對于打開磁盤寫緩存是安全的，因為它發行自己的磁盤緩存刷新命令。） * 在Windows上，如果`wal_sync_method`為`open_datasync`（默認值）， 寫緩存可以通過取消選中`My Computer\Open\``_disk drive_`\Properties\Hardware\Properties\Policies\Enable write caching on the disk 來禁用。或者，設置`wal_sync_method`為`fsync`或`fsync_writethrough` 來阻止寫緩存。 * 在Mac OS X上，寫緩存可以通過設置`wal_sync_method` 為`fsync_writethrough`來阻止。 最近的SATA驅動器（跟隨ATAPI-6或以后的）提供一個驅動器緩存刷新命令(`FLUSH CACHE EXT`)， 而SCSI驅動器長期以來支持一個類似的命令`SYNCHRONIZE CACHE`。這些命令不能直接訪問PostgreSQL， 但是某些文件系統（例如，ZFS，ext4）可以使用它們來刷新數據到啟用了回寫的驅動器上的盤片上。 不幸的是，這樣的文件系統只有在組合電池備份單元(BBU)磁盤驅動器時行為有效。在這樣的設置中， 同步命令強制所有數據從驅動器緩存到磁盤，消除BBU的好處。你可以運行[pg_test_fsync](#calibre_link-1619) 程序來查看你是否受影響。如果你受到影響，BBU的性能優勢可以通過在文件系統中關掉寫屏障或重新配置磁盤控制器重新獲得， 如果這是一個選項。如果關閉了寫屏障，確保電池仍然運行；失效的電池可能導致數據丟失。 希望文件系統和磁盤控制器設計將最終解決這個次優的行為。 在操作系統向存儲硬件發出一個寫請求的時候，它沒有什么好辦法來保證數據真正到達非易失的存儲區域。 實際上，確保所有存儲部件都保證數據和文件系統元數據的完整性是管理員的責任。 應該避免使用沒有電池供電的回寫緩沖磁盤控制器。在驅動級別， 如果驅動器不能保證在關閉(掉電)之前寫入數據，那么應該關閉回寫緩沖。 如果你使用SSD，要知道這些默認不尊重緩存刷新命令。你可以使用 [`diskchecker.pl`](http://brad.livejournal.com/2116715.html) 測試可靠的I/O子系統的行為。 另外一個數據丟失的風險來自磁盤盤片寫操作自身。磁盤盤片會被分割為段，通常每段 512 字節。 每次物理讀寫都對整個段進行操作。當一個寫操作到達磁盤的時候，它可能是512字節的某些整數倍 （PostgreSQL通常一次寫入8192字節，或者16段），而寫入操作可能因為電力失效而隨時失敗， 意味著某些 512 字節的段寫入了，而另一些則沒有。為了避免這個問題，PostgreSQL 在修改磁盤上的實際頁面_之前_周期性地把整個頁面的影像寫入永久WAL存儲。這樣， 在崩潰恢復的時候，PostgreSQL就可以從WAL中恢復部分寫入的頁面。 如果你有文件系統(比如ZFS)自身能夠避免部分頁面寫入，你可以通過關閉[full_page_writes](#calibre_link-1135) 參數來關閉頁面影像功能。電池備份單元(BBU)磁盤控制器不能阻止部分頁面寫入， 除非他們保證數據以完整頁面（8kB）寫入BBU。 PostgreSQL也能阻止某些因為硬件錯誤或介質失效可能發生在存儲驅動器上的數據損壞， 比如讀/寫垃圾數據。 * 在WAL文件中的每個單獨的記錄受CRC-32 (32-bit)校驗保護，這樣允許我們判斷記錄內容是否正確。 當我們在崩潰恢復時寫入每個WAL記錄和檢查、歸檔記錄和復制時設置CRC值。 * 數據頁不是當前校驗和的，盡管在WAL記錄中的整個頁面圖像記錄將受到保護。 為未來使用數據頁校驗和特性，數據頁有一個16位字段可用。 * 內部數據結構例如`pg_clog`, `pg_subtrans`, `pg_multixact`, `pg_serial`, `pg_notify`, `pg_stat`, `pg_snapshots` 不是直接校驗和的， 也不是通過全頁面寫入受到保護的頁面。然而，這樣的數據結構具有持久性， WAL記錄書面允許最近的改變在崩潰恢復時精確重建并且這些WAL記錄正如上述討論的那樣受到保護。 * 在`pg_twophase`中的個人狀態文件受到CRC-32保護。 * 臨時數據文件用于較大的SQL查詢，具體化和中間結果不是當前校驗和的， 也不會WAL記錄被寫入修改這些文件。 PostgreSQL不預防矯正內存錯誤，假設您將使用具有工業標準糾錯編碼(ECC) 的內存操作或更好的保護。