PostgreSQL 架構

wongchaofan發表於2024-07-20
SQL架構
LIBPQ-圖書館池配額
  • 關於已連線使用者使用工具的詳細資訊
  • libpq 是C 應用程式設計師與 PostgreSQL 的介面。libpq 是一組庫函式，允許客戶端程式將查詢傳遞給 PostgreSQL 後端伺服器並接收這些查詢的結果。
  • 使用 libpq 的客戶端程式必須包含標頭檔案 libpq-fe.h，並且必須與 libpq 庫連結
  • 原始碼分發中的 src/test/examples 目錄下還有 libpq 應用程式的幾個完整示例。
客戶流程：
  • 每當我們發出查詢或我們（客戶端）所做的操作都稱為客戶端程序
  • 它是前端。
  • 前端可以是文字應用程式、圖形應用程式或 Web 伺服器頁面。
  • 透過 TCP/IP 客戶端訪問伺服器
  • 許多使用者可以同時訪問資料庫
  • FORKS – 此過程使多使用者訪問成為可能。它不會干擾 postgres 程序
郵政局長：
  • postmaster的工作是對埠（5432）進行認證，併為使用者分配程序。
伺服器程序：
  • 它也被稱為postgres。它接受來自客戶端（我們）的連線，如資料庫檔案並管理資料庫操作。

Postgresql​ 10 naming updates:

9.6 Directory | 10 Directory
--------------+-------------
pg_xlog | pg_wal
pg_clog | pg_xact
pg_log | log

Postgres 伺服器分為兩部分

例項

二、貯存

一、例項 分為兩種型別
1.記憶體緩衝區
2.實用程式程序1.記憶體緩衝區：a)Shared_buffer：

    • 設定資料庫伺服器用於共享記憶體緩衝區的記憶體量。預設值通常為 128 兆位元組 (128MB)，但如果您的核心設定不支援（在 initdb 期間確定），則預設值可能會更少。此設定必須至少為 128 千位元組。（BLCKSZ 的非預設值會更改最小值。）但是，通常需要設定遠高於最小值的設定才能獲得良好的效能。此引數只能在伺服器啟動時設定。
    • 如果您擁有一臺具有 1GB 或更多 RAM 的專用資料庫伺服器，shared_buffers 的合理起始值是系統記憶體的 25%。在某些工作負載下，即使較大的 shared_buffers 設定也是有效的，但由於 PostgreSQL 還依賴於作業系統快取，因此為 shared_buffers 分配超過 40% 的 RAM 不太可能比分配較小的 RAM 效果更好。較大的 shared_buffers 設定通常需要相應增加 checkpoint_segments，以便在更長的時間內分散寫入大量新資料或更改資料的過程。
    • 在 RAM 小於 1GB 的系統上，較小的 RAM 百分比是合適的，以便為作業系統留出足夠的空間。此外，在 Windows 上，shared_buffers 的較大值效果不佳。您可能會發現將設定保持在相對較低水平並更多地使用作業系統快取會獲得更好的效果。
    • Windows系統上shared_buffers的有用範圍一般是64MB到512MB。

b)牆緩衝區：

  • 用於尚未寫入磁碟的 WAL 資料的共享記憶體量。預設設定 -1 選擇的大小等於 shared_buffers 的 1/32（約 3%），但不小於 64kB，也不大於一個 WAL 段的大小，通常為 16MB。如果自動選擇太大或太小，可以手動設定此值，但任何小於 32kB 的正值都將被視為 32kB。
  • 此引數只能在伺服器啟動時設定。
  • 每次事務提交時，WAL 緩衝區的內容都會寫入磁碟， 因此過大的值不太可能帶來顯著的好處。但是，將此值設定為至少幾兆位元組可以提高繁忙伺服器上的寫入效能，因為許多客戶端同時提交。預設設定 -1 選擇的自動調整在大多數情況下應該會給出合理的結果。

c)CLOG緩衝液：

  • CLOG BUFFERS 是面向迴圈資料“環”的 SLRU 樣式緩衝區之一，例如 哪些事務號已提交或已回滾。

