自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

sqlite wal 分析

數(shù)據(jù)庫(kù)
本文將介紹 wal 原理,并源碼剖析 checkpoint 過(guò)程,同時(shí)討論下 wal 使用中的一些注意點(diǎn)。由于 sqlite 的復(fù)雜性,會(huì)省略掉一些細(xì)節(jié),重點(diǎn)放在核心流程和 wal 并發(fā)的實(shí)現(xiàn)。

sqlite 提供了一種 redo log 型事務(wù)實(shí)現(xiàn),支持讀寫的并發(fā),見 write-ahead log(https://sqlite.org/wal.html)。

一. wal 原理

1.1 redo log

sqlite wal 是一種簡(jiǎn)單的 redo log 事務(wù)實(shí)現(xiàn),redo log 概念這里簡(jiǎn)述下。數(shù)據(jù)庫(kù)事務(wù)需要滿足滿足 acid,其中原子性(a),即一次事務(wù)內(nèi)的多個(gè)修改,要么全部提交成功要么全部提交失敗,不存在部分提交到 db 的情況。 redo log 的解決思路是將修改后的日志按序先寫入 log 文件(wal 文件),每個(gè)完成的事務(wù)會(huì)添加 checksum,可鑒別事務(wù)的完整性。事務(wù)寫入日志文件后,即代表提交成功,讀取時(shí)日志和 db 文件合并的結(jié)果構(gòu)成了 db 的完整內(nèi)容。同時(shí)定期 checkpoint,同步 wal 中的事務(wù)到 db 文件,使 wal 文件保持在合理的大小。日志文件持久化到磁盤后,已提交成功的事務(wù)按序 checkpoint 執(zhí)行的結(jié)果都是一樣的,不受 crash 和掉電的影響。

sqlite 的 wal 也是這種思路的實(shí)現(xiàn),只是 sqlite 提供的是一種簡(jiǎn)化實(shí)現(xiàn),同時(shí)只允許一個(gè)寫者操作日志文件,日志也是 page 這種物理日志。redo log 還能將 undo log 的隨機(jī)寫轉(zhuǎn)化為順序?qū)?,具有更高的寫入性能?/strong>這里不贅述。

想對(duì) redo log 進(jìn)一步了解,可以參考以下資料:

??https://zhuanlan.zhihu.com/p/35574452??

??https://developer.aliyun.com/article/1009683??

1.2 sqlite wal

sqlite wal 寫操作不直接寫入 db 主文件,而是寫到“db-wal”文件(以下簡(jiǎn)稱'wal'文件)的末尾。讀操作時(shí),將結(jié)合 db 主文件以及 wal 的內(nèi)容返回結(jié)果。wal 模式同時(shí)具有簡(jiǎn)單的 mvvc 實(shí)現(xiàn),支持文件級(jí)別的讀寫并發(fā),提供了相對(duì) delete(rollback) 模式 (undo log 事務(wù)) 更高的并發(fā)性。 具體可看圖加深理解。

下圖中:

  1. pgx.y,x 表示當(dāng)前 page 的 num,y 表示當(dāng)前 page 的版本,每個(gè)提交的事務(wù)都保存當(dāng)前修改后的 page 副本;
  2. 圖中 wal 中提交了兩個(gè)事務(wù),wal 中藍(lán)色框表示一個(gè)完整事務(wù)修改的所有 page;
  3. wal 實(shí)際中保存的單位是 wal frame,除了修改的頁(yè)面還會(huì)保存 page number checksum 等信息,這里為了突出展示了 page, 詳細(xì)格式見:https://www.sqlite.org/fileformat2.html

圖片

關(guān)于寫

  1. 寫操作總是發(fā)生在 wal 文件上;
  2. 寫操作總是追加在 wal 文件末尾,由 commit 觸發(fā);
  3. 寫入 wal 文件中是原始 page 修改后的副本;
  4. 寫操作對(duì) wal 文件的訪問(wèn)是獨(dú)占串行的;
  5. 事務(wù)寫入只有成功落盤(寫入磁盤)才算成功提交,checkpoint 前會(huì)調(diào)用 wal 文件的 fsync,保證日志提交持久性和一致性;
  6. 沒有調(diào)用 fsync 不代表日志提交一定失敗,會(huì)由文件系統(tǒng)定期回寫;
  7. 如果 fsync 回寫之前發(fā)生 crash 或系統(tǒng)崩潰,導(dǎo)致事務(wù) 2 的 pg4.2 寫 wal 失敗,可校驗(yàn)出事務(wù) 2 不完整,則 wal 中成功提交的事務(wù)只有事務(wù) 1; 如果 pg0.1 回寫失敗,則 wal 中沒有成功提交的事務(wù)。?

