postgresql逻辑复制槽的推进

逻辑复制槽为什么要推进?

  • 我们知道逻辑复制槽有两个作用,一个是保护系统表避免被vacuum,一个是保护xlog,防止需要解码的xlog被回收
  • 如果系统表不往前推进,则系统表就会发生膨胀
  • 如果xlog不往前推进,xlog就会堆积在磁盘。
  • 所以,我们根据当前逻辑复制的进度,推进逻辑复制槽

逻辑复制槽的推进主要表现在哪些字段的推进?

  • 对于xlog,与物理复制槽相同,通过restart_lsn控制
  • 对于系统表,通过catalog_xmin控制

restart_lsn的推进

  • 物理复制restart lsn的推进比较简单,当备机flush某个lsn以后,告诉主机,主机收到后,立即就会推进restart lsn
  • 而逻辑复制,则相对比较复杂。
    • 我们用confirmed_flush表示当前订阅端逻辑复制的进度。但是,不是说confirmed_flush之前的xlog就可以回收。

    • 因为逻辑解码需要历史快照,而历史快照的构建本质就是根据running_xacts以及后续的commit等xlog来完成的

    • 所以为了能够解析后面的xlog,restart lsn还要对后续解码需要用的快照xlog进行保护。

    • 那么此时就得看confirmed_flush更新时,需要用到的最老的快照lsn是多少了。

    • 所以我们用两个lsn实现restart_lsn的推进,candidate_restart_valid就表示当前解码的进度lsn,而candidate_restart_lsn表示解码到candidate_restart_valid的时候,需要用的最老的快照的lsn。

    • 当confirmed_flush超过candidate_restart_valid时,就可以推进restart_lsn到candidate_restart_lsn了,可以进行更新了。

      // 主机或者发布端收到备机或订阅端的flush后的处理
      ProcessStandbyReplyMessage(void)
      {
      if (MyReplicationSlot && flushPtr != InvalidXLogRecPtr)
      {
      if (SlotIsLogical(MyReplicationSlot))
      LogicalConfirmReceivedLocation(flushPtr);
      else
      PhysicalConfirmReceivedLocation(flushPtr);
      }
      }

      // 物理复制槽,只要备机flush某个lsn,主机收到后,立即就会推进restart lsn
      PhysicalConfirmReceivedLocation(XLogRecPtr lsn)
      {
      if (slot->data.restart_lsn != lsn)
      {
      changed = true;
      slot->data.restart_lsn = lsn;
      }
      }

      // 逻辑复制槽,如果订阅端flush了某个lsn,并不会直接推进restart lsn。而是根据candidate的情况,判断是否推进restart lsn。
      // 如果可以就推进,如果不行,只把当前订阅端flush的lsn记录到confirmed_flush
      LogicalConfirmReceivedLocation(XLogRecPtr lsn)
      {
      if (MyReplicationSlot->candidate_xmin_lsn != InvalidXLogRecPtr ||
      MyReplicationSlot->candidate_restart_valid != InvalidXLogRecPtr)
      {
      if (MyReplicationSlot->candidate_restart_valid != InvalidXLogRecPtr &&
      MyReplicationSlot->candidate_restart_valid <= lsn)
      {
      MyReplicationSlot->data.restart_lsn = MyReplicationSlot->candidate_restart_lsn;
      MyReplicationSlot->candidate_restart_lsn = InvalidXLogRecPtr;
      MyReplicationSlot->candidate_restart_valid = InvalidXLogRecPtr;
      updated_restart = true;
      }
      }
      else
      {
      SpinLockAcquire(&MyReplicationSlot->mutex);
      MyReplicationSlot->data.confirmed_flush = lsn;
      SpinLockRelease(&MyReplicationSlot->mutex);
      }
      }

      // 为什么逻辑复制不能直接根据flush推进restart lsn呢?
      // 因为逻辑解码需要历史快照,而历史快照的构建本质就是根据running_xacts以及后续的commit等xlog来完成的
      // 所以为了能够解析后面的xlog,restart lsn还要保护对后续xlog解码需要用的快照xlog进行保护。
      // 因为,我们每次会在解析running_xacts后,序列化一次快照,所以我们可以在此时推进一下我们需要保护的lsn,也就是所谓的candidate
      // 等订阅端的flush满足条件后,就可以真正的推进restart lsn了
      SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
      {
      // 处理running_xacts后,序列化一次快照
      SnapBuildSerialize(builder, lsn);

      复制代码
      // 我们从reorder buffer中找最老的txn,这样我们就可以获取最老的需要保护的xlog
      txn = ReorderBufferGetOldestTXN(builder->reorder);
      if (txn != NULL && txn->restart_decoding_lsn != InvalidXLogRecPtr)
          LogicalIncreaseRestartDecodingForSlot(lsn, txn->restart_decoding_lsn);
      // 如果当前没有在处理的事务,则使用最新序列化的快照位置即可
      else if (txn == NULL &&
               builder->reorder->current_restart_decoding_lsn != InvalidXLogRecPtr &&
               builder->last_serialized_snapshot != InvalidXLogRecPtr)
          LogicalIncreaseRestartDecodingForSlot(lsn,
                                                builder->last_serialized_snapshot);

      }

      // 这里有两个lsn,candidate_restart_valid是一个参照物,他是当前的lsn,当订阅端confirmed_flush超过他的时候,就可以推进此时对应的restart_lsn
      // 为什么这么设计?因为confirmed_flush只代表flush的进度,或者说只代表解码的xlog进度,而不代表快照的xlog进度。
      LogicalIncreaseRestartDecodingForSlot(XLogRecPtr current_lsn, XLogRecPtr restart_lsn)
      {
      if (current_lsn <= slot->data.confirmed_flush)
      {
      slot->candidate_restart_valid = current_lsn;
      slot->candidate_restart_lsn = restart_lsn;
      updated_lsn = true;
      }

      复制代码
      if (slot->candidate_restart_valid == InvalidXLogRecPtr)
      {
          slot->candidate_restart_valid = current_lsn;
          slot->candidate_restart_lsn = restart_lsn;
      }
      
      if (updated_lsn)
          LogicalConfirmReceivedLocation(slot->data.confirmed_flush);

      }