d)臨時緩衝區：

  • 設定每個資料庫會話使用的臨時緩衝區的最大數量。
  • 這些是會話本地緩衝區，僅用於訪問臨時表。預設值為 8 兆位元組 (8MB)。
  • 可以在各個會話內更改該設定，但只能在會話內第一次使用臨時表之前更改；後續嘗試更改該值將不會對該會話產生影響。
  • 會話將根據需要分配臨時緩衝區，直至達到 temp_buffers 給出的限制。在實際上不需要很多臨時緩衝區的會話中設定較大的值的成本僅為緩衝區描述符，即 temp_buffers 中每個增量約 64 個位元組。但是，如果實際使用緩衝區，則會為其消耗額外的 8192 個位元組（或一般為 BLCKSZ 位元組）。

e)工作記憶體：

  • 指定在寫入臨時磁碟檔案之前 內部排序操作和雜湊表要使用的記憶體量 。該值預設為 4 兆位元組 (4MB)。
  • 請注意，對於複雜查詢，可能會並行執行多個排序或雜湊操作；在開始將資料寫入臨時檔案之前，每個操作將被允許使用此值指定的記憶體量。
  • 此外，多個正在執行的會話可能會同時執行此類操作。因此，使用的總記憶體可能是 work_mem 值的很多倍；在選擇值時必須牢記這一事實。排序操作用於 ORDER BY、DISTINCT 和合並連線。
  • 雜湊表用於雜湊連線、基於雜湊的聚合以及基於雜湊的 IN 子查詢處理。

f)維護工作記憶體：

  • 指定維護操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE ADD FOREIGN KEY）使用的最大記憶體量 。預設為 64 兆位元組 (64MB)。
  • 由於資料庫會話一次只能執行其中一個操作，並且安裝通常不會同時執行多個操作，因此可以安全地將此值設定為遠大於 work_mem。
  • 更大的設定可能會提高畫質理和恢復資料庫轉儲的效能。

請注意 ，當 autovacuum 執行時，最多可分配 autovacuum_max_workers 倍的記憶體，因此請注意不要將預設值設定得太高。透過單獨設定 autovacuum_work_mem 來控制這一點可能會很有用。2 . 實用程式（後臺）程序：a)BGWriter：



  • 有一個單獨的伺服器程序稱為後臺寫入器，其功能是發出“髒”（新的或修改的）共享緩衝區的寫入。
  • 它寫入共享緩衝區，因此處理使用者查詢的伺服器程序很少或永遠不需要等待寫入發生。
  • 但是，後臺寫入器確實會導致 I/O 負載的總體淨增加，因為雖然重複弄髒的頁面可能在每個檢查點間隔內僅被寫入一次，但後臺寫入器可能會在同一間隔內將其寫入多次。
  • 本小節討論的引數可用於根據當地需求調整行為。

b)WallWriter：

  • 每次事務提交時， WAL 緩衝區都會 寫入磁碟，因此過大的值不太可能帶來顯著的好處。但是，將此值設定為至少幾兆位元組可以提高繁忙伺服器上的寫入效能，因為許多客戶端同時提交。預設設定 -1 選擇的自動調整在大多數情況下應該會給出合理的結果。
  • 指定 WAL 寫入器活動輪次之間的延遲。在每一輪中，寫入器都會將 WAL 重新整理到磁碟。然後它會休眠 wal_writer_delay 毫秒，然後重複。
  • 預設值為 200 毫秒 (200ms)。
  • 請注意，在許多系統上，睡眠延遲的有效解析度為 10 毫秒；將 wal_writer_delay 設定為非 10 的倍數的值可能會產生與將其設定為下一個更高的 10 的倍數相同的結果。此引數只能在 postgresql.conf 檔案或伺服器命令列中設定。

c)SysLogger：錯誤報告和日誌記錄

PostgreSQL 架構
    • 根據該圖，可以清楚地看到，所有實用程式程序 + 使用者後端 + Postmaster Daemon 都連線到 syslogger 程序，用於記錄有關其活動的資訊。每個程序資訊都記錄在 $PGDATA/pg_log 下的 .log 檔案中。
    • 除錯更多程序資訊將導致伺服器開銷。始終建議進行最低限度的調整。但是，必要時可以增加除錯級別。單擊此處瞭解有關日誌記錄引數的更多資訊
    • 日誌收集器，這是一個後臺程序，用於捕獲傳送到 stderr 的日誌訊息並將其重定向到日誌檔案
    • log_directory- 資料目錄
    • log_filename-預設為postgresql-%Y-%m-%d_%H%M%S.log
    • 預設許可權為 0600