圖片

關(guān)于讀

  1. 讀與寫可以并發(fā);
  2. 每個(gè)讀事務(wù)會(huì)記錄 wal 文件中一個(gè) record 點(diǎn),作為它的 read mark,每個(gè)事務(wù)執(zhí)行過(guò)程中 read mark 不會(huì)發(fā)生改變,新提交的事務(wù)產(chǎn)生的修改不會(huì)影響舊的事務(wù)。read mark 會(huì)選擇事務(wù)完整提交后的位置。原始 db 文件和 wal 中 read mark 之前的記錄構(gòu)成了數(shù)據(jù)庫(kù)的一個(gè)固定的版本記錄;
  3. 讀事務(wù)讀一個(gè) page 優(yōu)先讀 wal 文件,沒有則讀原始文件;
  4. 如果一個(gè) page 在 wal 中有多個(gè)副本,讀 read mark 前的最后一個(gè);
  5. 同一個(gè) read mark 可以被多個(gè)讀事務(wù)使用。

圖片

關(guān)于 checkpoint:

  1. checkpoint 針對(duì) wal 中已經(jīng)成功落盤的事務(wù),每次 checkpoint 前會(huì)執(zhí)行 fsync;
  2. 每次 checkpoint 從前到后按序回寫 wal 文件中尚未提交的事務(wù)到 db;
  3. 如果 checkpoint 中途 crash,由于事務(wù)已持久化到 wal 文件,下次啟動(dòng)重新按序回寫 wal 中的事務(wù)即可;
  4. wal 中所有的事務(wù) checkpoint 后,wal 文件會(huì)從頭開始使用;
  5. checkpoint 并不一定都會(huì)提交 wal 中全部的事務(wù),如果只是部分提交,下次寫入還是會(huì)寫入 wal 文件的末尾,wal 文件可能會(huì)變很大;
  6. 只有 truncate 的 checkpoint 才能清理已經(jīng)異常變大的 wal 文件,會(huì) truncate 文件大小到 0。

二. wal 實(shí)現(xiàn)?

wal 的實(shí)現(xiàn)大部分代碼集中在 wal.c 中,從 sqlite 的架構(gòu)劃分應(yīng)該主要算是 pager 層的實(shí)現(xiàn)。

https://www.sqlite.org/arch.html。wal 實(shí)現(xiàn)從邏輯上由 3 部分組成:

2.1 wal 和 wal-index 文件格式

文件格式定義,官方文檔見:

??https://www.sqlite.org/walformat.html??

??https://www.sqlite.org/fileformat2.html??

這一層細(xì)節(jié)比較多,主要是些二進(jìn)制定義。核心是 wal 格式提供了一種 page 格式的 redo log 組織格式,保證 crash 后 recover 過(guò)程滿足一致性。

wal-index 文件(db-shm)只是一種對(duì) wal 文件的快速索引,后文為了省事,也統(tǒng)稱 wal 文件。

2.2 文件多副本抽象

即 wal 和 db 文件對(duì)外表現(xiàn)為一個(gè)統(tǒng)一的文件抽象,并提供文件級(jí)別的 mvcc,對(duì) pager 層屏蔽 wal 細(xì)節(jié)。

由于 wal 和 db 一樣都是以 pgno 的方式索引 page,按 pgno 替換就可以構(gòu)造出不同版本的 b 樹,比較簡(jiǎn)單。mvcc 主要通過(guò) read lock 的 read mark 實(shí)現(xiàn),前面有介紹過(guò), 后面并發(fā)控制部分會(huì)詳細(xì)舉例介紹。

具體實(shí)現(xiàn)可看:

寫入:https://github.com/sqlite/sqlite/blob/version-3.15.2/src/pager.c#L3077

讀?。篽ttps://github.com/sqlite/sqlite/blob/version-3.15.2/src/wal.c#L2593

2.3 并發(fā)控制

通過(guò)文件鎖保證并發(fā)操作不會(huì)損壞數(shù)據(jù)庫(kù)文件,下一節(jié)詳細(xì)講解。

三. wal 下的并發(fā)

wal 支持讀讀、讀寫的并發(fā),相比最初的 rollback journal 模式提供了更大的并發(fā)力度。但 wal 實(shí)現(xiàn)的是文件級(jí)別的并發(fā),沒有 mysql 表鎖行鎖的概念,一個(gè) db 文件同時(shí)的并發(fā)寫事務(wù)同時(shí)只能存在一個(gè),不支持寫的同時(shí)并發(fā)。checkpoint 也可能會(huì) block 讀寫。

