66. 66/147
2015
Auto / Manual Clean Dead Node
Ref: https://www.facebook.com/groups/199493136812961/permalink/731201573642112/
67. 67/147
2015
Auto / Manual Clean Dead Node
Ref: https://www.facebook.com/groups/199493136812961/permalink/729886527106950/
作者一直強調:
1. DBA 一定要知道什麼時候系統最清閒。
2. 手動決定而不要自動。
68. 68/147
2015
Auto / Manual Clean Dead Node
《我的解釋》
很多營運不是政府機關或金融單位。夜間也不一定可以緩機
休息。因此,面對全球化營運思維時,系統隨時都有高承載
的可能。這意謂著系統即使相對上有「比較空閒」的時間,
但此時線上人數都還可能超過數萬,甚至數百萬人使用。
這時候的任何回收行為都會影響正常的系統營運。
還是回到初衷,選擇最適你的業務需求。
69. 69/147
2015
Auto / Manual Clean Dead Node
《 Sentry 的災難與慘痛經驗 》
The internet is full of awful advice of users suggesting you
should turn off autovacuum, or run it manually at low traffic
times, or simply adjust its schedule to run less often. To know
why that’s ill-advised, you first need to understand the
consequences of autovacuum not running.
網路上很多人建議關閉 AUTOVACUUM ,改以排程或手動
選擇負載低的期間執行 VACUUM 。但這是不明智的,你只
要知道不運行 AUTOVACUUM 會帶來的各種嚴重後果就會
明白了。
Ref: http://blog.getsentry.com/2015/07/23/transaction-id-wraparound-in-postgres.html
89. 89/147
2015
MySQL index->lock contention
《整理》
作者的論點 ( 雖然兩者衝突 )
1. MySQL 的 B+ tree 在 page splitting / merging 時 ,(always) 整棵
B+ tree 都會加上 WRITE_LOCK 。
2. 只有 leaf-node split / merge 會引起 index X lock 。
我的論點 ( 兩個是獨立事件 )
1. “latch” “與 lock” 的定義在 MySQL 中不一樣。
2. ”latch” “只是 one page” ,不等同於 "full index" 。
( ”但若 latch” ”不只是 one page” 則可能 )
2. “latch” ”可以對 node” ”,也可以對 full index” 。
90. 90/147
2015
MySQL index->lock contention
Ref: http://mysqlserverteam.com/mysql-5-7-improves-dml-oriented-workloads/
Before 5.7, every modifications to non-leaf pages (every modifications for the
tree structure) required to exclude the other threads’ access to the whole index
by X-lock, and every concurrent accessing the index tree were blocked.
91. 91/147
2015
MySQL index->lock contention
Ref#1: http://mysqlserverteam.com/mysql-5-7-improves-dml-oriented-workloads/
Ref#2: http://www.percona.com/blog/author/yasufumi/
Ref#3: http://dev.mysql.com/worklog/task/?id=6326
Ref#4: https://github.com/mysql/mysql-server/commit/070115a3d9548f790039c39a48b19d759ab2407c
Before 5.7, every modifications to non-leaf pages (every modifications for the
tree structure) required to exclude the other threads’ access to the whole index
by X-lock, and every concurrent accessing the index tree were blocked.
MySQL 開發者講了兩件事:
1. page split / merge “時,只有發生在 non-leaf pages” 時才會 whole index locked 。
2. page split / merge “時,只有在 non-leaf pages” ”才稱 tree structure modification” 。
補充:這位 MySQL 開發者是誰?
1. 他是 Yasufumi Kinoshita 。
2. Percona 官方認證數一數二 InnoDB 專家,從事 InnoDB 內核改進多年。
( 底下附參考連結 #2)
3. 本次的改良幾乎由他主導,是實際改程式碼的人。 ( 詳見下方參考連結 #3 及 #4)
4. 如果不相信他,我也不知道該相信誰。
92. 92/147
2015
MySQL index->lock contention
《整理》
作者的論點 ( 雖然兩者衝突 )
1. MySQL 的 B+ tree 在 page splitting / merging 時 ,(always) 整棵
B+ tree 都會加上 WRITE_LOCK 。
2. 只有 leaf-node split / merge 會引起 index X lock 。
我的論點 ( 兩個是獨立事件 )
1. “latch” “與 lock” 的定義在 MySQL 中不一樣。
2. ”latch” “只是 one page” ,不等同於 "full index" 。
( ”但若 latch” ”不只是 one page” 則可能 )
128. 128/147
2015
High Concurrent Write?(PURGE/VACUUM)
PostgreSQL 8.3 之後,加入了 HOT ("heap only tuple") 。
但 HOT 並沒有完全解決問題,它的缺點如下:
1. 只有在所有索引屬性都沒有被更新時才能使用 HOT 。
2. 只有在被更新記錄所在頁面能夠存儲新版本時才能用 HOT 。
Ref: http://rhaas.blogspot.tw/2011/02/mysql-vs-postgresql-part-2-vacuum-vs.html