Oracle2PG系列之檢查點(diǎn)引起的故障案例

IT那活兒發(fā)布于2023-01-11 13:20 / 2056人閱讀

Oracle2PG系列之檢查點(diǎn)引起的故障案例

點(diǎn)擊上方“IT那活兒”，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！！

最近碰到個(gè)案例,某Oracle數(shù)據(jù)庫遷移到PG的過程中,壓測(cè)發(fā)現(xiàn)一波巨量IO將PG庫給沖hang住了,一通檢查發(fā)現(xiàn)是PG全量檢查點(diǎn)搗的鬼,今天我們一起來總結(jié)一下。

先普及一下基礎(chǔ)知識(shí)，一般數(shù)據(jù)庫的最小存儲(chǔ)單元都是數(shù)據(jù)塊(block/page),當(dāng)客戶端修改數(shù)據(jù)時(shí)意味著,數(shù)據(jù)庫引擎需要將對(duì)應(yīng)的物理數(shù)據(jù)塊讀到數(shù)據(jù)庫的buffer cache中進(jìn)行修改,此時(shí)這個(gè)數(shù)據(jù)塊與物理文件中的數(shù)據(jù)塊將不在一致，稱為臟塊。

由于臟塊分布隨機(jī),持久化到存儲(chǔ)的成本巨大,讓客戶端等待這個(gè)臟塊完成持久化完成無疑TPS會(huì)非常差。

為了改進(jìn)這個(gè)問題各大數(shù)據(jù)庫廠商普遍采用預(yù)寫式(write ahead log,也有取名redo,都是一個(gè)意思)來記錄這些臟塊的修改動(dòng)作(record),將這些record持續(xù)性順序的持久化到磁盤,臟塊將在后續(xù)異步持久化到存儲(chǔ)中。

傳統(tǒng)HDD順序IO的性能優(yōu)于隨機(jī)IO幾十倍，這即保證了數(shù)據(jù)修改不會(huì)丟失，性能也得到得了巨大提升。

參考o(jì)racle文檔圖：

需要注意：當(dāng)臟塊持久化不及時(shí)，buffer cache中堆積了巨量臟塊時(shí)，如果發(fā)生宕機(jī),數(shù)據(jù)庫再次啟動(dòng)時(shí)為了維持一致性，需要調(diào)用wal的record來恢復(fù)這些臟塊。這就需要數(shù)據(jù)庫判斷哪些是臟塊,通常數(shù)據(jù)庫廠商采用檢查點(diǎn)(checkpoint)點(diǎn)來進(jìn)行標(biāo)記。

Buffer cache中的臟塊持久化到數(shù)據(jù)文件中后，將標(biāo)記上checkpoint position,并與wal record進(jìn)行關(guān)聯(lián)，position之前的wal將不再需要,position之后的wal record用來對(duì)臟塊進(jìn)行一致性恢復(fù)。

參考o(jì)racle文檔圖：

注意：在Oracle中,其采用SCN來記錄Checkpoint position。

Oracle在古老的8i版本之前,采用一次性將buffer cache中的臟塊全量持久化到數(shù)據(jù)文件中并更新checkpoint position，稱為全量檢查點(diǎn)(full checkpoint)。這種方法比較簡(jiǎn)單粗暴,產(chǎn)生的問題也很直觀,當(dāng)產(chǎn)生全量檢查點(diǎn)時(shí)，巨量的臟塊持久化IO會(huì)對(duì)數(shù)據(jù)庫TPS產(chǎn)生劇烈影響，甚至于hang、宕機(jī)等、問題多多。

Oracle針對(duì)這個(gè)問題后續(xù)采用了增量檢查點(diǎn)(Incremental checkpoint),在buffer cache中對(duì)臟塊按順序進(jìn)行鏈表記錄,增量檢查點(diǎn)按鏈表持續(xù)推進(jìn)position，數(shù)據(jù)庫實(shí)例異常宕機(jī)時(shí)，僅需對(duì)最新position之后的臟塊使用wal record進(jìn)行一致性恢復(fù)，這會(huì)大大縮短恢復(fù)時(shí)間，且將全量檢查點(diǎn)的巨量臟塊持久化IO進(jìn)行平滑拆分提高數(shù)據(jù)庫穩(wěn)定性,同時(shí)提供了Fast Mtrr等參數(shù)進(jìn)一步幫助用戶來控制一致性恢復(fù)時(shí)間。

以上我們就搞清了Oracle檢查點(diǎn)相關(guān)的知識(shí)。

接下來就來探討PG的檢查點(diǎn)：