wal 并發(fā)實(shí)現(xiàn)上主要通過(guò)文件鎖,和文件級(jí)別 mvcc 來(lái)實(shí)現(xiàn)文件級(jí)別的讀寫并發(fā)。 鎖即下文源碼中的 WAL_CKPT_LOCK,WAL_WRITE_LOCK 和WAL_READ_LOCK,出于簡(jiǎn)化問(wèn)題考慮省略了 WAL_RECOVER_LOCK 等相關(guān)性不大的其他鎖的討論。mvcc 即通過(guò)文件多副本和 read mark 實(shí)現(xiàn),后文也會(huì)詳細(xì)介紹。

3.1 鎖的分類和作用

官方介紹:https://www.sqlite.org/walformat.html

可看 2.3.1節(jié) How the various locks are used

也可看下面簡(jiǎn)化分析:

圖片

3.2 鎖的持有情況

數(shù)據(jù)庫(kù)的訪問(wèn),可以分為 3 類:讀、寫和checkpoint。事務(wù)對(duì)鎖的持有不總是在事務(wù)一開始就持有,后文為了簡(jiǎn)化分析,會(huì)假設(shè)讀寫事務(wù)對(duì)鎖的持有在事務(wù)開始時(shí)是已知的,并且與事務(wù)同生命周期。實(shí)際在讀事務(wù)某些執(zhí)行路徑上也可能會(huì)持有 write lock,這里專注主線邏輯。

圖片

3.3 鎖的應(yīng)用

這部分可以和源碼分析部分參照起來(lái)看,是整個(gè) wal 里面相對(duì)復(fù)雜的部分,重點(diǎn),需要來(lái)回反復(fù)看。

commit transaction:表示已經(jīng)提交但沒有 checkpoint 的事務(wù),藍(lán)框中表示事務(wù)修改的頁(yè)面。

ongoing transition : 表示正在進(jìn)行中的事務(wù),同時(shí)也表示一個(gè)活躍的數(shù)據(jù)庫(kù)連接,藍(lán)線表示 read mark 的位置。

pgx.y: 表示 page 的頁(yè)號(hào)和版本。

圖片

3.3.1 讀寫

如圖可知:

  1. wal文件存在 4 個(gè)已經(jīng)提交的事務(wù)
    第一個(gè)事務(wù)修改了 page0,第二個(gè)事務(wù)修改了 page0、1、3,依此類推。
  2. 當(dāng)前數(shù)據(jù)庫(kù)上存在 4 個(gè)活躍的連接,包括 3 個(gè)讀事務(wù)和 1 個(gè)寫事務(wù);
  3. 寫事務(wù)獨(dú)占了 WAL_WRITE_LOCK,所以此時(shí)不能再發(fā)起一個(gè)寫事務(wù);
  4. 寫事務(wù)占有 1(4)讀鎖,所以寫事務(wù)讀取不到 read mark 4 之后的修改,只能讀取 read mark 4 之前的修改。即寫事務(wù)讀取 page4 時(shí)不能讀取到 page4.3,只能讀取 page4.0;
  5. 3 個(gè)讀事務(wù)占有 0(0),1(4),2(5)三個(gè)讀鎖,read mark 只能在事務(wù)結(jié)束的位置,不會(huì)處于中間 page 的位置;
  6. 后續(xù)如果發(fā)起一個(gè)讀事務(wù),會(huì)占有讀鎖 3(7)。理論上可以發(fā)起任意多個(gè)讀請(qǐng)求,讀鎖可以被 sqlite 連接共享。

3.3.2 checkpoint

這部分要和源碼分析結(jié)合,如果此時(shí)發(fā)起 checkpoint。

  1. 由于事務(wù) 0 持有 read lock 0,read mark 0,計(jì)算 mxSafeFrame 為 0,不會(huì)發(fā)生 checkpoint。
    如果事務(wù) 0 結(jié)束后發(fā)起 checkpoint。
  2. 由于寫事務(wù)存在,不能發(fā)起非 passive 的 checkpoint。
    如果事務(wù) 1 結(jié)束后執(zhí)行 checkpoint。
  3. 計(jì)算 mxSafeFrame 等于 4,會(huì)提交前 4 個(gè) page,沒有完全提交,wal 文件不會(huì)重新利用,新的寫入還是會(huì)寫入 commit transaction3 之后。
    如果所有事務(wù)結(jié)束后執(zhí)行 checkpoint。
  4. 提交所有頁(yè)面,下次寫入 wal 文件頭部。

