Libcomm 通信库cid:link_4producer 线程cid:link_0通信流cid:link_5TCP代理通信库cid:link_6CN多流cid:link_7集群通信常见问题cid:link_1数据收发过程中报错 cid:link_8使用通信中的视图进行分析cid:link_2增量备份核心设计cid:link_3差分增量备份cid:link_9Checkpoint 操作cid:link_10CBM文件的命名格式cid:link_11Roach的集群级备份cid:link_12流程分析cid:link_13日志回收https://bbs.huaweicloud.com/forum/thread-02107197297724506124-1-1.html

日志是查看代码运行状态和错误定位的重要文件，Roach内核的回收日志只能保证一个日志回收点：$GAUSSLOG/roach/。Roach日志的管理可分为三类： agent文件夹保存了内核侧生成的日志； controller文件夹保存了python侧的调度信息； frame文件夹保存了双集群容灾过程中python侧代码生成的日志。缺省情况下，内核日志仅记录警告及以上级别的消息。Roach工具支持的日志级别，默认只有ERROR和Warning级别日志。执行命令可开启INFO级别日志，--logging –logging-level INFO 如果备份或恢复操作失败，可查看控制台中显示的错误汇总，识别发生错误的主机。 系统日志 Linux记录系统事件至系统日志中。Roach工具将FATAL及ERROR消息记入相同的系统日志文件。例如，在运行SUSE Linux操作系统的设备上，Roach写日志到/var/log/messages文件。 安全日志 用户可以保存所有活动信息到文件中。安全日志文件包括时间戳，以及备份，恢复和生成文件的详细信息。安全日志文件的文件名称格式如下：roach-agentsecurity-YYYY-MM-DD_HHMMSS.log。 控制器日志 控制器日志为python脚本运行日志，用户可以保存控制器日志信息到文件中。 控制器日志文件的格式如下：roach-controller-YYYY-MMDD_HHMMSS.log。例如：roach-controller-2015-12-15_203415.log 

根据GaussDB(DWS)数据库的功能结构，全量备份按照以下顺序备份所需要的文件： 数据库相关的配置文件。 行存全部数据：GaussDB(DWS) A数据库支持行存。 xlog日志文件：Roach支持在线业务的备份，则通过备份xlog日志文件可在恢复时将备份期间的业务Redo，保证数据一致性。 列存全部数据： GaussDB(DWS) A数据库支持列存。 备份的数据按照每个节点为单位进行备份，所以每个节点都只存储当前节点的备份。结合Roach工具备份调度流图和日志信息分析如下： 整个备份流程的上层代码为python代码，即GaussRoach.py，master进程的创建和agent进程的拉起都是由python侧完成的。备份的配置和参数部分检查过程同样是由python侧代码完成。各个节点agent进程被拉起之后，C侧代码进行具体的业务操作。C侧代码运行起来之后，可以通过ps ux到gs_roach进程查看进程状态。备份的数据会进行压缩后写入到rch文件后存储到备份路径下的实例文件夹下，且每个rch文件大小是4GB； 存放路径：[存储路径]/roach/backupkey/hostname/，其中存储路径为备份命令中指定的--media-destination的值，backupkey为当前备份开始的时间作为标识某个特定的备份集，hostname为当前节点的hostname。

Roach的集群级备份采用的是物理备份，即通过物理文件拷贝的方式对数据库进行备份，通过备份的数据文件及日志等文件，数据库可以进行完全恢复。全量备份则是将当前时间点数据库中所有的数据进行备份。当然，全备份可以备份整块硬盘、整个分区或某个具体的目录。全备份的好处是数据恢复方便，因为所有的数据都在同一个备份中，所以只要恢复全备份，所有的数据都会被恢复。 其优点是：物理备份速度快，通过合理规划，可以低成本进行备份和恢复； 其缺点是：相较于增量备份备份时间较长。Roach备份采用生产者-消费者模式，下图展现了备份流程各个线程及IO交互图。exec线程作为生产者，同时为减轻exec线程的压力，增加并行的reader线程读取小文件；sender线程作为消费者；中间则是通过一个256MB（可设置）的大buffer衔接。GaussDB(DWS)内核的备份组件为GaussRoach.py和gs_roach，需在集群内拉起备份任务。GaussRoach.py：Roach单集群全量备份入口为GaussRoach.py。每次命令行输入“python GaussRoach.py –t backup…”后，roach的python语言模式就开始运行。任意节点均可作为主节点拉起GaussRoach.py，然后每个节点都启动gs_roach进程负责本节点备份，各节点并行备份，节点内各DN并行备份。   

