在 Bash Shell Script 檢查相依 Script 檔案＆輸出內容自動導向＆輸出內容補前綴

用 Bash Shell Script 時，你有以下困擾ㄇ～？

1. 拆多個 Script、自訂設定檔，擔心檔案漏掉不知道
2. 因為手痠不想在執行 Script 時寫輸出導向（大於符號 > log_file 2>&1）；更不想在 Script 裡面每一行都加上輸出導向（手更痠。。）。只想要一兩行公式就自動檔向檔案
3. 想要在 Shell Script 所吐出來的輸出內容，每一行添加時間或是檔名等裝飾品
4. [Update 2022/3/8] 症狀四：不能同時運作的 shell script，運作時間又抓不準，然而卻需要設定頻繁 cronjob 排程，卻又害怕重複運行。。

這篇集以上問題之小成於一身，弄一個簡易可以抄的 Shell Script 範本，自認症狀符合的人類就夾去配ㄅ～

利用 Python3 內建 venv 管理 PGSQL PL/Python3 裡面可以使用的 Python 模組

使用 Python 有很多便利，但也很多困擾。。。其中之一就是 dependency hell。經典的圖就是 xkcd: Python Environment～

當然這狀況已經有許多手段可以預先規劃避免與處理，其中之一就是使用 virtualenv 製作隔離的 python runtime 環境。

那麼，當 Postgres 的內嵌 stored procdure PL/PythonU 遇到需要安裝模組要怎辦？

初步認識 EDB Postgres 的 K8s 容器化解決方案 — Cloud Native PostgreSQL Operator

基於上一篇筆記所找到的好心測試 K8s 工具，這邊要來嘗試 EDB Postgres 的 PostgreSQL 容器化方案 — Cloud Native PostgreSQL Operator。

在前一陣子 EDB 曾經在 K8s/Openshift 平台還沒變成壓倒性主流容器平台方案時，就已經提供 Docker Container 的資料庫解決方案，當時也做了一點點練習（筆記在這）。

不過當時得努力的搞清楚最原生的 K8s YAML 設置，其實很複雜。。。

隨著 K8s 整體的推進，出現了 Helm 與 Operator 這類「套件管理」的工具，加上 K8s 強化 Stateful Container 的支援，資料庫陸陸續續也可以輕易登陸 K8s 平台。

EDB 團隊基於這些變化，加上原 2ndQ 團隊的一同合作，便推出這個成熟的 K8s 解決方案。

這邊就要來初步體驗一下～

K8s in Docker：好心的 K8s 測試環境

K8s 有一大堆的測試環境設置方式，這邊紀錄一個 KIND 專案 — Kubernetes IN Docker — 把在 Docker Container 裡面模擬多節點 K8s 環境。

有別於之前筆記在 LXD 裡面設置 Minikube 得準備一堆預備動作，KIND 蠻好心的～簡簡單單的把 K8s 關在容器裡面～！

這樣一來～測試環境空間省很多，資源也比較省～更比之前辛苦的用 LXD 關住 Minikube 容易多了～

在 PGSQL 把 EAV 表格轉成 JSON 欄位與進一步攤平

Entity-Attribute-Value 型態（縮寫 EAV）的資料蠻常出現在實際應用上，最典型的就是資料分析時很多屬性標籤。

但是。。。PGSQL 其實不擅長對付這種屬性的資料。。。第二個無腦建議總是說：想辦法轉成關聯式結構的表格（第一個建議呢～就是建 GIN Index 之類的ㄅ～）

不過，這種屬性的資料正好可以用另一種主流資料儲存型態代換—JSON 型態。正好現在的 Postgres 也很擅長處理 JSON 資料。

另外值得提到的是，PGSQL 並不像 Cassandra 這種 Wide-Column Store 一樣可以開「很多」欄位，因此若 Attribute 標籤種類繁雜，就不是很適合在 PGSQL 開超多欄位的表格來存放。

因此這篇筆記嘗試把 EAV 轉換成 JSON 儲存的方式（測試版本：EDB PGSQL13，不過用到的功能基本上 PGSQL 9.5 以上都可以）。

另外，當標籤的類型很少，可以轉換成一般欄位的話（也就是關聯式表格），這篇筆記也嘗試演練一下～

如果看到這邊～還是不知道窩在講蝦米～請上網查一下 EAV pattern 與 Relational Model～

攜帶 ansible 環境的偷吃步方式

 由於開始接觸 ansible 佈署工具，但有一些麻煩的地方：

• 沒有連外部網路的環境，是很麻煩的，東西得預先備妥

• ansible 對版本對齊這件事還蠻要求的，不同版本的 playbook 或模組會有差異，套錯版本可能會有意料之外的狀況（通常是少一些步驟，變成雪球越滾越大）

• 對使用的 python 環境，也有不同版本：不過這一點稍微鬆一點，ansible 目前還能向下支援到很古老的 python 版本

• 如何方便的攜帶相依模組與對應的模組版本，這也是很痛苦的地方：雖然有 pip requirements.txt，但這沒有網路就無用武之地

部份公司的部門可能有設置 ansible tower 管理，這種狀況還有機會偷懶，只放置 ansible galaxy 帶過來的 collection 和預備好的 playbook；但更多時候，是面對接好線，灌好 RHEL/Debian 系列的電腦，直接開始表演。。。

因此要使用 ansible 佈署，最好是了解怎麼攜帶需要的環境。

以下筆記簡單的紀錄一種偷吃步方式：這邊以 CentOS 8 Stream 示範，不過原理上適用市面上熱門的 Linux distribution～

EDB 解決方案—EDB-Ansible 佈署 PostgreSQL 13 初步練習