四. checkpoint 源碼分析

源碼對(duì)應(yīng) sqlite 3.15.2,通過(guò)直接調(diào)用 checkpoint 觀察整個(gè)過(guò)程。

??https://github.com/sqlite/sqlite/tree/version-3.15.2/src??

4.1 調(diào)用鏈路

圖片

4.2 sqlite3_wal_checkpoint_v2

??https://github.com/sqlite/sqlite/blob/version-3.15.2/src/main.c#L2065??

主要是加鎖和一些參數(shù)校驗(yàn)。

4.3 sqlite3Checkpoint

??https://github.com/sqlite/sqlite/blob/version-3.15.2/src/main.c#L2146??

ndb 上循環(huán) checkpoint,大多數(shù)時(shí)候只有一個(gè) db 文件。

4.4 sqlite3BtreeCheckpoint

??https://github.com/sqlite/sqlite/blob/version-3.15.2/src/btree.c#L9472??

檢查 btree 是否 locked,也是前置檢查邏輯。

4.5 sqlite3PagerCheckpoint

??https://github.com/sqlite/sqlite/blob/version-3.15.2/src/pager.c#L7198??

也是前置的處理邏輯。不過(guò)有個(gè)和 checkpoint 邏輯有關(guān)的。

 /* 只在非SQLITE_CHECKPOINT_PASSIVE模式時(shí)設(shè)置xBusyHandler
* 即SQLITE_CHECKPOINT_PASSIVE時(shí)如果獲取不到鎖,立即返回,不進(jìn)行等待并retry
*/
if( pPager->pWal ){
rc = sqlite3WalCheckpoint(pPager->pWal, db, eMode,
(eMode==SQLITE_CHECKPOINT_PASSIVE ? 0 : pPager->xBusyHandler),
pPager->pBusyHandlerArg,
pPager->walSyncFlags, pPager->pageSize, (u8 *)pPager->pTmpSpace,
pnLog, pnCkpt
);
}

4.6 sqlite3WalCheckpoint

??https://github.com/sqlite/sqlite/blob/version-3.15.2/src/wal.c#L3192??