CBM 文件保存在data 目录的pg_cbm 文件夹下，命名方式为：pg_xlog_seqnum_startlsn_endlsn.cbm。seqnum文件序号表示这是第几个cbm文件，当一个cbm文件的大小超过100M时，将会切换到下一个cbm文件，并将seqnum加1。 startlsn为本cbm文件内容对应xlog记录的起始lsn； endlsn为本cbm文件切换时最后一次解析的截止lsn，若一个cbm文件还没有切换，那么endlsn为0。pg_cbm_tracked_location 说明：用于查询cbm已经解析到的lsn位置 入参：无 返回值：cbm已经解析到的lsn位置 b. pg_cbm_get_merged_file 说明：用于将指定lsn范围之内的cbm文件合并成一个cbm文件 入参：startlsn，指定的起始lsn；endlsn，指定的结束lsn 返回值：合并完的cbm文件名 c. pg_cbm_get_changed_block 说明：用于将指定lsn范围之内的cbm文件合并一个表，并返回表的各行记录 入参：startlsn，指定的起始lsn；endlsn，指定的结束lsn 返回值：合并完的表的记录，表的结构如下

当系统运行时间较长的时候，由于操作较多，日志文件的数量也较多。如果每次利用日志进行恢复操作都会耗费大量的时间，为了节约时间同时减少不必要的恢复操作，引入了checkpoint的概念。checkpoint表示在此操作之前，相关数据已经被保存到永久存储中，即使系统故障，这部分数据也不会丢失，因此恢复的时候只要从checkpoint操作之后根据日志执行恢复操作就可以了。checkpoint本身也是一条xlog记录，该记录包含了redo点的位置，因此，每次恢复数据时，先从xloh记录里找到最近的一次checkpoint记录，并根据该记录找到相应的redo点位置，这就是执行本次恢复的起始点位置。checkpoint操作记录了redo点的位置。基于上述功能，由于数据的所有变化都被记录在了xlog中，GaussDB(DWS)数据库内核通过增加常驻的CBM writer线程，持续不断地对新增的xlog进行解析，识别并记录哪些数据数据页面被修改。进程启动时即开启CBM writer功能 在startup线程刚启动时，其根据已经解析出来的CBM文件，来决定CBM writer开始解析的起始LSN位置。每次执行到checkpoint末尾时，会设置CBM writer线程的latch。CBM writer线程等待latch被设置，然后进行一轮日志解析。 通过动态reload GUC参数，开启CBM writer功能 由于是动态开启的CBM writer功能，因此startup线程没有初始化CBM解析的起始位置。打开enable_cbm_writer开关的同时，会将CBM强制初始化的标志置为true。当CBM writer线程启动之后，其第一次解析中，会强制初始化获得解析的起始lsn。

如果一次全量备份后的多次增量备份，指定的prior-backup-key均为上一次备份（可能是全量备份也可能增量备份）的backup-key，即此次备份是基于上一次备份集来进行的，那么这些增量备份就是差分增量备份，差分增量备份均是基于最近一次备份进行的。增量备份只需要备份上一备份节点到当前时间发生变化的数据文件，为了实现备份数据的完整性与一致性，正确识别并备份增量数据文件是至关重要的，作为增量备份的核心GaussDB(DWS)数据库内核的事务日志功能与cbm设计可以帮助Roach工具快速准确识别增量期间数据文件的变换信息，为快速准确完成增量备份提供了有力保障。为了保证数据的一致性和完整性，在对数据进行相关操作之前都会将具体的操作记录下来，持久化到可靠存储中，然后再进行具体的数据操作，这就是所谓的WAL（Write Ahead Logging），记录的相关操作称为XLOG日志，每一条日志记录都由LSN进行唯一标识。这样做的好处是事务的记录被提前记录并保存起来，在因一些外部原因（比如断电、操作系统失败等）导致操作失败后，我们可以通过保存的事务日志将这些操作重新执行一遍，保证数据不会丢失。

