postgresql流复制同异步分析


难度 中等

postgresql流复制主要是四个进程的交互。

  • postgres(backend进程)(主节点)

    接受客户端的请求,并通过共享内存等待walsender唤醒。

  • walsender(主节点)

    向walreceiver发送日志,通过tcp通信,采用流复制协议与walreceiver交互。

  • walreceiver(备节点)

    向walsender请求日志,并回复wal日志接收,写入,数据apply信息,通过tcp通信,采用流复制协议与walsender通信。

  • startup(备节点)

    进行日志回放,将wal日志redo成数据,通过共享内存和信号与walreceiver通信。

参数

流复制同异步由如下两个参数控制:

  • synchronous_commit

    用于指定同异步模式。

  • synchronous_standby_names

    用于指定同步时需要多少备节点确认。

synchronous_commit

配置解析

{"synchronous_commit", PGC_USERSET, WAL_SETTINGS,
            gettext_noop("Sets the current transaction's synchronization level."),
            NULL
        },
        &synchronous_commit,
        SYNCHRONOUS_COMMIT_ON, synchronous_commit_options,
        NULL, assign_synchronous_commit, NULL
static const struct config_enum_entry synchronous_commit_options[] = {
    {"local", SYNCHRONOUS_COMMIT_LOCAL_FLUSH, false},
    {"remote_write", SYNCHRONOUS_COMMIT_REMOTE_WRITE, false},
    {"remote_apply", SYNCHRONOUS_COMMIT_REMOTE_APPLY, false},
    {"on", SYNCHRONOUS_COMMIT_ON, false},
    {"off", SYNCHRONOUS_COMMIT_OFF, false},
    {"true", SYNCHRONOUS_COMMIT_ON, true},
    {"false", SYNCHRONOUS_COMMIT_OFF, true},
    {"yes", SYNCHRONOUS_COMMIT_ON, true},
    {"no", SYNCHRONOUS_COMMIT_OFF, true},
    {"1", SYNCHRONOUS_COMMIT_ON, true},
    {"0", SYNCHRONOUS_COMMIT_OFF, true},
    {NULL, 0, false}
};

配置不同的值代表不同的同步模式。

synchronous_standby_names

配置解析

{
        {"synchronous_standby_names", PGC_SIGHUP, REPLICATION_PRIMARY,
            gettext_noop("Number of synchronous standbys and list of names of potential synchronous ones."),
            NULL,
            GUC_LIST_INPUT
        },
        &SyncRepStandbyNames,
        "",
        check_synchronous_standby_names, assign_synchronous_standby_names, NULL
    },
SyncRepConfig = (SyncRepConfigData *) extra;

在check_synchronous_standby_names中解析后最终将其赋值给了SyncRepConfig。

synchronous_standby_names可以配置为某个具体的备节点名,也可以配置成any 1(*)的形式。

如

synchronous_standby_names = 'standby001'

或者

synchronous_standby_names='ANY 1 (*)'

walsender进程处理同步

graph TB ProcessStandbyMessage-->|walsender收到walreceiver回复的r报文|ProcessStandbyReplyMessage -->|唤醒满足条件的backend进程|SyncRepReleaseWaiters -->|计算备库的回复确认是否满足要求,同时会计算writePtr,flushPtr,applyPtr|SyncRepGetSyncRecPtr -->|获取候选者个数|SyncRepGetCandidateStandbys -->|SYNC_REP_PRIORITY优先级模式计算ptr,最旧的|SyncRepGetOldestSyncRecPtr SyncRepGetCandidateStandbys-->|非优先级模式计算ptr,第n个|SyncRepGetNthLatestSyncRecPtr

收到walreceiver的确认报文,walsender需要判断回复的standby个数是否满足配置的要求。SyncRepGetSyncRecPtr中会计算已经回复的standby个数并和配置的值进行比较,若满足则会返回true,否则返回false。

got_recptr = SyncRepGetSyncRecPtr(&writePtr, &flushPtr, &applyPtr, &am_sync);
if (!got_recptr || !am_sync)    { // 若确认的standby个数不足或者不是sync模式直接返回
    LWLockRelease(SyncRepLock);
    announce_next_takeover = !am_sync;
    return;
}

若确认的standby个数不足或者不是sync模式直接返回;

若确认的standby个数满足,且是sync模式,则需要唤醒对应模式的backend进程。

    if (walsndctl->lsn[SYNC_REP_WAIT_WRITE] < writePtr)
{
    walsndctl->lsn[SYNC_REP_WAIT_WRITE] = writePtr;
    numwrite = SyncRepWakeQueue(false, SYNC_REP_WAIT_WRITE);
}
if (walsndctl->lsn[SYNC_REP_WAIT_FLUSH] < flushPtr)
{
    walsndctl->lsn[SYNC_REP_WAIT_FLUSH] = flushPtr;
    numflush = SyncRepWakeQueue(false, SYNC_REP_WAIT_FLUSH);
}
if (walsndctl->lsn[SYNC_REP_WAIT_APPLY] < applyPtr)
{
    walsndctl->lsn[SYNC_REP_WAIT_APPLY] = applyPtr;
    numapply = SyncRepWakeQueue(false, SYNC_REP_WAIT_APPLY);
}

