问题现象：重启裸金属实例后，bond0，bond0.xxx前两个网卡ip没有挂上应对措施：登录BMC，root用户手动重启bms-network-config服务service bms-network-config restart加固措施：将service bms-network-config restart加入到自启服务中echo 'service bms-network-config restart'>> /etc/rc.d/rc.local

【直播主题】大数据时代下的数据守护：华为云数仓GaussDB(DWS)备份恢复【直播时间】2024年8月27日 16:30-18:00【直播简介】在大数据时代，数据可靠性对于一个企业非常重要，但是原始数据丢失或由于误操作导致的数据遭到了破坏的事件时有发生。如果没有数据备份，则数据丢失时将无法找回丢失数据，可能造成巨大的经济损失。数据可靠性可以依靠B&R（Backup and Restore）进行保证。如果定期将数据进行备份，当灾难发生时，就可以利用之前的备份数据进行恢复，从而最小化的降低损失，所以数据备份和恢复工作是一项不可忽视的系统工作。 华为云数仓GaussDB(DWS)提供了多种备份恢复方案，本期直播将为您带来GaussDB(DWS)备份恢复能力与实践的全面解读。直播链接：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年9月3日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，被专家评选为优质问题的开发者进行奖励。奖品：定制卫衣活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：定制卫衣更多直播活动直播互动有礼：官网直播间发口令“GaussDB(DWS) ”抽定制鼠标垫、填写问卷抽定制颈枕等好礼。沙箱实验：完成沙箱实验，并在评论区留言体验截图，将有机会赢取GaussDB(DWS)定制礼品。【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年9月7日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。

【版本信息】813.320【问题描述】客户执行select a::json from xxx 语句，报错invalid input syntax for type json； a的数据类型为varchar【处理方法】1. 对于a中不报错的元数据字段（通过where条件过滤）并设置set enable_fast_query_shipping = off 打印执行计划，语句正常执行2. 对于a中转json/jsonb会报错的字段，尝试传其他类型（varchar，bytea等）发现均不报错3. 尝试把a改为json类型，插入原表数据，发现也会报json格式错4. 通过上述排查，已确认客户元数据中存在格式不满足json的数据，于是通过is_json函数对于此部分数据进行筛选：CREATE OR REPLACE FUNCTION is_json(input_text varchar) RETURNS boolean AS $$DECLAREmaybe_json json;BEGINBEGINmaybe_json := input_text;EXCEPTION WHEN others THENRETURN FALSE;END;RETURN TRUE;END;$$ LANGUAGE plpgsql IMMUTABLE;5. 筛选发现客户的200万+条数据中，有409条无法转换成json格式：6.数据格式转成bytea之后，发现有多余的09编码7.验证09编码前的e58f98为变8.测试也可反映相同场景9.通过正确和错误的元数据对比，发现错误元数据文字后有冗余的\t字符，删除后is_json输出为t【问题根因】客户的元数据中有409条不满足json转换，存在异常字符【解决方案】对409条数据进行逐个排查，删除冗余的\t字符；或建议直接确认元数据来源，避免异常字符导入至元数据

华为云开发者日 · 上海站8月30日将盛大开幕，大家对活动有什么期待，可以分享一下

分布式数据库的优势，就是利用多DN的资源进行并行计算，提高吞吐量。但有些SQL在这些方面不够注意，导致执行过程中由于全局性操作仅能在一个DN或CN上执行，造成了性能瓶颈。不能下推即属于这一类型问题。Stream方式的选择https://bbs.huaweicloud.com/forum/thread-0256159430673930031-1-1.htmlpagehack&pg_xlogdump工具使用方法总结https://bbs.huaweicloud.com/forum/thread-02127159430903851031-1-1.htmlNBU部署方式https://bbs.huaweicloud.com/forum/thread-0256159434136944032-1-1.html统计信息未收集https://bbs.huaweicloud.com/forum/thread-02127159436015266033-1-1.html查看DN实例XLOG空间使用状况https://bbs.huaweicloud.com/forum/thread-02127159435502974046-1-1.html查看Catchup进度https://bbs.huaweicloud.com/forum/thread-02127159435404322028-1-1.html查看Failover进度https://bbs.huaweicloud.com/forum/thread-0261159435307957034-1-1.html查看DN实例Redo进度https://bbs.huaweicloud.com/forum/thread-02127159435247373021-1-1.html备机重建和增量重建https://bbs.huaweicloud.com/forum/thread-0256159435199245034-1-1.html数据同步涵盖范围https://bbs.huaweicloud.com/forum/thread-02127159435069367027-1-1.htmlDN高可用架构模型https://bbs.huaweicloud.com/forum/thread-02127159434867934045-1-1.htmlNBU部署调优https://bbs.huaweicloud.com/forum/thread-0267159434585384026-1-1.htmlRoach工具介绍https://bbs.huaweicloud.com/forum/thread-0256159434462566033-1-1.htmlNBU流程概述https://bbs.huaweicloud.com/forum/thread-02127159434278364044-1-1.htmlXBSA相关接口https://bbs.huaweicloud.com/forum/thread-02127159434379453032-1-1.html