int sqlite3WalCheckpoint(
Wal *pWal, /* Wal connection */
int eMode, /* PASSIVE, FULL, RESTART, or TRUNCATE */
int (*xBusy)(void*), /* Function to call when busy */
void *pBusyArg, /* Context argument for xBusyHandler */
int sync_flags, /* Flags to sync db file with (or 0) */
int nBuf, /* Size of temporary buffer */
u8 *zBuf, /* Temporary buffer to use */
int *pnLog, /* OUT: Number of frames in WAL */
int *pnCkpt /* OUT: Number of backfilled frames in WAL */
){
int rc; /* Return code */
int isChanged = 0; /* True if a new wal-index header is loaded */
int eMode2 = eMode; /* Mode to pass to walCheckpoint() */
int (*xBusy2)(void*) = xBusy; /* Busy handler for eMode2 */
assert( pWal->ckptLock==0 );
assert( pWal->writeLock==0 );
/* EVIDENCE-OF: R-62920-47450 The busy-handler callback is never invoked
** in the SQLITE_CHECKPOINT_PASSIVE mode. */
assert( eMode!=SQLITE_CHECKPOINT_PASSIVE || xBusy==0 );
if( pWal->readOnly ) return SQLITE_READONLY;
WALTRACE(("WAL%p: checkpoint begins\n", pWal));

/* IMPLEMENTATION-OF: R-62028-47212 All calls obtain an exclusive
** "checkpoint" lock on the database file. */
// 獨(dú)占獲取WAL_CKPT_LOCK鎖
rc = walLockExclusive(pWal, WAL_CKPT_LOCK, 1);
if( rc ){
/* EVIDENCE-OF: R-10421-19736 If any other process is running a
** checkpoint operation at the same time, the lock cannot be obtained and
** SQLITE_BUSY is returned.
** EVIDENCE-OF: R-53820-33897 Even if there is a busy-handler configured,
** it will not be invoked in this case.
*/
testcase( rc==SQLITE_BUSY );
testcase( xBusy!=0 );
return rc;
}
pWal->ckptLock = 1;
/* IMPLEMENTATION-OF: R-59782-36818 The SQLITE_CHECKPOINT_FULL, RESTART and
** TRUNCATE modes also obtain the exclusive "writer" lock on the database
** file.
**
** EVIDENCE-OF: R-60642-04082 If the writer lock cannot be obtained
** immediately, and a busy-handler is configured, it is invoked and the
** writer lock retried until either the busy-handler returns 0 or the
** lock is successfully obtained.
*/
// 非SQLITE_CHECKPOINT_PASSIVE時(shí),獨(dú)占獲取WAL_WRITE_LOCK鎖,并進(jìn)行busy retry
if( eMode!=SQLITE_CHECKPOINT_PASSIVE ){
rc = walBusyLock(pWal, xBusy, pBusyArg, WAL_WRITE_LOCK, 1);
if( rc==SQLITE_OK ){
pWal->writeLock = 1;
}else if( rc==SQLITE_BUSY ){
eMode2 = SQLITE_CHECKPOINT_PASSIVE;
xBusy2 = 0;
rc = SQLITE_OK;
}
}
//如果wal-index顯示db有變化,unfetch db文件,和主線邏輯關(guān)系不大
/* Read the wal-index header. */
if( rc==SQLITE_OK ){
rc = walIndexReadHdr(pWal, &isChanged);
if( isChanged && pWal->pDbFd->pMethods->iVersion>=3 ){
sqlite3OsUnfetch(pWal->pDbFd, 0, 0);
}
}
/* Copy data from the log to the database file. */
if( rc==SQLITE_OK ){

if( pWal->hdr.mxFrame && walPagesize(pWal)!=nBuf ){
rc = SQLITE_CORRUPT_BKPT;
}else{
// checkpoint
rc = walCheckpoint(pWal, eMode2, xBusy2, pBusyArg, sync_flags, zBuf);
}
/* If no error occurred, set the output variables. */
if( rc==SQLITE_OK || rc==SQLITE_BUSY ){
if( pnLog ) *pnLog = (int)pWal->hdr.mxFrame;
if( pnCkpt ) *pnCkpt = (int)(walCkptInfo(pWal)->nBackfill);
}
}
// release wal index,非主線邏輯
if( isChanged ){
/* If a new wal-index header was loaded before the checkpoint was
** performed, then the pager-cache associated with pWal is now
** out of date. So zero the cached wal-index header to ensure that
** next time the pager opens a snapshot on this database it knows that
** the cache needs to be reset.
*/
memset(&pWal->hdr, 0, sizeof(WalIndexHdr));
}
// 釋放鎖,返回
/* Release the locks. */
sqlite3WalEndWriteTransaction(pWal);
walUnlockExclusive(pWal, WAL_CKPT_LOCK, 1);
pWal->ckptLock = 0;
WALTRACE(("WAL%p: checkpoint %s\n", pWal, rc ? "failed" : "ok"));
return (rc==SQLITE_OK && eMode!=eMode2 ? SQLITE_BUSY : rc);
}

4.7 walCheckpoint

??https://github.com/sqlite/sqlite/blob/version-3.15.2/src/wal.c#L1724??

