準(zhǔn)備
CreateCheckpoint，或者bgwriter啟動(dòng)時(shí)，或者創(chuàng)建logicalreplicationslot時(shí)都會(huì)調(diào)用LogStandbySnapshot 記錄一個(gè)XLOG_RUNNING_XACTS類型的日志。日志中記錄了所有提交的事務(wù)的xid(HistoricSnapshot)
啟動(dòng)（SNAPBUILD_BUILDING_SNAPSHOT）
當(dāng)接收端讀到 XLOG_RUNNING_XACTS 時(shí)，調(diào)用SnapBuildProcessRunningXacts開始記錄所有看到的日志，但此時(shí)只知道提交的事務(wù)，不知道進(jìn)行中的事務(wù)。在沒有完整事務(wù)狀態(tài)的情況下，接收端是不能開始apply日志的。這時(shí)日志中記錄的 nextxid(1) 就是這之后再開啟事務(wù)時(shí)的最小事務(wù)號(hào)。
組裝事務(wù)狀態(tài)（SNAPBUILD_FULL_SNAPSHOT）
當(dāng)接收端再收到 XLOG_RUNNING_XACTS 時(shí)，如果發(fā)現(xiàn)nextxid(1)之前的日志都提交了，就證明當(dāng)前從日志收集過的事務(wù)，已經(jīng)是全部在運(yùn)行的事務(wù)了，沒有不知道的事務(wù)，此時(shí)事務(wù)狀態(tài)是完整的，但因?yàn)橹笆盏降姆鞘聞?wù)的 log 都人為丟棄了，不能對這些事務(wù) apply log，因?yàn)槭聞?wù)不完整，這時(shí)nextxid(２)記錄的就是之后再開啟事務(wù)的時(shí)的最小事務(wù)號(hào) 。
這時(shí)每次 apply 前要判斷，要 apply 的這個(gè)事務(wù)的xid是否在nextxid(２)之前，如果是之前的就不apply，之后的才apply（SnapBuildProcessChange）。
第一次apply的時(shí)候會(huì)記錄一個(gè)完整的HistoricSnapshot作為basesnapshot
事務(wù)狀態(tài)已完整（SNAPBUILD_CONSISTENT）
當(dāng)接收端再收到 XLOG_RUNNING_XACTS 時(shí)，如果發(fā)現(xiàn)nextxid(２)之前的日志都提交了，說明以后收到的 log一定可以 apply，不用再做上面的判斷了。
第一次到這個(gè)狀態(tài)時(shí)會(huì)寫一個(gè).snap文件
文章來源：http://www.zghlxwxcb.cn/news/detail-620525.html
新的事務(wù)提交日志(SnapBuildCommitTxn)
在每次處理事務(wù)提交日志時(shí)，它會(huì)感知所有修改系統(tǒng)表的事務(wù)，把它們加入新snapshot中（SnapBuildAddCommittedTxn），并把這個(gè)新的 snapshot 掛到所有事務(wù)的reorderbuffer中（SnapBuildDistributeNewCatalogSnapshot）。當(dāng)其它事務(wù)commit時(shí)（DecodeCommit），檢查reorder_buffer（ReorderBufferCommit），就會(huì) apply 這個(gè) snapshot （TeardownHistoricSnapshot + SetupHistoricSnapshot）文章來源地址http://www.zghlxwxcb.cn/news/detail-620525.html
到了這里，關(guān)于postgresql四種邏輯復(fù)制的狀態(tài)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