增量备份指备份基于上一个备份集到当前阶段的数据变化文件，相比于全量备份所用的时间更少，能够节约大量的空间资源，因此一直是客户的常规备份手段。为了实现数据的完整性与一致性，正确识别并备份增量数据文件是至关重要的，Gauss(DWS)数据库内核的事务日志功能与CBM设计可以帮助Roach工具快速准确识别增量期间数据文件的变换信息，从而快速实现增量备份的任务。GaussDB(DWS)数仓的备份恢复工具Roach支持集群级增量备份。全量备份会将源数据完整备份，而增量备份仅将上次备份后所作的更改进行备份，这里的上次备份可以使全量备份，也可以是全量备份后的增量备份。需要注意的是，增量备份的基础始终是全量备份，如果一次全量备份之后进行了全量恢复，则不能再基于该全量备份进行增量备份，必须重新进行全量备份然后基于新的全量备份进行增量备份。 增量备份分为两种：累积增量备份和差分增量备份。如果一次全量备份后的多次增量备份，指定的prior-backup-key始终为全量备份的backup-key，即所有的增量备份都是基于全量备份来进行的，那么这些增量备份就是累积增量备份，累积增量备份均是基于最近一次全量备份进行的。

组合使用pgxc_stat_activity 、 pgxc_thread_wait_status 、pgxc_comm_send_stream、pgxc_comm_recv_stream视图定位问题 在pgxc_stat_activity 视图中找到问题查询的query_id; 根据query_id查询pgxc_thread_wait_status 视图，看到 CN 在等DN4的数据，而DN4在与DN42建连;查询pgxc_comm_send_stream看到DN4发起的与DN2的逻辑连接中有一个处于READY半连接状态；查询pgxc_comm_recv_stream看到DN2已经接受了DN4发起的4个逻辑连接，问题出在DN4逻辑连接应答上。DN间接收数据分两个动作 LibcommRecvPoll，等待数据到达； LibcommRecv，数据到达后接收数据。 Poll Time：等待数据到达所花费的时间； Send time：发送数据并接收对端quota所花费的时间。在GaussDB(DWS)通信运维中，很多情况是由于一些参数配置的不合理导致集群效率低、资源过载、连接异常等问题。对于通信库和操作系统两方面都提供了大量可供用户自定义的参数、视图、脚本，熟练掌握一些重要工具有助于快速定位现网通信故障问题。 

CN 连接DN报错, 主要关注后面的detail信息 Already too many client：DN线程数超过max_connections上限； Connection timed out：TCP建连超时，网络不通或者网络质量差； Connection refused：TCP建连被拒绝，防火墙配置或者端口号错误； timeout expired：连接已经建立，但连接信息同步时对端响应超时。 数据收发过程中报错 cancel/terminate日志：外部信号中止查询； reset by peer/broken pipe：连接对端线程主动关闭连接； Stream closed by remote：对端关闭连接或发生重启，需查看对端日志； Peer address changed：对端DN存在主备切换。 DN 间通信性能差 pv_total_memory_detail中通信内存过大：Libcomm通信库降级运行； gsar监控有严重丢包重传：网络质量差，丢包过多导致连接断开； top查看CPU高或者ksoftirq进程CPU高：排查异常CPU占用。

CN 连接DN报错, 主要关注后面的detail信息 Already too many client：DN线程数超过max_connections上限； Connection timed out：TCP建连超时，网络不通或者网络质量差； Connection refused：TCP建连被拒绝，防火墙配置或者端口号错误； timeout expired：连接已经建立，但连接信息同步时对端响应超时。 数据收发过程中报错 cancel/terminate日志：外部信号中止查询； reset by peer/broken pipe：连接对端线程主动关闭连接； Stream closed by remote：对端关闭连接或发生重启，需查看对端日志； Peer address changed：对端DN存在主备切换。 DN 间通信性能差 pv_total_memory_detail中通信内存过大：Libcomm通信库降级运行； gsar监控有严重丢包重传：网络质量差，丢包过多导致连接断开； top查看CPU高或者ksoftirq进程CPU高：排查异常CPU占用。

对于256节点的集群来说，并发场景导致CN和DN之间存在大量连接，每个连接占用一个端口，则CN的端口号很容易受限。为解决此问题，设计了CN多流，即 CN与DN之间采用逻辑连接。comm_cn_dn_logic_conn参数默认值是off，在集群规模或并发达到一定程度时，需要将其开启为on，避免CN与DN之间由于端口号受限而无法建连。TCP 代理通信库采用 pull 模式进行流量控制，避免消息堵塞。两个DN 分别有一个buffer，当一条通道发送端数据量过大时，很容易造成buffer 填满，阻塞了其他通道的发送。此时，对于每条通道设置一个quota，接收端根据buffer剩余空间的大小发送给发送端一个合理quota值，发送端根据quota大小发送数据。 comm_quota_size 表示每个通道单次不间断发送数据量配额，默认值 1MB。当通道发送数据量达到配额时，发送端等待接收端重新发送配额，进而继续发送数据，从而实现流控功能。其取值为0时，表示不使用quota，在一些大流量等场景中，查询之间可能会有影响。在1GE网卡环境中，受网卡能力限制，应该调小该参数，推荐20KB~40KB。如果环境内存充足，参数comm_usable_memory设置较大，可以适当调大，从而提升性能。