分析过程1. 通过explain verbose/explain performance打印语句的执行计划2. 执行计划中会有语句未收集统计信息的告警，并且通常E-rows估算非常小。在打印的执行计划中有Warning提示信息，提示有哪些列在这个执行计划中用到了，但是这些列没有统计信息。在CN的pg_log日志中也有会有类似的Warning信息。同时，E-rows会比实际值小很多。问题根因优化器是基于代价的优化 (Cost-Based Optimization，简称CBO)。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值，以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost)，进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。统计信息是优化器生成执行计划的基础，没有收集统计信息，优化器生成的执行计划会非常差，如果统计信息未收集，会导致多种多样表现形式的性能问题。例如，等值关联走NestLoop，大表broadcast，集群CPU持续增高等等问题。解决详情周期性地运行ANALYZE，或者在对表的大部分内容做了更改之后马上执行analyze。

随着数据库的不断运行，产生的日志文件越来越多，如果因为节点故障或其它原因有可能造成日志文件不断积累而充爆磁盘。为了解此使用信息，最方便的是使用gs_ctl query工具对指定DN实例路径进行状态查询，结果中可以显示该实例的XLOG空间使用信息，截图示例请参见上面其它场景。此外，还提供系统函数 pgxc_stat_xlog_space、pg_stat_xlog_space 对数据库集群或单个实例进行查询，例如使用pgxc_stat_xlog_space可以获取到整个集群的CN、主DN的XLOG空间使用信息。XLOG空间使用信息（Xlog space info）包括：xlog_files：pg_xlog目录下，去除backup、archive_status等子目录，所有识别为xlog文件的数目；xlog_size：pg_xlog目录下，去除backup、archive_status等子目录，所有识别为xlog文件的大小之和，以MB单位显示；other_size：pg_xlog目录下backup、archive_status等子目录文件的大小之和，以MB单位显示。

当备机重新启动的时候，会连接主机做数据页追赶（catchup）。如果需要传输的数据页比较多，或者因为业务造成的锁冲突，catchup 时间就会比较长，备DN长时间不能成为Normal状态。如果期望查看数据页catchup的进度，可以在CN上执行select * from pgxc_get_senders_catchup_time()可进行当前活跃的主备发送线程的追赶信息显示。也可以在相应的主DN上执行select * from pg_get_senders_catchup_time可进行当前活跃的主备发送线程的追赶信息显示。完成后，看到的是刚结束的catchup过程信息。备机Catchup进度相关信息包括：catchup_type："Incremental"或者"Full"。catchup方式为全量还是增量。catchup_bcm_filename：当前主机正在处理的一个BCM文件名称。catchup_bcm_finished：catchup已操作完成的BCM文件数量。catchup_bcm_total：catchup总共需要操作的BCM文件数量。catchup_percent：catchup已经操作完成的百分。catchup_bcm_finished*100 / catchup_bcm_total 的计算值。catchup_remaining_time：依据已完成的进度，预估剩余完成时间。依据catchup_bcm_filename和catchup_bcm_finished的变化，可以看到数据页追赶的推进。依据catchup_percent和catchup_remaining_time，可以推测备DN实例追赶到正常状态的所需时间。