static int walCheckpoint(
Wal *pWal, /* Wal connection */
int eMode, /* One of PASSIVE, FULL or RESTART */
int (*xBusy)(void*), /* Function to call when busy */
void *pBusyArg, /* Context argument for xBusyHandler */
int sync_flags, /* Flags for OsSync() (or 0) */
u8 *zBuf /* Temporary buffer to use */
){
int rc = SQLITE_OK; /* Return code */
int szPage; /* Database page-size */
WalIterator *pIter = 0; /* Wal iterator context */
u32 iDbpage = 0; /* Next database page to write */
u32 iFrame = 0; /* Wal frame containing data for iDbpage */
u32 mxSafeFrame; /* Max frame that can be backfilled */
u32 mxPage; /* Max database page to write */
int i; /* Loop counter */
volatile WalCkptInfo *pInfo; /* The checkpoint status information */
szPage = walPagesize(pWal);
testcase( szPage<=32768 );
testcase( szPage>=65536 );
pInfo = walCkptInfo(pWal);
if( pInfo->nBackfill<pWal->hdr.mxFrame ){
/* Allocate the iterator */
rc = walIteratorInit(pWal, &pIter);
if( rc!=SQLITE_OK ){
return rc;
}
assert( pIter );
/* EVIDENCE-OF: R-62920-47450 The busy-handler callback is never invoked
** in the SQLITE_CHECKPOINT_PASSIVE mode. */
assert( eMode!=SQLITE_CHECKPOINT_PASSIVE || xBusy==0 );
/* Compute in mxSafeFrame the index of the last frame of the WAL that is
** safe to write into the database. Frames beyond mxSafeFrame might
** overwrite database pages that are in use by active readers and thus
** cannot be backfilled from the WAL.
*/
mxSafeFrame = pWal->hdr.mxFrame;
mxPage = pWal->hdr.nPage;
/* 計(jì)算mxSafeFrame
* 會(huì)嘗試獨(dú)占的獲取aReadMark鎖,如果獲取到,則代表原先持有對(duì)應(yīng)aReadMark鎖的事務(wù)已經(jīng)結(jié)束。
* 會(huì)不斷的用busy rerty邏輯等待對(duì)應(yīng)的讀鎖釋放。
* 如果對(duì)應(yīng)事物一直沒有釋放aReadMark鎖,最終的 mxSafeFrame = MIN(unfinished_aReadMarks)
*/
for(i=1; i<WAL_NREADER; i++){
/* Thread-sanitizer reports that the following is an unsafe read,
** as some other thread may be in the process of updating the value
** of the aReadMark[] slot. The assumption here is that if that is
** happening, the other client may only be increasing the value,
** not decreasing it. So assuming either that either the "old" or
** "new" version of the value is read, and not some arbitrary value
** that would never be written by a real client, things are still
** safe. */
u32 y = pInfo->aReadMark[i];
if( mxSafeFrame>y ){
assert( y<=pWal->hdr.mxFrame );
// 嘗試獲取 WAL_READ_LOCK(i)鎖,并進(jìn)行忙等待
rc = walBusyLock(pWal, xBusy, pBusyArg, WAL_READ_LOCK(i), 1);
if( rc==SQLITE_OK ){
// 成功獲取 WAL_READ_LOCK(i)鎖,設(shè)置為READMARK_NOT_USED;i==1,是個(gè)treak,不影響主流程
pInfo->aReadMark[i] = (i==1 ? mxSafeFrame : READMARK_NOT_USED);
walUnlockExclusive(pWal, WAL_READ_LOCK(i), 1);
}else if( rc==SQLITE_BUSY ){
// 一直沒有獲取對(duì)應(yīng)WAL_READ_LOCK(i)鎖,設(shè)置mxSafeFrame為y
mxSafeFrame = y;
xBusy = 0;
}else{
goto walcheckpoint_out;
}
}
}
// 開始從wal文件寫回db文件,此時(shí)獨(dú)占的持有WAL_READ_LOCK(0)
if( pInfo->nBackfill<mxSafeFrame
&& (rc = walBusyLock(pWal, xBusy, pBusyArg, WAL_READ_LOCK(0),1))==SQLITE_OK
){
i64 nSize; /* Current size of database file */
u32 nBackfill = pInfo->nBackfill;
pInfo->nBackfillAttempted = mxSafeFrame;
/* Sync the WAL to disk */
if( sync_flags ){
rc = sqlite3OsSync(pWal->pWalFd, sync_flags);
}
/* If the database may grow as a result of this checkpoint, hint
** about the eventual size of the db file to the VFS layer.
*/
if( rc==SQLITE_OK ){
i64 nReq = ((i64)mxPage * szPage);
rc = sqlite3OsFileSize(pWal->pDbFd, &nSize);
if( rc==SQLITE_OK && nSize<nReq ){
sqlite3OsFileControlHint(pWal->pDbFd, SQLITE_FCNTL_SIZE_HINT, &nReq);
}
}
// 邏輯比較簡(jiǎn)單,遍歷并回寫
/* Iterate through the contents of the WAL, copying data to the db file */
while( rc==SQLITE_OK && 0==walIteratorNext(pIter, &iDbpage, &iFrame) ){
i64 iOffset;
assert( walFramePgno(pWal, iFrame)==iDbpage );
if( iFrame<=nBackfill || iFrame>mxSafeFrame || iDbpage>mxPage ){
continue;
}
iOffset = walFrameOffset(iFrame, szPage) + WAL_FRAME_HDRSIZE;
/* testcase( IS_BIG_INT(iOffset) ); // requires a 4GiB WAL file */
rc = sqlite3OsRead(pWal->pWalFd, zBuf, szPage, iOffset);
if( rc!=SQLITE_OK ) break;
iOffset = (iDbpage-1)*(i64)szPage;
testcase( IS_BIG_INT(iOffset) );
rc = sqlite3OsWrite(pWal->pDbFd, zBuf, szPage, iOffset);
if( rc!=SQLITE_OK ) break;
}
/* If work was actually accomplished... */
if( rc==SQLITE_OK ){
if( mxSafeFrame==walIndexHdr(pWal)->mxFrame ){
i64 szDb = pWal->hdr.nPage*(i64)szPage;
testcase( IS_BIG_INT(szDb) );
rc = sqlite3OsTruncate(pWal->pDbFd, szDb);
if( rc==SQLITE_OK && sync_flags ){
rc = sqlite3OsSync(pWal->pDbFd, sync_flags);
}
}
if( rc==SQLITE_OK ){
/* 更新nBackfill為已經(jīng)checkpoint的部分
* nBackfill記錄當(dāng)前已經(jīng)checkpoint的部分
*/
pInfo->nBackfill = mxSafeFrame;
}
}
/* Release the reader lock held while backfilling */
// 釋放 WAL_READ_LOCK(0)
walUnlockExclusive(pWal, WAL_READ_LOCK(0), 1);
}

if( rc==SQLITE_BUSY ){
/* Reset the return code so as not to report a checkpoint failure
** just because there are active readers. */
rc = SQLITE_OK;
}
}
/* If this is an SQLITE_CHECKPOINT_RESTART or TRUNCATE operation, and the
** entire wal file has been copied into the database file, then block
** until all readers have finished using the wal file. This ensures that
** the next process to write to the database restarts the wal file.
*/
// 非passive的checkpoint的區(qū)別都在這里
if( rc==SQLITE_OK && eMode!=SQLITE_CHECKPOINT_PASSIVE ){
assert( pWal->writeLock );
if( pInfo->nBackfill<pWal->hdr.mxFrame ){
// 沒有全部checkpoint
rc = SQLITE_BUSY;
}else if( eMode>=SQLITE_CHECKPOINT_RESTART ){
// RESTART or TRUNCATE
u32 salt1;
sqlite3_randomness(4, &salt1);
assert( pInfo->nBackfill==pWal->hdr.mxFrame );
// 獲取所有讀鎖, 保證下一個(gè)事物能夠重新開始restart,即循環(huán)利用wal文件
rc = walBusyLock(pWal, xBusy, pBusyArg, WAL_READ_LOCK(1), WAL_NREADER-1);
if( rc==SQLITE_OK ){
if( eMode==SQLITE_CHECKPOINT_TRUNCATE ){
/* IMPLEMENTATION-OF: R-44699-57140 This mode works the same way as
** SQLITE_CHECKPOINT_RESTART with the addition that it also
** truncates the log file to zero bytes just prior to a
** successful return.
**
** In theory, it might be safe to do this without updating the
** wal-index header in shared memory, as all subsequent reader or
** writer clients should see that the entire log file has been
** checkpointed and behave accordingly. This seems unsafe though,
** as it would leave the system in a state where the contents of
** the wal-index header do not match the contents of the
** file-system. To avoid this, update the wal-index header to
** indicate that the log file contains zero valid frames. */
walRestartHdr(pWal, salt1);
// Truncate wal文件
rc = sqlite3OsTruncate(pWal->pWalFd, 0);
}
walUnlockExclusive(pWal, WAL_READ_LOCK(1), WAL_NREADER-1);
}
}
}
walcheckpoint_out:
walIteratorFree(pIter);
return rc;
}

