資料庫PostrageSQL 非同步提交

2021-10-14 07:41:58 字數 1712 閱讀 1571

非同步提交是乙個允許事務能更快完成的選項,代價是在資料庫崩潰時最近的事務會丟失。在很多應用中這是乙個可接受的交換。

如前一節所述,事務提交通常是同步的:伺服器等到事務的wal記錄被刷寫到持久儲存之後才向客戶端返回成功指示。因此客戶端可以確保那些報告已被提交的事務確會被儲存,即便隨後馬上發生了一次伺服器崩潰。但是,對於短事務來說這種延遲是其總執行時間的主要部分。選擇非同步提交模式意味著伺服器將在事務被邏輯上提交後立刻返回成功,而此時由它生成的wal記錄還沒有被真正地寫到磁碟上。這將為小型事務的生產力產生顯著地提公升。

非同步提交會帶來資料丟失的風險。在向客戶端報告事務完成到事務真正被提交(即能保證伺服器崩潰時它也不會被丟失)之間有乙個短的時間視窗。因此如果客戶端將會做一些要求其事務被記住的外部動作,就不應該用非同步提交。例如,乙個銀行肯定不會使用非同步提交事務來記錄一台atm的現金分發。但是在很多情境中不需要這種強的保證,例如事件日誌。

使用非同步提交帶來的風險是資料丟失,而不是資料損壞。如果資料庫可能崩潰,它會通過重放wal到被刷寫的最後乙個記錄來進行恢復。資料庫將因此被恢復到乙個自身一致狀態,但是任何還沒有被刷寫到磁碟的事務將不會反映在該狀態中。因此其影響就是丟失了最後的少量事務。由於事務按照提交順序被重放,所以不會出現任何不一致性 — 例如乙個事務b按照前面乙個事務a的效果來進行修改,則不會出現a的效果丟失而b的效果被保留的情況。

使用者可以選擇每乙個事務的提交模式,這樣可以有同步提交和非同步提交的事務並行執行。這允許我們靈活地在效能和事務永續性之間進行權衡。提交模式由使用者可設定的引數synchronous_commit控制,它可以使用任何一種修改配置引數的方法進行設定。乙個事務真正使用的提交模式取決於當事務提交開始時synchronous_commit的值。

特定的實用命令,如drop table,被強制按照同步提交而不考慮synchronous_commit的設定。這是為了確保伺服器檔案系統和資料庫邏輯狀態之間的一致性。支援兩階段提交的命令頁總是同步提交的,如prepare transaction。

如果資料庫在非同步提交和事務wal記錄寫入之間的風險視窗期間崩潰,在該事務期間所作的修改將丟失。風險視窗的持續時間是有限制的,因為乙個後台程序(「wal寫程序」)每wal_writer_delay毫秒會把未寫入的wal記錄刷寫到磁碟。風險視窗實際的最大持續時間是wal_writer_delay的3倍,因為wal寫程序被設計成傾向於在忙時一次寫入所有頁面。

乙個立刻關閉等同於一次伺服器崩潰,因此也將會導致未刷寫的非同步提交丟失。

非同步提交提供的行為與配置fsync = off不同。fsync是乙個伺服器範圍的設定,它將會影響所有事務的行為。它禁用了postgresql中所有嘗試同步寫入到資料庫不同部分的邏輯,並且因此一次系統崩潰(即,乙個硬體或作業系統崩潰,不是postgresql本身的失敗)可能造成資料庫狀態的任意損壞。在很多情境中,帶來大部分效能提公升的非同步提交可以通過關閉fsync來獲得,而且不會帶來資料損壞的風險。

commit_delay也看起來很像非同步提交,但它實際上是一種同步提交方法(事實上,commit_delay在非同步提交時被忽略)。commit_delay會使事務在刷寫wal到磁碟之前有乙個延遲,它期望由乙個這樣的事務所執行的刷寫能夠也服務於其他同時提交的事務。該設定可以被看成是一種時間視窗,在其期間事務可以參與到一次單一的刷寫中,這種方式用於在多個事務之間攤銷刷寫的開銷。

資料庫PostrageSQL 架構

邏輯複製從拷貝發布者資料庫上的資料庫快照開始。拷貝一旦完成,發布者上的更改會在它們發生時實時傳送給訂閱者。訂閱者按照資料在發布者上被提交的順序應用資料,這樣任意單一訂閱中的publication的事務一致性才能得到保證。訂閱者資料庫上的應用程序總是將session replication role設...

資料庫PostrageSQL 啟動資料庫伺服器

在任何人可以訪問資料庫前,你必須啟動資料庫伺服器。資料庫伺服器程式是postgres,它必須知道在 能找到它要用的資料。這是用 d選項實現的。因此,啟動伺服器最簡單的方法是 postgres d usr local pgsql data這將把伺服器放在前台執行。這個步驟同樣必須以postgresql...

資料庫PostrageSQL 鎖管理

deadlock timeout integer 這是進行死鎖檢測之前在乙個鎖上等待的總時間 以毫秒計 死鎖檢測相對昂貴,因此伺服器不會在每次等待鎖時都執行這個它。我們樂觀地假設在生產應用中死鎖是不常出現的,並且只在開始檢測死鎖之前等待一會兒。增加這個值就減少了浪費在無用的死鎖檢測上的時間,但是減慢...