此时唤醒对应的后端进程后,后端进程将回复客户端。

可以看到,针对不同的同步模式,唤醒后端进程采用的是不同的lsn指针。

switch (newval)
{
    // 备库接收到wal日志并写入缓存
    case SYNCHRONOUS_COMMIT_REMOTE_WRITE:
        SyncRepWaitMode = SYNC_REP_WAIT_WRITE;
        break;
    // 备库接收到日志并写入磁盘
    case SYNCHRONOUS_COMMIT_REMOTE_FLUSH:
        SyncRepWaitMode = SYNC_REP_WAIT_FLUSH;
        break;
    // 备库接收到日志写入磁盘并且redo数据也写到磁盘
    case SYNCHRONOUS_COMMIT_REMOTE_APPLY:
        SyncRepWaitMode = SYNC_REP_WAIT_APPLY;
        break;
    default:
        SyncRepWaitMode = SYNC_REP_NO_WAIT;
        break;
}

对于SYNC_REP_WAIT_WRITE,使用的是writePtr唤醒后端进程。

对于SYNC_REP_WAIT_FLUSH,使用的是flushPtr唤醒后端进程。

对于SYNC_REP_WAIT_APPLY,使用的是applyPtr唤醒后端进程。


文章作者: growdu
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 growdu !
  目录
分类导航
随笔3 AI29 计算机基础13 算法1 博客搭建7 ChatGPT2 集群63 计算机通信1 数据库59 数据库深入93 数据库93 Docker11 DPDK26 编辑工具4 Elasticsearch4 FAQ1 Go Web1 hometown2 编程语言16 人生11 网络9 Linux38 OPC1 openGauss4 页面12 PostgreSQL54 程序员自我修养1 协议11 stock1 存储5 成长之路1 工具20 视频作品1 VPP18 Vue13 Web1 代码示例11 BenchmarkSQL1 PostgreSQL 源码修炼之路14
最热文章
1
PostgreSQL 逻辑复制全链路:以一个真实事务为例,从 `INSERT` 到 `apply` 的源码级旅程
数据库🔥 2162
2
PostgreSQL 逻辑复制 Stream 执行逻辑源码级拆解:从 reorderbuffer 触发到订阅端落盘回放
数据库🔥 1765
3
PostgreSQL 行锁机制源码级深度拆解:4 种锁模式 + xmax + MultiXact 的完整链路
数据库🔥 1656
4
PostgreSQL reorderbuffer.c 函数级源码全集:5615 行 / 95 个函数的逐函数解析
数据库深入🔥 1650
5
PostgreSQL 目录快照源码级深度拆解:系统表读取的 MVCC 真相与失效机制
数据库🔥 1604
6
13 逻辑复制深入
数据库深入🔥 1570
7
0 Postgresql存储、索引及系统优化、主备切换
PostgreSQL🔥 1495
8
PostgreSQL 读一行数据源码级深度拆解:MVCC 在每个环节的落点
数据库🔥 1464
9
PostgreSQL WAL 记录类型完全指南:21 个 RMGR × 80+ 种记录的源码级拆解
数据库🔥 1431
10
一文读懂openguass dcf网络模块
集群🔥 1420
11
PostgreSQL 元数据存储机制:从磁盘文件到内存缓存,`pg_class` 撑起的整个系统表体系
数据库🔥 1411
12
openGauss 并行解码设计原理深度拆解:reader + 多 worker + CSN 三层架构的源码级剖析
数据库深入🔥 1344
13
逻辑复制源码分析
数据库深入🔥 1327
14
PostgreSQL 逻辑复制:catalog 改动、可见性判定与 xmin/xmax 推进全景
数据库深入🔥 1317
15
自托管服务全家桶:从原文方案到可复制实操手册
人生🔥 1278
16
PostgreSQL CREATE_REPLICATION_SLOT 端到端源码分析:从 SQL 到 snapbuild 状态机的完整链路(每个函数每个参数)
数据库深入🔥 1277
17
PostgreSQL syscache 模块源码深度拆解:CatCache 数据结构、LRU 哈希表、cache invalidation 全链路
数据库深入🔥 1216
18
PostgreSQL 18 内核数据结构全景:RangeVar 与 20+ 个核心数据结构源码级拆解
数据库🔥 1158
19
PostgreSQL 逻辑复制里 `RUNNING_XACTS` 写入机制与快照 `xmin / xmax / xip` 的演化:源码级深度拆解
数据库🔥 1119
20
PostgreSQL 分区表:从一行 `PARTITION BY` 到路由热路径的全链路拆解
数据库🔥 1094