d)檢查點：
檢查點將發生在以下場景：

  1. pg_start_backup，
  2. 建立資料庫，
  3. pg_ctl 停止|重新啟動，
  4. pg_stop_備份，
  5. 提交問題，
  6. 頁面很髒
  7. 以及其他一些。
    • 它將記憶體中的所有髒頁寫入磁碟並清理 shared_buffers 區域。
    • 如果您的 Postgres 伺服器崩潰，您可以測量上次檢查點值時間和 PostgreSQL 停止時間之間的資料丟失。您還可以使用此資訊恢復您的系統。
    • 如果我們增加 checkpoint_segments，則檢查點出現的次數就會減少，並且 I/O 也會減少，因為需要寫入磁碟的內容更少。
    • 如果插入大量資料，則會生成更多檢查點。
    • 預寫日誌 (WAL) 會時不時地在事務日誌中放置一個檢查點。
    • CHECKPOINT 命令在發出時強制立即進行檢查點，而無需等待計劃的檢查點。
    • 檢查點是事務日誌序列中的一個點，在該點處，所有資料檔案都已更新以反映日誌中的資訊。所有資料檔案都將重新整理到磁碟。
    • 如果在恢復期間執行，CHECKPOINT 命令將強制重新啟動點而不是寫入新的檢查點。
    • 只有超級使用者可以呼叫 CHECKPOINT。此命令不適用於正常操作期間。
    • 強制切換到新的事務日誌檔案（僅限於超級使用者）或 切換到新的 xlog 檔案pg_switch_xlog()
    • 如果要強制切換日誌檔案，可以在 Postgres 上執行以下查詢：
 SELECT pg_switch_xlog();

e)統計收集器：

  • PostgreSQL 的統計收集器是一個子系統，支援收集和報告 有關伺服器活動的資訊，然後將資訊更新到最佳化器（pg_catalog），最佳化器使用 pg_catalog 生成查詢計劃。
  • 收集器可以按磁碟塊和單個行來統計對錶和索引的訪問。它還可以 跟蹤每個表中的總行數 以及有關每個表的清理和分析操作的資訊。
  • 它還可以計算使用者定義函式的呼叫次數以及每個函式所花費的總時間。
  • PostgreSQL 還支援報告其他伺服器程序當前正在執行的確切命令。此功能獨立於收集器程序。
  • 統計資訊收集器透過臨時檔案將收集到的資訊傳輸給其他 PostgreSQL 程序，這些檔案儲存在 stats_temp_directory 引數指定的目錄中，預設為 pg_stat_tmp。
  • 為了獲得更好的效能，stats_temp_directory 可以指向基於 RAM 的檔案系統，從而降低物理 I/O 要求。
  • 當伺服器正常關閉時，統計資料的永久副本將儲存在 pg_stat 子目錄中，以便在伺服器重啟後可以保留統計資料。
  • 當伺服器啟動時執行恢復時（例如立即關閉、伺服器崩潰和時間點恢復後），所有 統計計數器都將被重置。

f)存檔：

    • Achiver 程序是可選程序，預設為 OFF。
    • 以存檔模式設定資料庫意味著在每個段檔案寫滿後捕獲其 WAL 資料，並在段檔案被回收再利用之前將該資料儲存在某個地方。
    • 在資料庫 Archivelog 模式下，一旦 WAL 資料填充到 WAL 段中，WAL Writer 就會在 PGDATA/pg_xlog/archive_status 下建立該填充段的檔案，並將檔案命名為“.ready”。檔案命名將為“segment-filename.ready”。
    • 當找到由 WAL Writer 程序建立的 處於“.ready”狀態的檔案時，Archiver Process 會觸發。
    • 歸檔程序選擇 .ready 檔案的“segment-file_number”，並將該檔案從 $PGDATA/pg_xlog 位置複製到“archive_command”引數（postgresql.conf）中給出的相關歸檔目標。
    • 從源複製到目標成功完成後，歸檔程序將“segment-filename.ready”重新命名為“segment-filename.done”。這樣就完成了歸檔過程。
    • 可以理解的是，如果在 $PGDATA/pg_xlog/archive_status 中找到任何名為“segement-filename.ready”的檔案。它們是尚未複製到存檔目標的待處理檔案。
