| 我其實想多寫幾個字來屁一下的 |
|---|
| 看了AWS的工程師寫的文件後 |
| 我只能說...甘拜下風 |
| 人家確實寫得好棒棒.... |
| 我們搞技術的 |
| 人家做得好 |
| 只能給他拍拍手 |
| 環境: |
| 1.cloud sql Postgres 13 |
| 2.compute engine debian 10 |
| 我也只能寫寫如何在cloud sql postgres安裝 |
| GCP Postgres是有支援pg_repack的 |
| 1.資料庫安裝extension |
| 進資料庫後,執行如下: |
| create extension pg_repack |
| 2.作業系統安裝binary |
| 進作業系統後: |
| apt-get install postgresql-13-repack |
| 關於索引重整 |
| postgres 本身reindex指令可以進行online rebuild 指令如下: |
| reindex index concurrently index_name |
說是online......恩....... |
| 我的測試結果是 |
| 其實跟pg_repack碰到的狀況一樣 |
| 還是要在資料異動作業小的時候來進行 |
| 只是pg_repack預設下 |
| 它會去找到卡住它運作的session |
| ㄝ.....然後把它砍掉 |
| 所以麻煩執行它的時候 |
| 請務必帶一個開關 --no-kill-backend |
| 這是AWS的部落格文章沒提到的 |
| percona的文章中提到了 Understanding pg_repack: What Can Go Wrong – and How to Avoid It |
| (記得要看阿...不要用了之後說..是我害了你) |
加了開關後的執行output |
AWS文章Remove bloat from Amazon Aurora and RDS for PostgreSQL with pg_repack開頭就說明了為什麼要做重整 |
| 記得要用pg_repack前 |
| 拜讀人家的大作 |
還有其他不錯的文章 |
| 也建議大家看一下 |
| 1.Using pg_repack to Rebuild PostgreSQL Database Objects Online |
| 2.Basic-understanding-bloat-vacuum-postgresql-mvcc |
| 3.Tuning-autovacuum-in-postgresql-and-autovacuum-internals |
| 怎麼看重整成效?? |
|---|
| 用pgstattuple extension |
| 這是我的一個分割表索引重整前的數據 |
| test=> select * from pgstatindex('date_trunc_idx'); |
| -[ RECORD 1 ]------+--------- |
| version | 4 |
| tree_level | 2 |
| index_size | 29646848 |
| root_block_no | 298 |
| internal_pages | 17 |
| leaf_pages | 2077 |
| empty_pages | 0 |
| deleted_pages | 1524 |
| avg_leaf_density | 53.05 |
| leaf_fragmentation | 10.74 |
| 這是pg_repack完成後的數據 |
| test=> select * from pgstatindex('date_trunc_idx'); |
| -[ RECORD 1 ]------+-------- |
| version | 4 |
| tree_level | 2 |
| index_size | 8519680 |
| root_block_no | 209 |
| internal_pages | 7 |
| leaf_pages | 1032 |
| empty_pages | 0 |
| deleted_pages | 0 |
| avg_leaf_density | 89.84 |
| leaf_fragmentation | 0 |