Polardb Mini Transaction解决什么问题?

Mini Transaction

主要差异点：

backend推进日志走PG原生逻辑，不拆分mtr，在redo中对mtr涉及的多个页面统一处理（可能推多个页面）不会出现多backend因mtr读不一致的情况。startup推进日志处理mtr时统一加锁、放锁，避免backend因startup读到不一致页面

在这里插入图片描述

两个问题

1. backend之间导致读到mtr中间态
2. backend和stratup之间导致读到中间态

解决：

1. 原生redo逻辑避免问题1发生
2. mini transation lock新增逻辑保证问题2发生

栗子：

异常场景：索引分裂on page0 page1

• startup直接挂链，没有任何阻塞过程
• backend 0 把页面推到n+1
• backend 1 把页面推到n

page0与page1不一致

在这里插入图片描述

解决方法

• startup更新某一个页面的lsn list（挂链）之前，必须拿到页面的mini transaction lock
• 加锁流程
  • startup先拿到page0的mini transaction lock（获取锁的顺序和mtr的顺序一样）
  • 挂page0的链
  • startup拿到page1的mini transaction lock
  • 都挂完了再放锁
• backend互斥流程
  • 如果backend重放页面的时候发现startup**《在mini transaction中》**，在backend回放之前需要拿锁

场景： startup完成了page0的挂链，但没完成page1的挂链； 这时backend0访问page0，backend1访问page1； backend0无法推进page0直到startup把两个日志都挂完（mini放锁）； 拿到锁的时候，两条日志的挂链都已经完成了。

在这里插入图片描述

1 log meta是什么？

除了blockdata部分，其他就是log meta。

在这里插入图片描述

2 备库怎么使用log meta

在这里插入图片描述

1. 日志正常发送到wal buffer，并且把meta追加到wal meta queue上。
2. 同步提交的话，wal sender发送meta到备库
3. wal receiver收到之后，metadata挂到queue上，通知startup有新日志了。
4. startup读取metadata，解析到log index上

3 logindex结构

在这里插入图片描述

4 日志回放

For scenarios in which LogIndex Tables are used, the startup processes of read-only nodes generate LogIndex records based on the received WAL metadata and mark the pages that correspond to the WAL metadata and exist in buffer pools as outdated pages. This way, WAL logs for the next LSN can be replayed. The startup processes do not replay WAL logs. The backend processes that access the page and the background replay processes replay the logs. The following figure shows how WAL logs are replayed.

startup不在回放日志，backend进程在访问页面的时候执行回放的动作。

The background replay process replays WAL logs in the sequence of WAL logs. The process retrieves modified pages from LogIndex Memtables and LogIndex Tables based on the LSN of a page that you want to replay. If a page exists in a buffer pool, the page is replayed. Otherwise, the page is skipped.

The background replay process replays WAL logs generated for the next LSN of a page in a buffer pool in the sequence of LSNs. This prevents a large number of LSNs for a single page that you want to replay from being accumulated.

replay进程按照 WAL 日志的顺序重放 WAL 日志。

• 根据要重放的 LSN 从 LogIndex Memtables 和 LogIndex Tables 中检索修改过的页面。
• 如果缓冲池中存在页面，则重放该页面。
• 否则跳过该页面。
• 后台重放进程按照 LSN 的顺序重放，防止backend要重放一堆日志。

The backend process replays only the pages it must access. If the backend process must access a page that does not exist in a buffer pool, the process reads this page from the shared storage, writes the page to a buffer pool, and replays this page. If the page exists in a buffer pool and is marked as an outdated page, the process replays the most recent WAL logs of this page. The backend process retrieves the LSNs of the page from LogIndex Memtables and LogIndex Tables based on the value of PageTag. After the process retrieves the LSNs, the process generates the LSNs for the page in sequence. Then, the process reads the complete WAL logs from the shared storage based on the generated LSNs to replay the page.

• backend只重放它必须访问的页面。
• 如果后端进程必须访问缓冲池中不存在的页面，则该进程从共享存储中读取该页面，将该页面写入缓冲池，并重放该页面。
• 如果该页面存在于缓冲池中并被标记为过期页面，则该进程会重放该页面的最新 WAL 日志。
• 后端进程根据 PageTag 的值从 LogIndex Memtables 和 LogIndex Tables 中检索页面的 LSN。 在进程检索到 LSN 后，进程会依次为页面生成 LSN。 然后，该进程根据生成的 LSN 从共享存储中读取完整的 WAL 日志以重放页面。

在这里插入图片描述

• XLOG Buffer 缓存读取的 WAL 日志。 当从磁盘读取 WAL 日志以进行重播时，这会降低性能开销。 WAL 日志是从磁盘上的 WAL 段文件中读取的。 添加XLOG Page Buffer后，会优先从XLOG Buffer中读取WAL日志。
• 如果要重放的 WAL 日志不在 XLOG Buffer 中，则从磁盘读取 WAL 日志的页面，写入缓冲区，然后复制到 XLogReaderState 的 readBuf。
• 如果 WAL 日志在缓冲区中，则将日志复制到 XLogReaderState 的 readBuf。 减少了重放 WAL 日志所需执行的 I/O 操作数，提高重放 WAL 日志的速度。