catalog_xmin的推进

  • 与restart lsn的推进是类似的。

  • 在序列化快照的时候,使用candidate_xmin_lsn表示当前解码的进度,使用candidate_catalog_xmin表示当前解码需要用的最老xmin

  • 当confirmed_flush超过candidate_xmin_lsn的时候,就可以更新复制槽的catalog_xmin为candidate_catalog_xmin了

    SnapBuildProcessRunningXacts(SnapBuild *builder, XLogRecPtr lsn, xl_running_xacts *running)
    {
    SnapBuildSerialize(builder, lsn);
    xmin = ReorderBufferGetOldestXmin(builder->reorder);
    LogicalIncreaseXminForSlot(lsn, xmin);
    }

    LogicalIncreaseXminForSlot(XLogRecPtr current_lsn, TransactionId xmin)
    {
    if (current_lsn <= slot->data.confirmed_flush)
    {
    slot->candidate_catalog_xmin = xmin;
    slot->candidate_xmin_lsn = current_lsn;
    updated_xmin = true;
    }
    else if (slot->candidate_xmin_lsn == InvalidXLogRecPtr)
    {
    slot->candidate_catalog_xmin = xmin;
    slot->candidate_xmin_lsn = current_lsn;
    }
    }

相关推荐
dragoooon3415 分钟前
仿muduo库实现高并发服务器-面试常见问题
运维·服务器·面试
老蒋新思维40 分钟前
创客匠人启示录:AI 时代知识变现的底层逻辑重构 —— 从峰会实践看创始人 IP 的破局之路
网络·人工智能·网络协议·tcp/ip·数据挖掘·创始人ip·创客匠人
码农爱学习1 小时前
使用wpa工具配网、udhcpc分配IP的过程分析
网络·网络协议·tcp/ip
北京盛世宏博2 小时前
边缘计算赋能!机房机柜微环境温湿度快速响应控制方案
运维·服务器·网络
老蒋新思维2 小时前
创客匠人深度洞察:创始人 IP 打造的非线性增长模型 —— 知识变现的下一个十年红利
大数据·网络·人工智能·tcp/ip·重构·数据挖掘·创客匠人
北京耐用通信2 小时前
协议转换的‘魔法转换器’!耐达讯自动化Ethernet/IP转Devicenet如何让工业机器人‘听懂’不同咒语?”
网络·人工智能·科技·网络协议·机器人·自动化·信息与通信
日更嵌入式的打工仔2 小时前
EtherCAT 主站2
网络·ethercat
油丶酸萝卜别吃2 小时前
堡垒机的集中管控具体体现在哪些方面?
服务器
飞Link2 小时前
【轻量拓展区】网络 QoS 与带宽、延迟、抖动:AI 推理的性能瓶颈
开发语言·网络·人工智能
真正的醒悟3 小时前
图解网络22
服务器·网络·php