当主机发生故障时，我们需要将备机failover成主机，此时备机需要连接从备同步XLOG和数据页文件。如果需要同步的XLOG比较多，或者遇到某种特殊日志类型，或者数据文件比较多时，对备DN实例进行failover，过程时间就会有些长。备机failover升主过程中，如果期望查看XLOG redo和数据页文件同步的进度。最方便的是使用gs_ctl query工具对指定DN实例路径进行状态查询，结果中可以显示xlog redo的进度和从备数据同步的进度。此外，在DN实例可以接受gsql连接时，也可直接在当前DN上执行pg_data_sync_from_dummy_completion 函数来获取从备数据文件同步的进度信息。 Failover Redo进度相关信息（Xlog replay info），字段含义同Start Redo，区别在于，备DN在处理failover请求连接从备时候获取最新的replay lsn更新了replay_start。Failover数据页文件进度相关信息（Data sync from dummy）包括：start_index：数据页文件同步的起始编号。current_index：数据页文件同步的当前编号。total_index：数据页文件同步的最大编号。sync_percent：数据页文件当前完成的百分比。(current_index - start_index) *100/ (total_index - start_index + 1) 的计算值。依据current_index的变化，可以看到数据页同步的推进。依据sync_percent和failover开始时间，可以推测DN实例failover到正常状态的所需时间。

当DN实例crash发生时，我们可以通过回放XLOG日志中记录的数据变化还原crash前的操作。这个就是所谓的redo/recovery过程。如果需要redo的XLOG比较多，或者遇到某种特殊日志类型，对DN实例进行启动，启动过程时间就会有些长。DN实例启动过程中，如果期望查看XLOG redo的进度。最方便的是使用gs_ctl query工具对指定DN实例路径进行状态查询，结果中可以显示xlog redo的进度。此外，在DN实例可以接受gsql连接时（启动到最小恢复点之前是拒绝连接的），也可直接在当前DN上执行pg_xlog_replay_completion 函数来获取XLOG redo进度信息。启动Redo进度相关信息（Xlog replay info）包括：replay_start：Xlog Redo的起始LSN 。DN实例启动XLOG redo过程时，记录replay_start。replay_current：Xlog Redo的当前replay的LSN。replay_end：DN本地接收到的最大XLOG lsn。replay_percent：Xlog Redo的当前完成的百分比。(replay_current - replay_start)*100 / (replay_end - replay_start)的计算值。依据replay_current的变化，可以看到XLOG redo的推进。依据replay_percent和启动开始时间，可以推测DN实例启动到正常状态的所需时间。

主备倒换当主DN故障时，需要对备DN进行failover，failover后备DN升为主DN来接管业务。所以failover时，备DN需要连接从备DN，向从备DN请求数据，以补齐备DN比主DN缺少的数据。failover的过程是备DN独立完成的，不需要和主DN进行交互。备机重建重建功能主要目的是单点故障修复，备机重建方式按照实现分为全量重建和增量重建，均和主DN进行交互。全量重建是备机清空数据目录，保留配置文件，向主机发送全量重建请求，主机将自己的数据目录除了配置文件外，全部发给备机，重建后启动备机。增量重建是一种以主DN文件为基准，按照文件块对备DN文件进行校验，如果备DN文件的某个文件块校验不一致，则主机将此文件块发给备DN，写入文件对应的文件块中。与全量重建相比较，拷贝的数据量和WAL日志量都更少，代价更小。 从以上这些数据同步过程中，我们发现表现在运维上一个明显的特点是，这些过程有可能会时间花费较长，一旦同步过程中出现异常问题，其内部关键过程信息输出对于问题分析定位十分重要。因此，GaussDB(DWS)提供了丰富的系统函数、视图、工具等可以直观地对同步进度进行跟踪，尤其是为方便定位人员使用，gs_ctl工具已集合了大部分相关系统函数的调用，可做到在任何时间，从未启动、启动、重建到运行时的关键信息显示。

数据同步就是涉及集群中主、备节点以及从备节点之间的日志复制数据的传输、回放，数据页复制数据的传输、追赶，备机重建等过程。GaussDB(DWS)集群高可用实践WAL（Write Ahead Logging）思想，并通过各组件的主备的数据同步、倒换、重建等机制，保证数据库单实例遭遇Crash后，具备故障恢复及自愈的能力，保护数据库中数据的可靠性和完整性，最终实现集群对外业务连续性的过程。这些主要的过程有：1、主备之间的正常流复制每组DN独立承担一个数据分片，因此要求各个DN主与备必须强同步。为保证DN的主备强同步，数据在主DN操作时产生日志，事务提交时将日志同步给备DN。备机对接收到的XLOG进行回放（replay），将日志转为数据。另外，列存和行存批插场景下，备机正常时，新增（变更）数据会发往备机。使用数据页同步相对于日志同步少了磁盘IO，可以提升同步效率，减小RTO。2、备机追赶为了解决单节点故障后集群写事务可用，DN的高可用设计引入从备这个实例。一旦备DN故障，数据将发送给从备，仍然保证了数据写两份的原则，事务照样可以提交。但主机会对BCM文件里面的标记位置状态位。BCM文件中每一bit位（除预留位外）对应数据文件中每一页（8k）状态。当备机重新启动的时候，会连接主机做数据页追赶（catchup）。追赶机制分为全量和增量两种。全量catchup机制，不依赖于从备，主机递归扫描本地默认表空间和自定义表空间下的所有BCM文件，然后查看状态位来确认哪些数据文件需要发送给备机。增量catchup机制依赖于从备，主机通知从备遍历其从备上暂存的数据页，将变更的数据页列表发往主机，主机直接按照从备发来的变更列表，将变更数据发往备机。

