PostgreSQL9.6：新增加“idle in transaction”超時空閑事務自動查殺功能

meislzhua 發布于2019-07-25 12:34 / 3803人閱讀

摘要：以上出自發行說明，這段指出版本支持自動查殺超過指定時間的空閑事務連接，下面演示下。修改以下參數備注參數單位為毫秒，這里設置超時空閑事務時間為秒。數據庫日志備注數據庫日志里清晰地記錄了進程的連接由于空閑事務超時被斷開連接。

熟悉 PostgreSQL 的朋友應該知道 “idle in transaction” 進程，引發 idle in transaction 的原因很多，例如應用代碼中忘記關閉已開啟的事務，或者系統中存在僵死進程等，曾經看到過某個庫中的 idle in transaction 進程存在一年有余，這類進程嚴重危害了數據庫的安全，例如它會阻止 VACUUM 進程回收記錄，造成表數據膨脹，同時它有可能引起整個 PostgreSQL 數據庫 Transaction ID Wraparound 的風險。

Allow sessions to be terminated automatically if they sit too long in
an idle-in-transaction state (Vik Fearing) This behavior is enabled
and controlled by the new configuration parameter
idle_in_transaction_session_timeout. It can be useful to prevent
forgotten transactions from holding onto locks or preventing vacuum
cleanup for very long periods.

以上出自 PostgreSQL9.6 Beta1 發行說明，這段指出9.6版本 PostgreSQL 支持自動查殺超過指定時間的 idle in transaction 空閑事務連接，下面演示下。

--修改 postgresql.conf 以下參數

idle_in_transaction_session_timeout = 20000

備注：參數單位為毫秒，這里設置 idle in transaction 超時空閑事務時間為 20 秒。

--重載配置文件

[pg96@db1 pg_root]$ pg_ctl reload
server signaled

備注：此參數修改后對當前連接依然生效，應用不需要重連即能生效。

--開啟會話一：模擬一個事務

[pg96@db1 ~]$ psql francs francs
psql (9.6beta1)
Type "help" for help.

francs=> begin;
BEGIN

francs=> select 1;
 ?column? 
----------
        1
(1 row)

事務中，不提交也不回滾。

--開啟會話二：監控

postgres=# select * from pg_stat_activity where pid<>pg_backend_pid();
-[ RECORD 1 ]----+------------------------------
datid            | 16386
datname          | francs
pid              | 7776
usesysid         | 16384
usename          | francs
application_name | psql
client_addr      | 
client_hostname  | 
client_port      | -1
backend_start    | 2016-06-01 16:03:12.557328+08
xact_start       | 2016-06-01 16:03:16.921353+08
query_start      | 2016-06-01 16:03:18.754706+08
state_change     | 2016-06-01 16:03:18.755422+08
wait_event_type  | 
wait_event       | 
state            | idle in transaction
backend_xid      | 
backend_xmin     | 
query            | select 1;

postgres=# select * from pg_stat_activity where pid<>pg_backend_pid();
(0 rows)

備注：開始還能監控到這個 "idle in transaction" 的事務，大概過了 20秒后，這個事務查詢不到了。

--再回到會話一

francs=> select 1;
 ?column? 
----------
        1
        
FATAL:  terminating connection due to idle-in-transaction timeout
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

備注：回到會話一執行 select 1 測試命令，發現連接被斷開了，報錯代碼很明顯，idle-in-transaction 超時了。

--數據庫日志

2016-06-01 16:03:38.756
CST,"francs","francs",7776,"[local]",574e96c0.1e60,1,"idle in
transaction",2016-06-01 16:03:12 CST,2/5887,0,FATAL,25P03,"terminating
connection due to idle-in-transaction timeout",,,,,,,,,"psql"

備注：數據庫日志里清晰地記錄了 7796 進程的連接由于空閑事務超時被斷開連接。

--參考
idle_in_transaction_session_timeout (integer)
Preventing Transaction ID Wraparound Failures

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/38975.html

PostgreSQL9.6：新增pg_blocking_pids函數準確定位 Blocking SQ

摘要：創建測試表會話一備注會話一在事務里更新的記錄，并不提交。會話二備注會話二刪除的記錄，此時由于這條記錄之前被并沒有提交，這句仍然處于等待狀態。 PosttgreSQL 的SQL被鎖情況在數據庫維護過程中非常常見，之前博客 PostgreSQL 鎖分析演示了 PostgreSQL 鎖的一些場景，在開始本文的介紹之前特做以下說明，假如會話A堵住會話B，我們稱會話B為 blocked 會話...

liuchengxu 2019-07-25 12:34 評論0 收藏0
MyBatis 源碼閱讀之數據庫連接

摘要：源碼閱讀之數據庫連接的配置文件所有配置會被類讀取，我們可以通過此類來了解各個配置是如何運作的。也就是說的統計字段是關于整個數據源的，而一個則是針對單個連接的。 MyBatis 源碼閱讀之數據庫連接 MyBatis 的配置文件所有配置會被 org.apache.ibatis.builder.xml.XMLConfigBuilder 類讀取，我們可以通過此類來了解各個配置是如何運作的。而 ...

TwIStOy 2019-08-16 14:12 評論0 收藏0
數據庫相關異常分析

摘要：起因最近一段時間，生產系統持續碰到一些數據庫異常，導致執行失敗。綜上，若發生異常，為數據庫連接失效，但是失效的原因可能會有多種，大致都與各種參數相關。當時數據量大概多條，然后在批量插入時拋出該異常。起因最近一段時間，生產系統持續碰到一些數據庫異常，導致 sql 執行失敗。應用環境 Java 1.7 + Mysql 5.6 + spring + ibatis 問題排查將各種失敗的...

IamDLY 2019-08-16 13:58 評論0 收藏0
MongoDB 客戶端連接選項

摘要：原文保持更新及修正基于的客戶端配置選項，其它驅動大同小異。連接池中連接的最大使用壽命毫秒。設置該選項后，客戶端將進行以下行為以副本集模式連接，并根據給定的服務器發現副本集的所有成員。該選項可以和配合使用。編解碼器用于對進行編碼和解碼。原文保持更新及BUG修正：http://kweny.io/mongodb-clien... 基于 MongoDB Java Driver 3.8.1 ...

yexiaobai 2019-06-26 17:50 評論0 收藏0