五. 常見問(wèn)題

5.1 checkpoint 何時(shí)觸發(fā)

  1. 手動(dòng)調(diào)用 checkpoint 觸發(fā);
  2. 通過(guò) sql 語(yǔ)句 PRAGMA wal_checkpoint 觸發(fā);
  3. sqlite 官方默認(rèn)的 checkpoint 閾值是 1000 page,即當(dāng) wal 文件達(dá)到 1000 page 大小時(shí),寫操作的線程在完成寫操作后同步進(jìn)行 checkpoint 操作;
  4. 當(dāng)最后一個(gè)連接 close 時(shí)觸發(fā)。

5.2 checkpoint 四種 mode 的區(qū)別

  1. passive 不會(huì)加寫鎖,也就是不會(huì) block 寫操作;
  2. 其他三種 mode 在回寫 db 結(jié)束之前的邏輯都是一樣。區(qū)別是 restart 會(huì)嘗試再次獨(dú)占獲取讀鎖,保證 restart 型的 checkpoint 正常結(jié)束后,下一個(gè)發(fā)起的事務(wù)會(huì)從頭開始循環(huán)利用 wal 文件。truncate 模式更近一步會(huì) truncate wal 文件。

5.3 wal 下讀寫和 checkpoint 的并發(fā)性