要理解或描述数据同步的过程机制，需要首先要了解GaussDB(DWS)的DN高可用架构，理解涉及数据同步的各组件的关系、数据类型、数据流向、设计原理和目的。GaussDB(DWS)的DN高可用架构为主、备、从备架构。即在分布式环境中，完整的集群数据采用分片技术分布在多个DN组上，每组DN承担一个数据分片，包括：一个主DN、一个备DN和一个从备DN。主和备各有一份完整的数据，从备上一般不存储数据，仅在备机故障时做数据的暂存。主、备、从备高可用架构下，主、备及主、从备之间均会建立流复制通道。流复制又分为日志复制和数据页复制。日志复制用于同步主DN由于WAL机制刷到磁盘上的XLOG，同步到备DN进行回放。数据页复制用于同步批量导入的行存数据、或列存CU文件。需要注意的一点是，从备仅用于存放XLOG和数据，回放（replay）仅发生在备DN上。

NBU侵入式部署调优Maximum jobs per client：此值设定每个NBU client发送的并行处理任务数，通常Roach与并行参数相对性，一般设置为DN数+CN数为最佳。NBU非侵入式部署调优Maximum jobs per client：此值设定每个NBU client发送的并行处理任务数，通常Roach与并行参数相对性，一般设置为：(DN数+CN数)*（Roach client 服务的Roach agent）个数为最佳。超时设置：超时属性适用于选定的Master server、Media Server以及NBU client。Client connect timeout：此选项指定服务器连接客户端时等待的秒数。默认值为300s。一般Roach备份业务中，建议此值设置为3600s或者更高。此选项适用于NBU Master Server、NBU Media Server、NBU Client。Client read timeout：此选项指定用于客户端读取超时的秒数。此选项适用于NBU Master Server、NBU Media Server。默认值为300s，如果服务器在客户端在此超时时间内没有从客户端得到响应，则备份/恢复任务失败，报错误码13。特别是针对于NBU Job复用场景，文件间隔传输时间超过此值，则备份/恢复任务失败。建议此值设置为3600s或者更高。Media server connect timeout：此选项用于指定Master Server连接Media Server的等待超时描述，默认值为300s。建议此值设置为3600s。此选项适用于NBU Master Server、NBU Media Server。

Roach工具目前支持两种NBU部署结构，分别为NBU侵入式部署与NBU非侵入式部署，两种部署方式的参数调优分别如下：1、通用参数调优Maximum concurrent jobs此值指定了对应存储单元上最大作业数量，取值范围为1-256。例如准备将三个备份作业发送到存储单元，并将“最大并发作业数”设置为两个。前两个作业开始，而第三个作业等待。Maximum vault jobs：此属性指定在master server上允许活动的最大活跃job数量。如果达到了允许活动的job限制，则将后续的kob排队，并且它们状态在“活动监视器”中显示为“已排队”。此属性设置范围为1~200， 当备份过程并发job数大大超过200，则master server会出现瓶颈，造成任务排队耗时。此时应考虑部署多Master Server模式。设置NET_BUFFER_SZ ：在应用Netbackup备份数据到带库时，有一个NET_BUFFER_SZ参数，决定media server与client之间数据传输的缓冲池大小，该参数值默认为32032 bytes，以文件形式保存于%Install_Path/netbackup/目录下。通常默认值都较小，如果希望修改该参数值，则直接修改%Install_Path/netbackup/NET_BUFFER_SZ即可。设置一个足够大的NET_BUFFER_SZ某些情况下能够有效提高备份的速度，推荐在server/client端都设置该参数。