II.儲存：如何在 PostgreSQL 資料庫中查詢檔案路徑所指向的資料庫和表？路徑主要有三種模式：

  • 1.對於預設表空間中的檔案：關係的 base/database_oid/filenode id
  • 2.對於非預設表空間中的檔案：關係的 pg_tblspc / tablespace_oid / tablespace_version_subdir / database_oid / filenode id
  • 3.對於共享關係（見下文）：關係的全域性/檔案節點 ID
1.對於預設表空間中的檔案：
表的檔名不一定與 pg_class 中的 oid 相同，並且在執行 VACUUM FULL、TRUNCATE 等時可能會發生變化。
例如：
billing_db=# \dt+
                    List of relations
 Schema | Name | Type  |  Owner   |  Size   | Description
--------+------+-------+----------+---------+-------------
 public | t1   | table | postgres | 0 bytes |
(1 row)

billing_db=# SELECT pg_relation_filepath('t1');
 pg_relation_filepath
----------------------
 base/18144/18146
(1 row)

billing_db=# insert into t1 values(2);
INSERT 0 1
billing_db=# insert into t1 values(2);
INSERT 0 1
billing_db=# insert into t1 values(2);
INSERT 0 1

billing_db=# SELECT pg_relation_filepath('t1');
 pg_relation_filepath
----------------------
 base/18144/18146
(1 row)

billing_db=# update t1 set id=1;
UPDATE 3
billing_db=# SELECT pg_relation_filepath('t1');
 pg_relation_filepath
----------------------
 base/18144/18146
(1 row)


billing_db=# vacuum t1;
VACUUM

billing_db=# SELECT pg_relation_filepath('t1');
 pg_relation_filepath
----------------------
 base/18144/18146
(1 row)

billing_db=# vacuum full t1;
VACUUM

billing_db=# SELECT pg_relation_filepath('t1');
 pg_relation_filepath
----------------------
 base/18144/18149
(1 row)

注意，在 vacuum full 之後，此表 ID 從 18146 更改為 18149

2.非預設表空間路徑：

SELECT pg_relation_filepath('t1');
 pg_relation_filepath
----------------------
pg_tblspc / 16709 / PG_9.3_201306121 / 16499/19401
因此檔名模式可以分解為：
  • pg_tblspc：它位於非預設表空間中
  • 16709：它位於 oid 為 16709 的表空間中
  • PG_9.3_201306121：由 PostgreSQL 9.3 使用，目錄版本為 201306121。
  • 16499：在資料庫中，oid 為 16499
  • 19401 relfilenode id 為 19401 的表

例如：
data_directory：

  • 指定用於資料儲存的目錄。此引數只能在伺服器啟動時設定。

配置檔案：

  • 指定主伺服器配置檔案（通常稱為 postgresql.conf）。此引數只能在 postgres 命令列上設定。

hba_檔案：

  • 指定基於主機的認證的配置檔案（通常稱為pg_hba.conf）。此引數只能在伺服器啟動時設定。

ident_file（識別檔案）：

  • 指定使用者名稱對映的配置檔案（通常稱為 pg_ident.conf）。這個引數只能在伺服器啟動時設定。

外部程序號檔案：

  • 指定伺服器應建立供伺服器管理程式使用的附加程序 ID (PID) 檔案的名稱。此引數只能在伺服器啟動時設定。

PG_日誌：

  • 它不是一個實際的 postgres 目錄，而是 RHEL 儲存實際文字 LOG 的目錄。

PG_XLOG：

  • 預寫日誌儲存於此。它是日誌檔案，其中儲存了已提交和未提交事務的所有日誌。它最多包含 6 個日誌，最後一個日誌將被覆蓋。如果存檔器處於開啟狀態，它會移動到此處。

PG_CLOG：

  • 它包含提交日誌檔案，用於例項崩潰後的恢復

PG_版本：

    • 包含 PostgreSQL 主版本號的檔案

Base:

  • Subdirectory containing per-database subdirectories

Global:

  • Subdirectory containing cluster-wide tables, such as pg_database

PG_MULTIXACT:

  • Subdirectory containing multitransaction status data (used for shared row locks)

PG_SUBTRANS:

  • Subdirectory containing subtransaction status data

PG_TBLSPC:

  • Subdirectory containing symbolic links to tablespaces

PG_TWOPHASE:

  • Subdirectory containing state files for prepared transactions

POSTMASTER.OPTS:

  • A file recording the command-line options the postmaster was last started with

POSTMASTER.PID:

    • A lock file recording the current postmaster PID and shared memory segment ID (not present after postmaster shutdown)


相關文章