可看看上面不同操作對(duì)鎖的持有情況:

  1. 讀和讀可以同時(shí)進(jìn)行;
  2. 讀和寫可以同時(shí)進(jìn)行;
  3. checkpoint 和讀事務(wù)也存在很大程度的并發(fā),checkpoint 對(duì)讀鎖持有都是間歇性的,理論上都是耗時(shí)很短。仔細(xì)觀察上面的源碼分析部分,雖然會(huì)周期性持有讀鎖,基本上是等待讀事務(wù)釋放讀鎖,在真正耗時(shí)的 io 操作回寫 wal 日志到 db 的過(guò)程中,還是可以發(fā)起讀事務(wù)的。這種實(shí)現(xiàn) checkpoint 對(duì)讀存在著某種避讓,讀操作過(guò)于激進(jìn),會(huì)導(dǎo)致 checkpoint 饑餓,極端點(diǎn)會(huì)導(dǎo)致 wal 文件異常大;
  4. passive checkpoint 和寫事務(wù),理論上也是可以并發(fā);
  5. 非passive checkpoint 和寫事務(wù),理論上不可以并發(fā)。

5.4 wal 文件巨大的原因 & 如何解決

5.4.1 原因

wal 文件提供的操作模型非常簡(jiǎn)單,只有在一次完整的 checkpoint 后才會(huì)重頭開始循環(huán)利用 wal 文件,如果 checkpoint 一直沒有提交當(dāng)前的 wal 文件中所有更新,會(huì)導(dǎo)致 wal 文件無(wú)限增大。同時(shí)只有在 truncate 模式 checkpoint 才會(huì)縮減 wal 文件。

大概有以下原因會(huì)導(dǎo)致 wal 不能完全提交,核心都是 checkpoint 競(jìng)爭(zhēng)不到鎖。

  1. 非 passive 模式 checkpoint,需要獲取 write lock,但獲取不到;
  2. passive 模式 checkpoint 過(guò)程中,有并發(fā)的寫操作,導(dǎo)致 wal 中有未提交的日志;
  3. checkpoint 沒能及時(shí)獲取所以讀鎖。

在 checkpoint 中不能如預(yù)料中的獲得鎖,主要有兩種可能:

  1. 事務(wù)耗時(shí)很長(zhǎng),導(dǎo)致鎖遲遲不能釋放;
  2. 數(shù)據(jù)連接中存在鎖丟失的情況,導(dǎo)致 checkpoint 永遠(yuǎn)不能獲取到需求的鎖;
  3. 數(shù)據(jù)庫(kù)連接過(guò)多,導(dǎo)致 checkpoint 過(guò)程中競(jìng)爭(zhēng)不到鎖。

5.4.2 解決方案

綜上要解決 wal 無(wú)限增大主要有:

  1. 盡量把無(wú)關(guān)代碼移除事務(wù),保證事務(wù)只做數(shù)據(jù)庫(kù)相關(guān)的操作;
  2. 檢查代碼,避免出現(xiàn)鎖丟失的情況;
  3. 讀寫操作適當(dāng)退避,保證 checkpoint 有機(jī)會(huì)完全提交,而不總是部分提交。
責(zé)任編輯:龐桂玉 來(lái)源: 字節(jié)跳動(dòng)技術(shù)團(tuán)隊(duì)
相關(guān)推薦

2019-09-26 08:40:27

SqliteTips優(yōu)化

2009-03-04 09:11:20

類型親和性類型約束SQLite

2024-01-16 09:35:00

數(shù)據(jù)庫(kù)應(yīng)用

2023-07-30 17:34:53

KV存儲(chǔ)ChunkPosit

2012-03-06 09:13:04

Android SQLSQLiteAndroid

2011-08-01 10:21:01

SQLite

2011-06-02 10:24:48

Android SQLite

2025-04-14 02:00:00

SQLiteRedisRedka

2021-06-30 18:16:38

MySQLWal策略

2013-07-25 14:44:48

sqlite實(shí)例教程iOS開發(fā)學(xué)習(xí)sqlite打造詞典

2022-09-19 09:03:08

命令壓縮優(yōu)化

2011-07-05 10:22:44

Qt Sqlite

2011-08-22 16:42:43

SqliteiPad

2011-07-04 17:18:23

Qt SQLite 數(shù)據(jù)庫(kù)

2021-02-15 15:40:28

SQLite3數(shù)據(jù)庫(kù)

2022-08-04 11:10:03

日志優(yōu)化

2021-07-01 11:56:04

etcd-wal模塊解析數(shù)據(jù)庫(kù)

2011-07-20 12:34:49

SQLite數(shù)據(jù)庫(kù)約束

2019-08-15 07:00:54

SQLite數(shù)據(jù)庫(kù)內(nèi)存數(shù)據(jù)庫(kù)

2011-04-19 13:26:47

DB(BDB)SQLite
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)