一般來說，弄一個 PGSQL 資料庫到電腦上跑很容易，不過通常正式系統中會有一些東西需要微調，這部份沒有用一點心思去了解就會被遺漏。
不過現在流行把設置步驟整理成自動化作業，其中一個好處就是避免上面這狀況。其中一個流行的工具叫做 ansible，我最近才開始認識它～
EDB 公司也基於 ansible 提供了這樣的免費取得的工具（BSD 風格的授權），方便一般 PGSQL 使用者或是 EDB 訂閱客戶使用～不但避免了以上困擾，還可以讓大家直接套用原廠的最佳設置建議，同時又省下設定電腦流逝的光陰～
EnterpriseDB/edb-ansible: Ansible code for deploying EDB Postgres database clusters and related products.
Ansible Galaxy - edb_postgres

這篇筆記紀錄一些 EDB/Postgres 的 Ansible 佈署第一次操作體驗。

透過 XFS Project Quota 功能控制 PGSQL 個別帳號的空間用量

PGSQL 作為萬用型資料庫，有時候會有作中小型資料分析系統使用，這種系統有時候有不同人員需要使用，為避免使用者揮霍空間，就會有限制使用帳號可用資料量的想法，有一點像雲端的個人儲存空間～

但是 PGSQL 本身並沒有提供這種功能，只有一兩個稍嫌老舊的外掛雛型（應該還是能用）。。。有一個 Postgres 的延伸專案 Greenplum 由於是資料倉儲軟體，因此內建有 diskquota 外掛，不過 PGSQL 社群看起來不是很感興趣～

因此這邊透過 OS 內建功能達成：利用 Linux 底下 XFS 檔案系統才有的 Project Quota 功能，演練帳號空間控制～

PGSQL 有兩類型的 tablespace：
 - 普通用來放資料的，由 default_tablespace 指定
 - 暫存表跟查詢過程 temp file，由 temp_tablespace 指定

一般使用上，沒有需要特別指定 tablespace，資料跟暫存表都會放到 $PGDATA/base/ 跟 $PGDATA/base/pgsql_tmp/ 底下。

原則上這邊要限制的是 default_tablespace，至於 temp_tablespace 會涉及查詢成敗，因此要不是額外用較高速的共通磁碟空間，搭配 temp_file_limit 控制。

於是，這篇筆記目標就是使用 xfs_quota 的 Project Quota 功能控制個別 DB 帳號的個人使用空間（defaut_tablespace）。

從 Postgres 外部表查看即時的資料庫 Log

 聽說 Oracle 資料庫可以從資料庫裡面用表格查看資料庫 Alert Log（難道是把資料庫的 log 存放在資料庫裡面？這樣關掉資料庫不就看不到 log。。。？）

但是 EDB 跟 PGSQL 跟普通的程式一樣，寫檔案到 log 檔案。沒辦法直接用表格查詢查看（這是 SQL 控。。。。！？），對於只想要用 SQL 界面解決大小事的人們不太方便～

不過 PGSQL 有一個外部表模組，可以讀取 csv 檔案～

而 file_fdw 手冊頁面有一個雛型，可以直接查看 csv log 檔案內容；不過實際的 Log 會定時切換檔案，這篇筆記紀錄這樣的內容：透過 file_fdw 查看最目前的 DB log 檔案內容。

PGSQL 9.x 之後的交易流水帳 WAL 的管理變化—從 v9.4 到 v13

傳統的關聯式資料庫為了的設計上，大多有所謂的 Transaction Log （Tx Log） 的機制設計，將資料庫活動一五一十的記錄下來（優先於表格資料的實際回存到磁碟），以確保資料的高規格保全要求。

Transaction Log 通常稱作交易日誌，不過為了避免跟一般錯誤紀錄 Log 混淆，以下稱作交易紀錄流水帳。

在 PGSQL 與 EDB/PGSQL 企業版中，該機制稱為 Write-Ahead Logging，通常稱作 WAL。

這份筆記簡單紀錄 PGSQL 9.4 ~ PGSQL 13 的重要設定變化。

在 PGSQL 13 用 Stored Procedure 包裝 VACUUM 與 ANALYZE 指令

 使用 ETL 作業作資料匯入，常常會有大量資料匯入或異動。對 PGSQL 來說，這時候若可以在批次資料匯入/異動完畢後執行 ANALYZE 作一次資料表的抽樣統計收集，甚至是 VACUUM 維護作業，會有助於資料的查詢。

然而。在 PGSQL 裡面，可以執行 VACUUM 與 ANALYZE 指令的帳號，只有表格物件擁有者（ Table Owner ）以及 postgres/enterprisedb 等 Superuser 帳號，但是通常 ETL 程式用的帳號通常不會是這兩個。。。因此若有 vacuum analyze 包裝函數，搭配 Stored Function/Procedure 的 Security Definer 供其他帳戶呼叫，就會方便許多。

這篇筆記紀錄的就是 PGSQL 批次匯入後執行 ANALYZE 的 Stored Procedure，也順便練習 Stored Procedure 一下～

在 EDB13 安裝 tds_fdw 連通 Linux 上的 SQL Server XE

這邊不是用原生的 Postgres，而是使用 EDB 的企業版 Postgres 13。

PGSQL 在 PGDG Repo 裡面已經提供現成的 RPM 可以用了（可以載 https://tds-fdw.github.io/yum/tds_fdw.repo，或其實 PGDG 本身裡面就有提供了），因此不用擔心～

在 LXD 安裝 MS SQL Server 2019 XE

為了測試 PostgreSQL 的 tds_fdw 這個外掛，這邊要在測試環境安裝 Linux 版的 SQL Server XE 看看。這邊用的是 2019 版。這邊裝在 LXD Container 裡面，確定可以運作。