视图展示所有DN的通信库状态。其中字段包括节点名称、节点通信库接收速率，单位为byte/s、节点通信库发送速率，单位为byte/s、节点通信库接收速率，单位为Kbyte/s、节点通信库发送速率，单位为Kbyte/s、cmailbox的buffer大小、libcomm进程通信内存的大小、libpq 进程通信内存的大小、postmaster 线程实时使用率、gs_sender_flow_controller 线程实时使用率、gs_receiver_flow_controller 线程实时使用率、多个gs_receivers_loop线程中最高的实时使用率、当前使用的逻辑连接总数。表示TCP代理通信库支持的最大DN数，最小值为1，最大值为8192。当DN数小于256时，默认值为256；否则，为大于等于DN数的2的N次方。在集群扩容、缩容场景下，要注意此参数的变更。 表示TCP代理通信库支持的最大并发Stream数量，默认值为1024，最 大 为 60000，此参数要保证大于并发数每并发平均Stream算子数（smp的平方），否则会报错Cannot get stream index, maybe comm_max_stream is not enough。此外，在设置此参数时需要考虑占用内存问题，其大小为256byte * comm_max_stream * comm_max_datanode ，可见在内存、comm_max_datanode 和comm_max_stream三者之间需要一个动态的规划。

视图展示所有DN上的通信库接收流状态。其中字段包括节点名称、使用此通信流的线程ID、连接对端节点名称、连接对端节点ID、通信对端DN在本DN内的标识编号、通信流在物理连接中的标识编号、通信流所使用的tpc通信socket、通信流当前的状态、通信流对应的debug_query_id 编号、通信流所执行查询的 plan_node_id 编号、通信流所执行查询send端的smpid编号、通信流所执行查询recv端的smpid编号、通信流接收的数据总量、通信流当前生命周期使用时长、通信流的平均接收速率、通信流当前的通信配额值、通信流当前缓存的数据大小。展示所有DN上的通信库发送流状态。其中字段包括节点名称、使用此通信流的线程ID、连接对端节点名称、连接对端节点ID、通信对端DN在本DN内的标识编号、通信流在物理连接中的标识编号、通信流所使用的tpc通信socket、通信流当前的状态、通信流对应的debug_query_id 编号、通信流所执行查询的 plan_node_id 编号、通信流所执行查询send端的smpid编号、通信流所执行查询recv端的smpid编号、通信流接收的数据总量、通信流当前生命周期使用时长、通信流的平均接收速率、通信流当前的通信配额值和通信流等待quota值产生的额外时间开销。

并发比较高时 producer 线程会一直往队列里push，如果此时对端 cunsumer1 线程正在处理别的数据导致接收 buffer1 满了的话，producer2 和 producer3 无法往网络上填充更多的数据，发送阶段就会阻塞，而此时可能consumer2和consumer3正在空闲状态，等待这个接收数据，但是因为发送端阻塞而接收不到，这种场景会严重影响性能。这个模型我们称之为push模型。因此我们需要通过另外一种流控机制来解决这个问题，我们称之为pull模型。 push模型：发送端不感知接收端状态。一直往无锁队列中push，直到push阻塞； poll 模型：发送端感知接收端状态。发送端一开始不会发送数据，当接收端里的buffer 池内存满足一定条件时，通知对应的发送端，并告知可以接收的数据量，发送端可以按照对端可以接收的数据量进行发送。 通过 poll 模型的实现，在本线程阻塞的情况下，其他的线程不会阻塞，以确保物理连接中数据永远不会阻塞，保证连接的通畅性。该视图中的字段包括节点名称、连接对端节点的节点名称、连接对端IP的对端地址、当前物理连接使用的 Stream 逻辑连接数量、当前物理连接一分钟内探测到的最小时延、当前物理连接一分钟内探测道德平均值和当前物理连接一分钟内探测到的最大时延。