8月16日，以“数智赋能 共筑未来”为主题的第14届中国数据库技术大会（DTCC 2023）在北京举行，在GaussDB“五高两易”核心技术，给世界一个更优选择的专场，华为云数据库生态工具研发总监窦德明分享了GaussDB数据库的迁移创新实践。以下是演讲实录：各位同仁，我是华为云数据库生态工具研发总监窦德明，我分享的是GaussDB数据库迁移的创新实践。易迁移能力是企业数据库替换选型的关键考量数据库的选型除了要看数据库本身的能力外，能否很平滑地从其他数据库迁移到GaussDB，也是很多企业考量的关键因素。而数据库能否平滑迁移有两个非常核心的要素，一个是数据库本身，比如能否很好地兼容主流数据库的语法，让应用少改或者不改；另外一个是在数据库外围能否提供一些好用、易用的迁移工具，把应用中内嵌的SQL、数据库中的对象以及全量和增量数据，在业务近乎零停机的情况下从其他数据库平滑地迁移过来。这两点是企业做数据库选型时考量的两个迁移关键要素。结构（UGO）+ 数据（DRS）一站式迁移解决方案在2021年的DTCC大会上，我们发布了华为云结构+数据一站式迁移解决方案，其中有两个核心工具。一个工具是UGO，主要做结构和应用的语法兼容性评估和转换，比如将数据库上层应用中内嵌的SQL捕获出来进行评估，对数据库内部对象的DDL进行评估，并输出一个报告，清晰地展示哪些是数据库本身兼容的、哪些是通过UGO转换可以兼容的、哪些不能转换需要人工介入进行改造等。另外一个工具是DRS，大家都知道，异构数据库替换过程中的数据迁移问题非常非常多，DRS要解决的就是怎么在业务近乎不停机的情况下快速把客户的存量数据和增量数据迁移过来，并保证数据在任何情况下不丢、不错、不乱，同时提供灵活、多样的数据比对和修复能力。UGO+DRS一体化解决方案在实际项目中得到验证UGO+DRS一站式迁移解决方案近两年在很多项目中都得到了验证和应用，这里举几个实际的例子。第一个是我们公司自己内部的MetaERP项目，使用UGO自动转换了近7亿行的O数据库SQL脚本，转换成功率接近100%，同时GaussDB实现了并行逻辑解码，性能高达近300MB/秒，可以让DRS轻松应对MetaERP在月结、季结和年结时10~20倍的流量洪峰，保证数据同步<5s的低时延。第二个是某银行的数据库替换，这个项目迁移复杂度比较高，面临应用多、数据库对象多、存储过程和package深度依赖等困难，截至目前通过我们的一站式迁移解决方案，完成了近1.3亿行SQL脚本（包含近8000万存储过程）的UGO自动转换，转换成功率超过96%，采用DRS迁移了近300套左右的O数据库实例，实现了O数据库与GaussDB数据库的长时间并机稳定运行，正反向低时延数据同步。项目实施过程中遇到新的困难与挑战在大量的项目实施过程中，我们UGO+DRS一站式迁移解决方案也遇到了一些新的困难和挑战，这些挑战相信大家也都会遇到，在此给大家做个分享。挑战1：在做异构数据库替换时，如何快速识别异构数据库语法不兼容点，识别数据相同的情况下相同SQL在不同数据库中执行的性能差异，以及低版本向高版本升级时是否会存在不兼容或性能劣化，再有就是如何模拟业务流量洪峰时的数据库行为表现。挑战2：当前很多企业的开发人员和DBA对GaussDB熟悉程度还不高，SQL编写水平参差不齐，而且在做应用开发时缺乏统一的SQL编程规范和有效的SQL审核机制，很多烂SQL都流入了生产环境，进而引发大量的应用性能问题，影响生产业务和客户体验。挑战3：很多数据库当前的字符集在标准字符集的基础上做了很多扩展或者定制，导致数据迁移时相同字符集的不兼容，或者就没有对等的字符集，更有甚者，历史数据里已经存在了各种各样的乱码数据，这些特殊场景都会影响迁移的平滑性。当然，困难和挑战还有很多，但这三个是会阻塞或拖慢数据库迁移进程的，那么针对这三个挑战，我们都做了哪些探索和创新呢？再给大家分享一下。应对挑战1：孵化数据库流量录制与回放能力流量录制与回放的概念相信大家都不陌生，在数据库领域，有些数据库厂商也提供了相应的工具，GaussDB面临的业务场景比较多，所以需要的技术也因场景而异。如果源数据库是公有云服务，而且提供了全量SQL，那么直接获取全量SQL并进行回放即可；如果源数据库开启了审计日志，也可以直接下载并解析审计日志，当然开启审计日志会对数据库的性能有一定的影响；如果源端是自建数据库，而且未开启审计日志，那就需要部署一个agent，通过捕获网络数据包，结合数据库本身的通信协议来解析出应用下发的所有SQL。基本上这三种方案可以涵盖所有的场景，这里面还要注意几个点，首先是要研究透不同数据库的通信协议，其次是实现异构数据库替换场景下的SQL自动转换，另外是要具备SQL回放的流量控制能力，能加速或者放慢等，当然在解析、回放等出现异常的情况下，要做好记录。接下来就是在源数据库的镜像库和GaussDB数据库同时进行流量回放，而且保证镜像库和目标数据库的数据完全一致，回放的SQL也完全一样，最终输出一个分析报告，比对每一条SQL的执行耗时、资源消耗、甚至是执行结果，很容易看出来哪些SQL的性能GaussDB比源数据库好、哪些出现了劣化、哪些是基本持平的。我们正在和某银行进行数据库流量录制与回放的联合创新，从实际应用效果来看，通过agent方式捕获流量包，SQL抓取成功率可以做到97%以上，解析成功率和回放成功率可以达到95%，在此过程中，还可以识别到语法不兼容、语义不兼容的异常情况。应对挑战2：孵化GaussDB数据库SQL审核能力SQL审核大家更为熟悉，很多大的企业都会进行探索和实践，但对于GaussDB来说，由于是纯自主创新的分布式数据库，很多企业的开发人员和DBA还不熟悉GaussDB的SQL语法，也没有制定较为完善的SQL编程规范，很多第三方SQL审核工具也没有针对GaussDB的审核能力，这种情况下，我们结合UGO成熟的SQL解析器，以及多个项目中的SQL调优实践，孵化出了GaussDB数据库的SQL审核能力。我们SQL审核的输入可以有多种类型，可以是代码仓，也可以是一个SQL文件，还可以是通过流量录制获取的动态SQL等等，可以审核直接获取到的原生SQL，也可以审核通过UGO转换后的SQL。截至目前，我们已经沉淀了81条审核规则，并在公司内部的两个项目以及外部的多个银行进行了应用，效果超出预期。应对挑战3：孵化字符集兼容性分析评估能力针对数据迁移，大家最担心的莫过于正式割接时出现各种各样的问题导致割接失败，除了迁移工具本身的功能之外，最常见的可能就是字符集不兼容、数据乱码、生僻字等等。举个例子，O数据库对GBK字符集做了扩充，可以存储UTF-8字符，而GaussDB数据库的GBK字符集非常规范，从O数据库向GaussDB迁移数据时，这些UTF-8字符根本无法写入，迁移必然失败。更有甚者，很多客户的海量历史数据中有大量的乱码数据，无法确定这些数据是什么时候写入的，哪些应用写入的，或者后续会不会再用到，但客户要求必须迁移过来。那么，面对这些挑战，我们尝试通过孵化字符集兼容性分析评估工具来提前识别。这个工具的原理很简单，首先是建立一个可以分析的字符集基线，比如GB系、Unicode系列等，其次是获取源数据库的元数据，包括字符集、索引信息、表结构信息（列类型、列长度）等，然后基于源数据库和目标数据库的字符集做好映射，最后再对数据库进行数据扫描和分析，输出多维度的分析评估报告。目前这个工具正在和某银行进行联创，从前期的试用效果来看，确实能发现很多问题，比如ZHS16GBK和AL32UTF8两种字符集混编、直接写入二进制格式导致数据乱码、ZHS16GBK字符集使用了大量生僻字等。对UGO+DRS一站式迁移方案的演进思考以上是我们在使用UGO+DRS一站式迁移解决方案过程中遇到的三个大的挑战，以及应对这三个挑战做的一些创新实践。现在GaussDB的迁移场景越来越多，也越来越复杂，所以我们会不断地进行探索和创新，让我们的方案更完善，迁移过程更平滑，比如流量回放、SQL审核、字符集兼容性评估会支持更多的数据库，推出非常详细和全面的应用、结构、数据迁移可行性分析报告，实现SQL捕获、转换、审核、优化全流程一体化管理等等，也希望能和客户、伙伴以及各位同行进行合作。以上就是我分享的GaussDB数据库在迁移方面的一些创新实践，谢谢大家。

例如插入语句INSERT INTO your_table (column1, column2) VALUES ('', 'other_value');实际库的结果是 null,'other_value'想要的结果是'','other_value'有没有配置触发器,不改变插入的结果

近日，在第14届中国数据库技术大会（DTCC2023）的GaussDB“五高两易”核心技术，给世界一个更优选择专场，华为数据库技术专家李士福详细解读了GaussDB性能调优的相关技术和应用实践。以下为演讲实录：大家下午好！我是来自华为高斯实验室的李士福，很荣幸和大家分享GaussDB性能调优的实践。我今天分享的内容主要包括三个部分，分别是性能调优的整体介绍，性能调优的关键技术，性能调优的应用实践。一、GaussDB性能调优简介我们知道数据库作为系统软件，在整个计算机体系中起到关键的承上启下作用。我们可以看到应用程序通过北向接口与数据库进行交互，而数据库通过南向接口与操作系统和硬件进行交互。对于数据库系统的性能影响是多方面的，不管是硬件规格、操作系统配置、数据库系统的设计、应用和客户端的连接方式，都会对业务最终的性能表现产生很大的影响，所以数据库的性能表现本质上是整体计算机系统软硬件协调的结果。数据库性能优化充满复杂性和挑战性，既有主观的成分，也有复杂的一面。性能问题的主观性，举例来说，某个查询消耗是1s，它的性能是好还是坏，是否脱离业务目标很难讲清楚。所以描述性能问题时要目标清晰、描述具体、结果可度量。例如一个问题出现后，需要给出硬件配置、参数信息、部署形态、业务场景、当前结果、期望目标。另一个面临的性能问题是复杂性，通过一个问题表象，很难一眼确定是某一个模块引起的，需要分析出一个明确的方向，进一步观察作业在不同模块间数据流动，用全局视角来分析问题；如果性能问题不是单点的问题，我们需要从中找到引起问题的主要矛盾，然后先解决掉大头，看看是否满足业务诉求。在遇到数据库性能相关问题时，经常会出现一些行业术语。比如：IOPS通常指的数据库系统数据盘每秒读写IO的次数，反应了磁盘IO能力的读写能力；吞吐量，往往指的是数据库每秒处理事务数TPS或者查询数QPS，反应整体的负载状况；响应时间，指的是数据库中一条查询从发起到结果返回的时间开销，用来识别慢SQL；饱和度，指大并发场景下属于工作队列的任务数，反应当前系统作业被积压的情况，忙闲程度。GaussDB数据库的逻辑架构分析GaussDB性能问题前，先简单介绍一下逻辑架构。GaussDB分布式数据库包括下面的一些组件：OM运维管理组件，负责日常的运维和管理操作，例如安装、升级、节点替换等；CM集群管理组件，负责集群、节点和实例级别启停，集群状态查询、选主、主备切换等；GTM全局事物管理器，负责生产和维护全局事务ID、快照、sequence等全局唯一信息，确保全局事务一致性；CN协调节点，负责接收应用的访问请求，并将结果返回给客户端，在CN中完成SQL解析和优化后，将计划下发到各DN执行；DN数据节点，负责存储业务数据，执行数据查询业务，并返回执行结果；ETCD一致性组件，存储集群的拓扑状态和信息，主备状态信息，全局事务ID和sequence依赖ETCD，CMS自身仲裁和CMS对数据库组件的仲裁依赖ETCD。后续ETCD将改为自研组件DCC分布式配置中心来存储集群配置信息。这里面影响业务查询的核心组件是GTM、CN和DN组件。GaussDB的查询处理流程了解GaussDB架构后，我们简单梳理一下查询处理流程，拆解到每个模块，我们展开一下每个模块的功能和性能关注点。查询解析模块，将SQL文本翻译为解析树，这里面的性能主要因素是词法、语法、语义分析效率，用到技术包括模板查询免解析，PBE模式绑定变量方式执行。查询优化将进行逻辑优化和物理优化，最终生成物理计划，性能核心点是高效计划生成，包括计划缓存、重写规则、基数估计、代价估计准确率等。在查询执行阶段，执行查询计划，并将结果返回；这里面性能核心点包括SMP并行执行、分布式执行、基于编译技术的算子执行、表达式计算等。在查询时进行数据读取，性能涉及存储引擎的多个模块，包括高效的存储数据、并发控制、事务能力等。最终所有各阶段的执行消耗综合，决定了查询端到端性能。二、数据库性能调优关键技术下面介绍一下GaussDB在性能优化方面的几个关键技术。计划缓存计划缓存技术，一般在OLTP的业务负载中，因为涉及的数据量较少，通过索引加速数据访问路径后，查询解析、重写、优化占比就很高。对于模板行之的语句，可以将模板语句的计划缓存起来，那么同模板不同参数语句执行时，直接使用缓存计划，大大提升并发吞吐量。我们可以想一下，缓存计划是针对一个session，还是针对整个系统的，所以引申出两个概念，local plan cache和global plan cache。如果只在session上缓存已执行计划，那可能会导致每个session上执行计划都很多，占用内存资源高，GPC可以很好解决内存占用问题，但维护代价较大，管理成本高。还有一个问题是缓存计划可能针对某一类SQL，如果参数变化后，执行计划不优怎么办。GaussDB实现了计划自适应选择的能力，可以自动为不同参数配置最佳的缓存计划。智能基数估计智能基数估计主要解决两个问题：一是什么时候创建多列统计信息？二是创建什么类型的统计模型？当前常见的方案是采用MCV（一种软件架构模式）和直方图的统计模型来实现。但这两个方案在单列场景估计的比较准确，在多列场景中仅支持单表，而且误差较大，无法应用。GaussDB创新性地设计出基于库内轻量级贝叶斯网络算子模型来实现多列场景下的基数估计。基于DB4AI的轻量级算子，在数据库内完成训练和推理，对内核几乎无影响；在自动analyze收集统计信息时，自动创建贝叶斯网络模型；优化器在进行多列基数估计时，调用训练好的模型，给出准确率的数值。分布式查询执行GaussDB分布式数据库在查询执行过程中，采用多种技术提升查询执行的性能。其中分布式执行框架用于实现分布式集群的多节点并行处理能力，提升集群整体的性能。在复杂语句查询时，会将重执行算子下推到DN节点执行，例如AGG算子等。在下推算子执行时，会考虑数据本地性，尽可能在本地计算，减少数据在网络中的传输开销，从而同时整体的查询性能。在单节点内，通过SMP并行技术，重分利用多核cpu的并行加速，结合内存管控，提升单节点的性能。GTM LiteGTM负责全局事务的一致性，传统的GTM组件需要维护每一个活跃事务信息，作业执行时，需要从GTM获取快照时，拿到的是当前的活跃事务链表，如果量特别大，将对网络并发带来压力；GaussDB实现GTM lite能力，通过CSN号代替事务链表，获取的快照仅为CSN号，在事务提交时，也只需要原子加CSN号。在可见性判断时，基于CSN号进行，如果事物结束的CSN比快照中csn值小，那么元组可见，否则元组不可见。日志并行流水线数据库日志系统非常关键，是数据持久化的关键保证。传统数据库一般采用串行刷日志的设计，因为日志有顺序依赖关系。GaussDB采用log writer日志写盘线程并行写机制，充分发挥多通道IO的能力。主要机制是将一把大锁，拆分为多个并行的小锁。部分worker线程的事务日志写到一个事务日志共享缓冲区，每个事务结束前保证对应的事务日志LSN已经刷盘，有全局LSN原子加保证顺序。NUMA AwareGaussDB在多核ARM架构下，通过NUMA Aware技术解决跨NUMA内存访问延迟问题。做几个主要工作包括全局数据结构NUMA化改造，降低数据换成访问延迟，关键数据结构包括CLOG、Wal insertlock、proc array等；将内核工作线程与numa node进行绑定，避免跨numa调度；利用原子操作指令集LSE，提升计算性能。三、数据库性能调优应用实践最后介绍一下性能调优的应用实践。我们先看看性能调优的思路，遇到性能问题，先确定性能调优的范围，观察是否某个系统资源达到瓶颈，或者是否存在SQL阻塞或慢SQL，通过分析，如果是系统资源类问题，我们通过系统调优来进行诊断和优化，如果是SQL层面问题，我们通过SQL调优进行诊断和优化，最终看优化后效果是否满足业务需求，如果一次优化不能达成预期，则需要多轮迭代，最终达成目标。我们看一下数据库系统整体性能问题的定位思路，先判断是数据库层面问题还是其他层面问题，其他层面问题例如是否是节点上其他进程引起的数据库性能下降，或者操作系统参数配置不当引起的。若是数据库层面问题，需要对数据库占用的系统资源信息、数据库内核资源、主备状况等进行综合分析，最后确认问题根因。在分析单条SQL语句性能时，通过使用视图statement_history或者statement，查询语句每个阶段执行时间消耗，确定语句执行的性能瓶颈。statement_history记录了执行时间超过阈值(log_min_duration_statement，默认3 s)的详细SQL信息，包含计划生成时间、执行时间、锁等待时间等信息；statement记录了SQL按照unique_sql_id归一化的执行信息，包括执行次数、总的执行时间、访问数据量、内存使用等信息。然后通过等待事件视图，查询阻塞会话和对象；最后通过执行计划，获取更细粒度的算子执行情况，如是否走索引、走正确的索引、分布式执行算子stream是否涉及广播等。讲到GaussDB全量SQL和慢SQL，我们看一下他们包含哪些内容。GaussDB的多维度指标监控采集粒度不同，对系统性能的影响也不同，可分为三个级别进行采集。L0级别基本不影响业务执行，采集信息包括实例信息、语句信息、元组、缓存、执行时间等；L1级别对系统稍微有些影响，但可接受，这也是业务上线默认推荐的配置，主要包括执行计划信息和锁的统计次数；开启L2会对系统带来很大影响，通常用在问题定位，包括细粒度锁信息和等待时间等。下面介绍两个案例。第一个是应用升级后引起了性能剧烈波动，我们先观察一下实例整体执行的时间，看看在哪一步消耗的比重最高，然后通过归一化视图观察单个SQL，看每一步的执行消耗，确认是在网络发送部分引起的，我们把应用侧进行替换，应用程序更新后这个问题就解决了。第二个是集群整体性能劣化。我们先观察CN上线程等待状态，发现有些节点等待次数超高；我们在异常节点上分析等待事件，发现wal sync等待的时间较高；对比正常节点，确认该节点上存在wal sync的问题。最后分析出主备间日志LSN分片差异较大，一直在进行回放，影响系统整体性能。最后介绍一下GaussDB两个自调优利器，分别是索引推荐和分布键推荐，主要用于提供高效推荐。比如索引推荐，可以帮助用户根据业务负载自动推荐合适的索引组合，识别冗余索引和无效索引。在推荐索引时，同时输出正向提升SQL信息和负向提升SQL信息，帮助用户来决策是否使用推荐的索引。我的分享就到这里，谢谢大家。

8月31日，华为云GaussDB数据库城市沙龙·厦门站圈层活动顺利举行，活动围绕数据库开展政企行业数字化转型解决方案与实践交流。华为厦门政企解决方案部部长罗立强、华为云数据库服务产品部副总经理庄乾锋、华为政企行业数据库架构师，以及明源云和先进数通等合作伙伴，在现场与参会嘉宾共同探讨福建政企数字化创新，推动国内数据库在政企行业的发展。华为厦门政企解决方案部部长罗立强在致辞中表示：“数字经济发展如火如荼，政企行业也借这股东风乘云直上。华为致力于构建数字经济底座，携手广大合作伙伴，共同打造先进的产品和行业解决方案，使能千行百业高质量发展。”政企数字化转型，技术是关键华为云数据库服务产品部副总经理庄乾锋表示，随着国内数据库的蓬勃发展，以及外部环境不确定性的加剧，自主创新已成为国内行业发展必然之路。华为云GaussDB数据库自成立起便肩负两大使命：一是解决华为集团业务连续性，二是保障国家金融、关键信息基础设施行业的安全，并在实际业务场景中锤炼出了系列核心能力。华为云GaussDB通过全场景部署，做大单点能力，做强分布式能力，为行业提供一站式数据服务。单点能力方面，GaussDB对标国际领先产品，减少非必要分布式改造，单节点支持16TB数据量，性能远超开源MySQL。分布式能力方面，GaussDB优化跨节点查询，复杂SQL 性能倍增；支持多租户管理，极大提升了资源利用率；支持全场景数据压缩，快速提升存储使用效率；提供“GaussDB+UGO+DRS”一站式迁移解决方案，让迁移工作变得更轻松可控；是国内首个通过国际CC EAL4+安全顶级认证的数据库，全方位守护数据安全；提供全流程、全链路运维方案，面向应用开发及运维打造数据库自动驾驶体验。深入行业实践，GaussDB百炼成钢华为政企行业数据库架构师李彦伟表示，GaussDB立足金融政企行业场景，深入业务实践，完全经受住了企业严苛场景的锤炼。在工商银行核心交易系统分布式改造过程中，GaussDB提供了跨Region双集群数据0丢失方案，满足大型业务系统对存储容量和可用性的要求；异构语法兼容及自动化迁移成功率高，节省迁移改造工作量90%以上；全力支撑工行全球信贷系统7*24小时连续性服务。在华为集团MetaERP替换中，GaussDB通过Ustore存储引擎、纯软全密态、异地跨云容灾等能力，35小时完成3200亿行数据完全在线迁移，9大核心模块（库存服务、采购履行中心、库存分析等）系统稳定运行无问题，端到端业务处理效率提升10倍。依托GaussDB云原生数据库，明源云打造不动产数字新引擎明源云厦门公司解决方案架构师曾飞飞表示，明源云以“PaaS平台+SaaS+生态”的战略布局，累计为超过7000家不动产开发、运营企业提供了数字化产品与服务，助力1000多家国企实现深化改革和数字化转型。明源云携手华为云，从数据合作到Paas平台，从完整方案到AIGC，一步步构建引擎，加速国资国企智赢时代。在SaaS应用阶段一，明源云基于GaussDB云原生数据库展开数据合作，明源云链数字工程业务依托GaussDB提供的存算分离架构、Proxy读写分离、会话级别一致性等能力，以数据库为抓手，盘活数据资产，让数据成为血液流动。PaaS层面，明源云天际建模平台基于GaussDB云原生数据库，为企业提供快速开发平台，提升了企业开发效率。此外，明源云携手华为云联合构建了不动产投建营一体化平台，围绕投资、建设、运营三个方向为国企提供技术创新力，保障科学投资、智能建设、资产盘活，助力国企走向世界一流企业。携手先进数通，联合打造更优服务北京先进数通信息技术股份公司产品总监郭钰表示，作为中国金融行业数字化转型引领者，先进数通致力于为客户提供可信赖的数字化转型服务，并携手华为打造了包含GaussDB产品专业服务在内的系列专业产品服务，更好地提升了产品和服务的质量。随着国内数据库产业需求变化和技术演进，金融政企客户更倾向于选择自主创新、持续领先、低迁移成本、持续性服务、生态开放的产品。先进数通与华为分别基于Starring 和GaussDB数据库，共同构建了金融智能支付平台，让支付变得更敏捷高效。还打造了全生命周期服务与保障，包括前期咨询、中期实施、后期保障，提供了GaussDB基础运维服务，核心系统数据迁移服务，技术专家支持服务，让原本不确定的迁移担忧变为确定性的计划。共研国内数据库创新之路在“国产数据库深度使用”专题研讨环节，华为云高级数据库解决方案架构师马海旭与参会嘉宾围绕国产数据库资质、能力、迁移、管理、生态、人才等维度进行了深度讨论，积极为国产数据库创新发展建言献策，为金融客户数字化转型提供了更多思路。比如迁移方面，马海旭表示，迁移是一项系统工程，需要完善的方法论，高效的工具和成熟的产品。华为云数据库提供“GaussDB+UGO+DRS”一站式迁移上云解决方案，让客户迁移无忧。其中，UGO负责对源库进行风险和工作量评估，自动转换异构数据库语法，目前已经做到了95%的自动化；DRS负责全量和增量数据的实时在线迁移和同步，通过数据一致性比对确保数据零丢失，模拟业务流量进行仿真验证，让客户迁移更放心。国内数据库产业发展欣欣向荣，千行百业数字化转型正当时。华为云GaussDB沉淀了华为在数据库领域20多年的战略投入成果，具备高可用、高安全、高性能、高弹性、高智能、易部署、易迁移“五高两易”的核心技术竞争力，坚持做企业核心业务云化的智能数据底座，与众多合作伙伴构建数据库生态圈，共同助力政企行业数字化转型，实现高质量发展。

总所周知，小批量插入列存表可能会引起小cu问题，导致表空间膨胀和性能劣化。而批量插入的过程中，如果引入不下推的函数，导致语句不下推，同样也会引起小cu问题。在此，做了如下实验验证：-- 准备数据create table test_source(id int, a int);create table test_column(id int, a int, t timestamp) with (orientation = column, colversion=2.0);insert into test_source select GENERATE_SERIES(1, 1000), GENERATE_SERIES(1, 1000);-- 创建不下推函数-- now()函数可以下推create function test_function_01() return timestamp asbeginreturn now();end;/-- 对比下推与不下推的插入语句的执行计划和小cu状况explain performance insert into test_column select id, a, now() from test_source;truncate test_column;explain performance insert into test_column select id, a, test_function_01() from test_source;小cu排查技巧可以参考下列帖子【总结】列存表查看CU信息_数仓GaussDB(DWS)_大数据_华为云论坛 (huaweicloud.com)实验结果为test_function_01()的语句使目标表出现了严重的小cu现象，而now()语句没出现小cu现象。对比执行计划，在不下推语句的执行计划中发现如下记录： Targetlist Information (identified by plan id) ----------------------------------------------------------------------------------- 1 --Insert on public.test_column Node/s: All datanodes Remote query: INSERT INTO public.test_column (id, a, t) VALUES ($1, $2, $3) 2 --Data Node Scan on test_source "_REMOTE_TABLE_QUERY_" Output: test_source.id, test_source.a, test_function_01() Node/s: All datanodes Remote query: SELECT id, a FROM ONLY public.test_source WHERE true当语句不下推时，执行计划会先让dn收集除不下推函数以外的数据在cn汇总，再以insert into xxx (xx, xx, xx) values ($1, $2, $3)的模式执行。故而会产生小cu现象。

目前国家对去IOE这块的政策，有谁有了解么？谁能给详细讲讲。

近日，在第14届中国数据库技术大会（DTCC 2023）的GaussDB“五高两易”核心技术，给世界一个更优选择专场，华为云数据库技术专家徐宜良分享了《GaussDB高可用之应用无损透明》主题演讲，介绍了华为云GaussDB高可用方面的最新成果。以下为演讲实录：大家下午好！下面由我来为大家介绍GaussDB高可用之应用无损透明特性。一、GaussDB应用无损透明特性简介我们知道用户在使用数据库在线业务系统时，如果数据库服务端发生了维护操作，比如说重启或者主备切换，或者发生故障时，应用程序会感应到数据库之间的连接发生中断，一些执行的事务会被自动回滚掉。当数据服务恢复之后，应用程序需要重建连接，，这样对业务来说不仅增加了业务系统的开发复杂性，也增加业务运行风险。我们知道数据库发生异常时，我们无法判断正在执行的事务是否提交完成。为了解决连接中断和事务自动回滚的问题，华为云GaussDB数据库提供了应用无损透明的高可用能力，通过这个能力我们实现了连接保持和事务断点继续（从事务中断的地方继续执行）的功能。GaussDB应用无损透明支持在数据库内部自动判断事务边界，缓存当前事务执行的会话信息和数据信息，这些信息包括会话锁、用户变量等内容。在数据库恢复时，可以根据这些缓存的会话信息和事务信息，以及服务端的日志一起自动构建恢复出一个一致性的快照点，我们可以通过这个一致性快照点恢复出数据库发生主备切换那一刻所有的应用会话，恢复主备切换那一刻未提交的事务状态，当会话和事务状态都被恢复之后，我们可以从事务的一致性点上继续往下执行事务。从业务视角来看，如果使用应用无损透明功能，整个数据库在发生主备切换期间，应用程序只是感知到事务执行稍微变慢了，不会感知到事务执行中断，也不需要进行重建连接，更不需要进行事务的重试，简化了业务程序的开发复杂性，降低了风险。二、GaussDB应用无损透明的架构我们看一下GaussDB数据库的应用无损透明架构。刚才提到两个特性，一个是连接保持，一个是事务的断点继续，针对连接保持，业界常用的解决方案是，在应用程序和数据库之间部署一个中间件，中间件对数据库和应用程序的连接起到转发作用，当数据库服务端发生主备切换，断开了数据库和中间件之间的连接，应用程序和中间件之间的连接没有断，从表现上看好像解决了连接保持的功能，但我们知道中间件和数据库之间的连接还是发生了中断，连接断了之后会话级参数就丢失了。数据库进行主备切换，在备库升级为主库的时候，所有未提交的事务自动回滚掉了。中间件是独立的，它跟数据库没有任何关系，解决不了事务断点继续的问题，而且中间件不仅在调用链上多了一环，增加了高可用的复杂性和风险，还需要额外的部署、增加了资源消耗。GaussDB数据库没有使用中间件方式，而是直接把能力构建在驱动层。当数据库服务端主备切换或者发生故障时，驱动层不会把中断信息上报到应用程序，而是在自己内部进行连接保持，保持的时候缓存了一些会话数据和事务数据。当数据库服务端恢复之后，驱动会自动建立一个新的会话连接，利用缓存的会话数据，恢复原来连接上会话级的参数。会话级参数恢复之后，根据缓存的事务信息继续恢复原来未提交的事务状态，这样会话和事务状态都恢复之后，事务可以从它主备切换时的一致性快照点继续执行。刚才提到主库宕机备库升主之后，一般数据库会把未提交的事务回滚掉，针对这种未提交事务的回滚问题，GaussDB在启动应用无损透明功能之后，未提交的事务不能自动回滚，需要保持未提交事务的状态，等待新建的连接过来之后进行事务的恢复和桥接事务。这个地方我们引用了逻辑事务ID的功能，通过逻辑事务ID和真实的事务ID匹配，去判断事务的状态有效性。如果事务状态是有效的，就会把事务信息绑定到连接上，实现了数据库备库升主库之后未提交事务状态的恢复。当数据库发生主备切换的时候，连接发生中断，应用程序也不知道数据库发生了什么，也不知道数据库什么时候恢复，一般的策略会采用定时的重试，不停地去连接，查看数据库是否正常这种定时尝试机制存在两个问题：一个是，数据库服务正在恢复期间，不停的尝试会不断的报错，无效且多余的操作；二是，定时检测机制存在延时问题，当数据库服务恢复后，应用无法实时的感知服务恢复了。GaussDB 提供了一种实时消息通知服务（简称GNS），当数据库服务端状态发生任何变化的时候，可以及时的发送消息事件通知给应用程序，应用程序收到之后可以进行相应的动作。GaussDB消息通知服务是一种实时的主动推送的方式，时延更低，消耗资源更少。三、GaussDB应用无损透明的使用方式说到应用无损透明，其使用方式非常简单，只需要在应用程序向数据库建立连接时打开功能开关即可。例如以JDBC驱动为例，当应用程序想使用应用无损透明功能时，只需要在JDBC的URL中配置GaussDB消息通知服务（简称GNS）的IP地址和端口即可。这时会有一个情况，一个数据库集群有很多应用程序客户端，有的应用客户端想用应用无损透明功能，有的应用程序不用，打开或关闭应用无损透明功能这两种情况同时存在，那么当数据库发生主备切换时，使用应用无损透明功能的应用程序客户端，就会具备连接保持和事务断点继续的能力，这个时候的数据库主备切换操作对业务来说是无感知的。没有配置使用应用无损透明功能的应用程序客户端，当数据库发生主备切换或者异常时，可以立即感知到连接中断，数据库正在执行的事务会立即回滚掉。我们看到GNS是对等多活的，当客户端很多时，可以连接到不同的GNS，相当于负载均衡的功能，而不是像主备方式那样，把所有的资源压在一台物理机上。四、GaussDB应用无损透明的使用场景刚才介绍了一下架构原理和使用方法，下面介绍GaussDB数据库的应用无损透明使用场景，主要包括计划内主备切换、计划外主备切换、容灾切换等三个方面。计划内主备切换计划内主备切换一般都是数据库在进行例行的维护和升级中用到的，由运维管理员主动发起。在做计划内主备切换时，GaussDB会自动判断和等待达到一个安全的事务边界后，在驱动层缓存刚才说的会话数据和事务数据，把数据缓存完之后数据库再进行主备切换。安全的事务边界是指当前会话上的事务执行到某一个一致性点，可以分为两种情况，一是执行完事务后进行主备切换，即事务级排空，二是执行完一个SQL语句即可进行主备切换，即语句级排空，这个时候事务属于未提交状态，可以说语句级排空对业务影响更小一点。在整个数据库主备切换期间，GaussDB驱动进行连接保持，当数据库服务恢复了之后，先重建连接，再去恢复事务，事务恢复之后从事务一致性点继续执行。我们可以看到在正常的计划内主备切换的场景下，使用应用无损透明特性，对数据库来说是无感知的，而且这种主备切换会使用语句级排空。OLTP场景下，SQL语句执行时长都是毫秒级的，使用应用无损透明功能下的主备切换只是多增加了一个SQL语句执行时间的等待，也就是多等待一个毫秒级的时间，相对于原来几秒甚至几十秒的主备切换时间来说，多增加出来的毫秒级等待时间几乎是可以忽略不计的。计划外主备切换下面我们看一下计划外的场景。计划外可以说是灾难性的，突发的，它和计划内的主备切换场景的部分处理机制是有所不同的。针对计划外的主备切换，GaussDB数据库通过基于事务粒度来缓存整个事务里的语句和重放整个事务来实现。GaussDB自动以事务作为一致性边界，在事务执行过程中，驱动自动缓存执行过的事务SQL语句。数据库服务恢复后，GaussDB重新执行缓存的事务SQL语句，为了避免重复执行和提交事务，驱动重放时会首先根据逻辑事务ID来查询事务执行状态，如果事务已经提交了就不需要再执行。之所以采用事务粒度重放，而不是以语句粒度重放，是因为数据库的主库和备库之间的数据同步，是以事务为单位的，当事务在主库上被提交了，为了保证数据不丢失一定会把事务的wal日志实时同步到备库上，这是数据库的主备数据复制的一个通用基本的机制，已经完全能满足事务粒度重放的要求，而如果要使用语句粒度的重放，必然需要采用一些其他额外的手段措施，例如使用savepoint作为主备实时同步边界，用来阶段性保存进度等，和事务粒度重放相比，语句粒度重放使得方案更复杂，覆盖的场景更少，性能更差。容灾切换我们看一下容灾场景。异地容灾是两个城市相距几千公里，时延在几十毫秒，这么大的时延很难要求跨地区访问数据库，所以异地场景的容灾切换是数据库的容灾和业务程序容灾相互配合，同时切换的过程。目前容灾切换面临一个困境，因为这两个切换是互相独立的，数据库集群切换完了，而应用程序却没有切换完，端到端看数据库恢复了，但是业务没有恢复。为了解决端到端的问题，GaussDB提供了一个消息通知服务功能，即GNS。当数据库发生容灾切换时，比如说生产集群降为灾备集群时，会立即把消息发到应用，应用程序收到数据库集群降备的事件通知后，就可以立即进行主备切换；当数据库容灾集群升为主集群时，GNS会及时通知到应用程序，应用程序收到消息之后，就可以立即切流以恢复业务。这样一个相互配合的机制，可以解决端到端的RTO时长问题，不需要多余的等待，也不需要人为判断。除了异地容灾外，还有一种同城容灾部署场景，因为是同城，所以时延比较低，网络环境比较好，同城容灾这种场景下，可能只是数据库集群发生切换，而应用程序保持不变。这种场景如果我们使用GaussDB提供的应用无损透明机制，也就是通过连接保持和事务断点继续技术，在同城容灾切换时，在确保RPO=0不丢数据的情况下，还能保证数据库的容灾切换对应用程序也是透明的。今天我分享的内容就到这里，感谢大家。

近日，在第14届中国数据库技术大会（DTCC2023）的GaussDB“五高两易”核心技术，给世界一个更优选择专场，华为GaussDB首席安全架构师郭亮详细解读了GaussDB的高安全之密态等值技术。以下为演讲实录：各位嘉宾、各位老师下午好！我是GaussDB首席安全架构师郭亮，今天带来的分享是GaussDB高安全的关键特性，名字叫密态等值，是我们做的一个关于全密态的关键能力。数据成为生产要素，合规要求趋于严格大家应该都有切身的体会，近些年来数据的重要性越来越高，特别是国家已经把数据明确定义为了生产要素。生产要素是什么？就好像过去的石油，从工业革命时期开始，每一家工业企业几乎都要用到，是生产过程中必不可少的东西。现在，国家把数据定义为生产要素，意味着数据在各个领域也将要广泛的使用到。正因为这样，数据也上升成为了国家的“战略资源”。基于此，国家近些年发布了《中华人民共和国数据安全法》、《中华人民共和国个人信息保护法》等一系列法律，对数据安全的保护标准和使用规范越来越明确、越来越严格，这是我们切身体会到的一个大的趋势。数据库安全面临更大的威胁和挑战在这种新形势下，数据库的安全也面临很大的威胁。我们做了一个梳理，从里到外，数据库的安全问题一共有这几个方面。首先是数据安全传输，从网络层面容易受到攻击。大概20年前，安全人员在网络上部署一台嗅探器，就可以获取到许多的敏感信息。而之后陆续出现相关的标准和技术，经过一段时间的演进逐步成熟，演变成稳定的安全协议或安全架构，被广泛使用起来。例如HTTPS、TLS等，通过这种安全协议上的消解，我们发现，现在很难通过网络攻击，直接获取到敏感的东西。随后我们发现，SQL注入，以及网页跨站等问题开始越来越明显，数据展示层的攻击虽然和数据库不直接相关，而是从数据库把数据拿出来之后放到业务层，在业务层引入的风险，但这些风险也可以通过数据库提供的能力进行消减，因此也纳入数据库威胁范围内。同样也是随着技术的发展，一些稳定的安全框架、安全编码规范形成之后，这部分的风险逐渐消减了。再之后就是存储。各类安全规范里经常会提及到存储安全保护，因为我们知道数据一旦存在磁盘里，有可能永远都在磁盘里，直到磁盘销毁的那一天。如果里面存放了敏感数据，理论上每一天都有被偷走的可能，所以存储安全非常重要。关于这一点，相关的技术也在逐步成熟，像磁盘加密、透明加密等，而且各家机构企业也都非常重视对于物理硬件的保护，管理手段非常严格，所以磁盘被偷走的情况也很少出现。最近几年，我们经常看到各种各样的严重安全事件，主要在两个维度，一个是维护，一个是管理。维护就是后台操作系统的人员做一些数据库的维护操作，管理就是DBA通过数据库标准通道做一些管理操作。这也不一定是内部人员有问题，也有可能是这些内部人员的账号被泄露，近几年世界知名的一些大型数据安全事件，大部分是在这两个方面出了问题，都泄露了很多的数据，这是新形势下最大的安全威胁。GaussDB以数据为中心，构筑起3+1安全架构面对这些挑战，GaussDB构筑起了3+1的安全架构。这个架构的最外层，是基于智能化能力做一些风险、异常行为的感知，先感知有没有恶意攻击，阻挡一遍攻击。中层是访问控制能力，加上口令、身份认证等，进一步控制用户访问风险。里层是数据加密、脱敏，直接在数据上做文章，因而攻击者即使将外层全部攻破，拿走的也全部是密文状态下的数据。最后在这三层之外是审计，GaussDB做了很多细粒度的审计能力，还有防篡改。我们的审计日志是改不了的，即使篡改了也能看出来哪里被改了。所以，即使攻击者做了很多操作，把数据库也攻破了，但所有操作是跑不了的。而我今天分享的就是全密态里面的等值查询。GaussDB全密态等值查询，实现数据全流程保护全密态技术的原理很简单。比如在使用的时候输入一个SQL语句，加密驱动会找到哪个字段需要加密，然后用一个密钥把它自动加密，这样加密完后整个流程都是密文的，整个数据库跑的数据、以及跑完之后的结果都是密文数据，不论什么时候把数据拿走，拿走的也都是密文的，因为在整个数据库里面没有任何解密的过程。我们对查询回来的密文结果在客户端再进行解密，将明文数据返回给业务进行处理，从而能够做到无感知的使用和业务迁移。我们当前支持密态等值等查询，很快还会支持密态范围查询和模糊查询，都是基于密码学的算法。对于大规模数据，我们还可以基于密文数据进行索引和快速查询，并且支持JDBC、GO、Libpq等多种客户端驱动。客户端密钥管理，保障服务可信对加密来说，密钥是最关键的，所以全密态最主要的是密钥的分配。我们的全密态密钥是在客户端管理，一般属于业务管理人员负责，业务管理人员拿到密钥后把数据加密再交给数据库。逻辑很简单，我们在驱动层做了一个加密驱动，里面做了自动加解密和自动解析，能够自动识别哪个字段需要哪个密钥，再自动找到密钥、自动加密。这样只要业务不把密钥权限分配给到DBA和运维，他们就不能解密这部分数据，但是能够正常运维，如果有极特殊的情况需要看到明文敏感数据才能做管理运维，也可以把密钥赋权给相关人员。全流程加密，数据库内部全流程零解密第二层是加密，数据库里的整个流程是没有解密过程的，这是GaussDB实现的最主要的能力，包括传输、查询、存储等操作都有对应的方式，不需要解密再处理。但是，如果不单是在客户端需要数据导出，假如后端也需要直接导出数据，我们也可以在某些特殊场景下把密钥授权给下游做临时解密。这是加密方面的情况介绍。客户端轻量化解析，业务层加密透明无感知另外，如何做到透明无感知？大家应该知道解析器是数据库里的关键组件，我们在客户端里面做了一个轻量化解析器，对用户输入进去的SQL语句做自动的语法解析，找到哪个字段需要加密，而对于返回过来的语法也进行对应的解析。做完这个解析，客户端可以获取到需要加密的数据以及该数据在原始语句中的位置，然后重新构造一个新的SQL语句，数据库实际收到的就是加密之后的数据。经过客户端的自动语法解析，自动密钥管理和自动加密后，就可以继承标准的SQL语法，实现业务的透明无感知。对于业务迁移，也只需要修改一下建表语句，配置数据加密的表和加密字段即可，在实际增删改查过程中，所有操作语句都是与明文一样的。全密态等值和传统加密有什么区别？我做了一个总结。函数加密，是用户把密钥给到数据库，数据库在执行函数时做一个加密动作，是在数据库里加密。透明加密是数据库自己找一个密钥，在磁盘落盘时做加密，是磁盘做加密。全密态等值是客户找到密钥之后先把数据加密，再交给数据库，全生命周期都是密文的。应用案例自己生产的降落伞自己先跳，GaussDB的全密态能力已经在华为的MetaERP系统商用了。不久前，华为宣布实现自主创新的MetaERP研发，完成对旧ERP系统的替换，目前已覆盖了华为公司100%的业务场景和80%的业务量。ERP作为华为企业经营最核心的系统，伴随着华为20多年的快速发展，支撑了每年数千亿产值的业务以及全球170+国家业务高效经营。我们分析过一个业务，其中有270多个绝密字段，任何一个环节发生数据泄露都是重大事故。而之前的传统方案，是强制在应用层加密，加密完成后存到数据库，用数据的时候，先把数据查询出来之后做解密再使用，数据库做不了任何事情，这种方案加密时间长，性能损耗大，密钥需要自管，所以上了全密态。刚开始做自己的ERP系统的时候，数据库的容量、性能，特别是对批量数据的查询和处理，都是空前挑战。因为ERP业务实际是不看TPCC等基准测试指标的，他们只看实际业务场景的性能，比如批量插入、批量查询等，这给我们提供了一个良好的训练场，我们对批量处理性能等多种场景的实际应用都进行很大的优化，确保MetaERP在全密态下能满足业务对性能的要求。另外，ERP应用的时候有一个特点，交易查询完之后，下游还有一个分析库处理，我们有一个密钥授权能力，在业务负责人将密钥权限授权下游处理节点后，数据库就把密文数据解密后托管给下游处理，这样后台数据就可以不经过客户端，不同的应用只需要使用同一个KMS（密钥管理）就可以操作同一部分数据。另外，只要业务负责人不把密钥授权给其他任何人，就没有人能处理这个数据，包括管理和运维人员。最后是我们获得的一些成绩，GaussDB是国内首个通过国际CC EAL4+认证的数据库，也是国内首批通过信通院全密态数据库评测、国内首家通过信通院防篡改数据库评测的数据库产品。今天的分享就到这里，谢谢大家。

使用zookeeper客户端连接命令zkCli.sh -server 172.33.0.188:20029报以下错误：Connecting to 172.33.0.188:20029 Welcome to ZooKeeper! JLine support is enabled [zk: 172.33.0.188:20029(CONNECTING) 0] 2023-08-23 16:46:47,499 [myid:172.33.0.188:20029] - WARN  [main-SendThread(172.33.0.188:20029):ClientCnxn$SendThread@1312] - Connection 0x0 for sever MN01/172.33.0.188:20029, Closing socket connection. Attempting reconnect except it is a SessionExpiredException. java.lang.OutOfMemoryError: Java heap space     at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)     at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)     at org.apache.zookeeper.ClientCnxnSocket.readLength(ClientCnxnSocket.java:124)     at org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:84)     at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:352)     at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1301) 2023-08-23 16:46:48,694 [myid:172.33.0.188:20029] - WARN  [main-SendThread(172.33.0.188:20029):ClientCnxn$SendThread@1312] - Connection 0x0 for sever MN01/172.33.0.188:20029, Closing socket connection. Attempting reconnect except it is a SessionExpiredException. java.lang.OutOfMemoryError: Java heap space     at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)     at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)     at org.apache.zookeeper.ClientCnxnSocket.readLength(ClientCnxnSocket.java:124)     at org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:84)     at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:352)     at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1301) 2023-08-23 16:46:50,411 [myid:172.33.0.188:20029] - WARN  [main-SendThread(172.33.0.188:20029):ClientCnxn$SendThread@1312] - Connection 0x0 for sever MN01/172.33.0.188:20029, Closing socket connection. Attempting reconnect except it is a SessionExpiredException.上面的错误看起来是内存溢出的错误，这个怎么解决？另外一个问题，我的产品文档里写着端口号是：20029，但是我在网页版里面写的是24002。这2个之间的差异有哪位大佬可以解决下，谢谢

安装hive客户端后，并且将环境变量进行了source，也使用admin用户进行了安全认证，klist也可以返回正常结果。为什么我使用beeline连接后，报以下错误。产品文档中并没有找见这个问题产生的原因和解决办法，如何处理，谢谢。看问题是admin用户没有hdfs相关目录的权限，我是否可以直接修改hdfs的权限，安全性如何保证？Error: Could not open client transport for any of the Server URI's in ZooKeeper: Failed to open new session: java.lang.RuntimeException: org.apache.hadoop.security.AccessControlException: Permission denied: user=admin, access=EXECUTE, inode="/tmp/hive-scratch":hive:hive:drwxrwx---     at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:504)     at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkTraverse(FSPermissionChecker.java:420)     at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:323)     at com.huawei.hadoop.adapter.hdfs.plugin.HWAccessControlEnforce.checkPermission(HWAccessControlEnforce.java:74)     at org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer$RangerAccessControlEnforcer.checkDefaultEnforcer(RangerHdfsAuthorizer.java:687)     at org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer$RangerAccessControlEnforcer.checkRangerPermission(RangerHdfsAuthorizer.java:399)     at org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer$RangerAccessControlEnforcer.checkPermissionWithContext(RangerHdfsAuthorizer.java:236)     at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:240)     at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:2220)     at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:2204)     at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:2163)     at org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:60)     at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:3653)     at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1204)     at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:780)     at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)     at org.apache.hadoop.ipc.ProtobufRpcEngine2$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine2.java:602)     at org.apache.hadoop.ipc.ProtobufRpcEngine2$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine2.java:570)     at org.apache.hadoop.ipc.ProtobufRpcEngine2$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine2.java:554)     at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1093)     at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:1084)     at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:1007)     at java.security.AccessController.doPrivileged(Native Method)     at javax.security.auth.Subject.doAs(Subject.java:422)     at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1890)     at org.apache.hadoop.ipc.Server$Handler.run(Server.java:3037) (state=08S01,code=0)

8月16日，以“数智赋能 共筑未来”为主题的第14届中国数据库技术大会（DTCC 2023）在北京举行，华为云数据库技术专家张树杰分享了《GaussDB在HTAP上的探索与发展》主题演讲，介绍了华为云GaussDB在HTAP方向的思考与最新成果。以下为演讲实录：一、什么是HTAP？大家好！今天很高兴和大家分享《GaussDB在HTAP上的探索和发展》。首先，我们看一下TP和AP的特点。TP一般是做交易型的业务，它的数据量通常来说比较小，在GB~TB的范围内，它要求低时延、高吞吐，同时对高可用、故障恢复要求较高。AP一般用于对历史数据做分析，根据数据分析的结论为企业的商业决策提供一些支撑，因此AP对时延和吞吐的要求没有那么高，主要面对数据量大、查询偏复杂的场景。早期数据库对TP、AP区分没有那么明显，所有业务都放在同一个数据库上。随着时间的发展，数据量越来越大，人们倾向于把TP放在数据库层面上，AP由数据仓库解决，中间通过ETL工具把TP的数据传输到AP数仓上。这种模式兴起和盛行于20世纪90年代并持续到现在，我们一直还在使用着TP、AP混合的架构。随着CPU算力、内存容量、磁盘IO效率发生变化，一些老的软件体系结构随着新硬件、新算法的发展都在发生改变。所以在2010年左右，业内开始考虑把TP和AP同时融合到同一个数据库里，通过这种方式提升数据库处理数据的能力。 关于HTAP，目前还没有一个明确的定义，即使有一些公司或者个人给出了定义，但实际上也不是特别精确。我们总结了HTAP有两个关键特点：一个是采用In-Memory的架构。我们可以看到，无论是老牌的数据库厂商，还是新兴的数据库厂商，都不约而同采用In-Memory的架构来实现HTAP。另外一个是实时。我们当前的架构主要是，交易型的业务在行存的数据库上，分析型的业务在列存的数仓上，中间通过ETL工具传输数据。这个架构的问题是，它的数据新鲜度不够好，比如说先前在互联网应用方面，我们经常做一些个性化的用户推荐，在给用户推荐感兴趣的商品时，会在登录时对它进行一个用户画像，根据用户画像的结果推荐产品，这是一种实时分析的能力。另外就是防诈骗系统，需要实时的响应，实时分析这笔交易是否为诈骗交易。这种实时性的特点，对 HTAP方案提出了新的要求。我们当前的HTAP架构主要应对实时AP分析的能力，实时AP对性能上有一些影响，它随着数据新鲜度，也就是实时性要求变高，数据库的性能会有一些下降。二、HTAP架构模式有哪些？我们在设计HTAP架构时要考虑更多的维度，比如说硬件、资源隔离，从这些维度考虑，HTAP的架构会多种多样，加上应对的用户场景不同，会催化出不同的HTAP架构模式。我们对当前主流的HTAP架构进行了以下分类：第一种，IN-Memory Store模式。这种模式在同一个集群内对行存引擎做了增强，用空间换时间，在内存里保存一份列存数据，我们可以把他看成是一个列存索引，这种架构下的数据新鲜度比较好，行存和列存的数据完全同步，在行存和列存中间，会有一个Delta表记录增删改操作带来的增量数据，后台有进程定期将Delta表里的数据Merge到列存引擎。但是这种架构的扩展性一般，资源的隔离性不佳，能够支撑的列存的数据量也是有限度的，因此这种架构适用于TP为主，实时AP为辅的业务模型。第二种，主备架构模式。这种模式下主机上是行存模式，应对TP业务负载，在只读的备机上是列存模式，应对AP的业务负载，主备之间通过物理复制或逻辑复制的方式实现数据同步。这种方式的扩展性、资源隔离性都比较好，但是数据的新鲜度取决于主备之间的数据传输模式，如果采用同步复制，则主备的数据新鲜度较好，但是对主机的事务吞吐量会有所影响；如果采用异步复制模式，则主备的数据新鲜度取决于数据的延迟。 第三种，IN-Memory-Computing模式。这种模式将列式内存引擎和数据库对接，由数据库负责TP业务，列式内存引擎负责AP业务。由于其部署在云上，因此有很好的计算弹性，数据库和列式内存引擎之间通过逻辑复制同步数据，数据的延迟小于100ms，能够较好的兼顾数据新鲜度和性能之间的平衡。第四种，主列存+增量行存模式。通过主列存+增量行存的方式既能够较好的支撑TP业务，也能够应对AP业务，在TP/AP性能上做了一些均衡。其中增量行存可以看做是delta表，应对TP中的增删改操作，保证增删改操作的性能和TP系统基本一致，同时通过主列存引擎对AP业务进行加速，当然在做AP业务时，会同时访问增量数据和列存数据，达成数据的一致性。我们有了这么多模式之后，可以思考两个问题。一个是到底什么样的架构才是真正的HTAP架构？我个人的观点是没有适合的定义，因为在不同的业务场景下，TP和AP的占比不一样，包括周边各种环境，各种因素都不同，每个用户的选择也会不一样。包括我们在HTAP研发过程中接触到很多用户，每个用户都提出很多要求，像Orcale这种架构更适合重TP、轻AP的场景，而HANA这种架构更多是做偏AP分析型的应用。如果我们以TP、AP业务占比做一个横轴的话，每个架构在上面都有一个独立的坐标点。另外一个问题，我们当前这些HTAP的主流架构能不能取代以前的那种TP+ETL+AP的架构？从目前看，如果我们把HTAP定义为实时TP+实时AP，实际上是不能取代的，因为TP+ETL+AP这种架构，AP的数据量远远大于当前HTAP的主流架构所能支撑的AP数据量。三、GaussDB对HTAP的思考在GaussDB HTAP开发过程中，我们总结了以下实现HTAP架构需要关注的核心技术。第一，透明路由。它之所以成为关键的原因是因为增加了客户的易用性，提升了HTAP产品的商用价值。这里面有两个观点，一个是如果HTAP基于行存和冗余列存这种方式，需要判断哪些数据被冗余到列存里面来，因此提供一种自动化的方法根据业务特点来选择加载列存数据，并对用户透明就非常有意义。另外，TP业务要路由到行存引擎，AP业务路由到列存引擎，目前大部分架构还需要通过Hint的方式来实现业务分流，如果借助优化器的代价系统、以及当前的AI4DB技术，能够更大程度的提供业务分流的准确性，从而对用户透明，提高系统的易用性。第二，性能提升。我们把TP和AP融合起来比较困难的关键原因，主要是因为AP查询的复杂度比较高。如果是一个纯TP数据库，一些常规执行优化技术，比如说并行、编译执行、向量化执行，TP上虽然也有，但实际上很难有大的作为，因为TP要求的是低时延、高吞吐，这种情况下这些技术都有自己的启动代价，这些启动代价会对TP的性能产生很大的影响。在TP上，如果我们把HTAP里面的AP融入进来，这些技术就能大有可为，我们在这些技术的基础上对复杂查询进行加速，可以很好地支撑我们现在的性能，支撑我们的HTAP。第三，数据新鲜度。我们多次讨论实时性的问题，不同的数据新鲜度最后带来的就是我们不同的架构，有In-Memory的，有主备的，也有基于增量表技术的，都会带来不同的数据新鲜度。在这种数据新鲜度下，我们怎么保证数据新鲜度高，而且性能又好。在这些方面我们需要更多的思考，来保证我们HTAP架构能够具备更多应对用户的能力。第四，资源隔离。我们看到有的架构，比如说用户对TP性能要求比较高，要求你在引入实时AP的同时，不能影响TP的能力和性能。也有用户提出对整体的能力要求，对硬件没有什么诉求，如果有需要可以增加硬件。不同的用户有不同的要求，我们在面对这样的用户时，需要在资源隔离和数据新鲜度，以及性能的提升方面做好权衡。四、GaussDB在HTAP方向上的创新GaussDB在现有基础上对HTAP进行改造，并实现以下几个方面的提升：第一，性能提升数十倍。GaussDB已经实现向量化、并行、编译技术，性能提升10+倍，一些场景下还有更高的性能提升。最近我们基于HTAP做了更深度的挖掘和优化，比如基于降低内存拷贝、延迟读等技术，向量化的扫描算子最新的数据又提升了大概30倍左右。第二，100%的透明路由。我们既有基于Hint手工指定的方式，还有基于规则、基于代价、基于AI的透明路由技术。我们在基于代价的透明度路由方面，做了向量化优化技术；基于AI的透明路由方面，我们通过轻量的AI技术可以真正应用到商业版中，通过这些技术，TP、AP分流的准确率目前表现还是不错的。第三，100%的数据新鲜度。我们实现了在同Server内的列式的内存引擎，数据同步方面支持实时同步、在线同步、定期同步，保证了TP上的数据和IUD操作带来的数据修改及时同步到引擎上，可以实现100%的数据新鲜度。第四， 100%的资源隔离。如果用户更关注的是100%的资源隔离，我们也提供了基于主备复制HTAP模式，通过读写分离，把TP业务放到主机上，AP业务放到备机上，实现资源的隔离。目前，GaussDB既有基于同Server的实时的HTAP，也有基于主备技术的准实时的HTAP，同时在透明路由的加持下，能够准确的把业务分流同步分到实时的HTAP上，达成在性能、资源隔离、数据新鲜度方面有一个均衡的结果。

8月16日，第14届中国数据库技术大会（DTCC2023）在北京国际会议中心顺利举行。在GaussDB“五高两易”核心技术，给世界一个更优选择的专场，华为云数据库GaussDB首席架构师冯柯对华为云GaussDB数据库的高级压缩技术进行了详细的解读。以下为演讲实录：各位嘉宾，大家下午好！很高兴由我开始给大家带来今年GaussDB一系列新特性的技术解读。我解读的是第一个特性，高级压缩。GaussDB高级压缩全景高级压缩是面向业务全场景的数据库压缩解决方案，适用的场景主要分两类。第一类是存储类，主要为业务提供容量控制，减少业务扩容的概率和成本；第二类是传输类，主要是面向跨Region、跨AZ的业务场景如何去匹配业务的网络带宽的现实条件，为业务提供更稳定的SLA保证。这里面又有很多细分的场景，TP、AP都有。这里面有非常多的挑战，一是压缩算法怎么设计，二是怎么做冷热判定。我们在整个存储类的压缩里用的都是选择性压缩，基于系统自动发现数据的冷热，只压缩业务中相对比较冷的数据，不去碰相对热的数据。包括实现业务的零侵入、和存储引擎的结合，有很多技术挑战。典型场景和目标设计不同的场景对于压缩算法，包括压缩率、业务影响、业务侵入容忍度是不一样的。这里要介绍的，是我们第一个发布的OLTP表压缩的技术细节。讲这个之前，先讲一下OLTP表压缩究竟解决的是什么样的客户场景，这决定了我们整个技术目标。有两个典型场景是我们在真实业务中碰到的。第一个场景，客户的业务来自于IBM小机，整个单库容量达到几十个TB，容量比较大。业务如果迁移到开放平台，比较大的问题是单体容量太大，整个运维窗口的时间比较长。我们有不同的选择，可以选择大家说的拆库，也就是分表分库，但拆库意味着需要做整个分布式改造，对有些业务来讲是很多年的存量的关键业务，这种改造方式整个风险是非常高的。第二个选择可以用压缩，压缩可以减少容量，但客户在业务设计的开始并没有做冷热分离，比如没有把用户的数据基于时间维度做分片，如果用压缩，客户首要的诉求是能否做到压缩对业务的影响足够低，其次才是压缩率，这是第一个典型场景。第二个典型场景，客户业务基于分布式集群部署，容量增长得非常快，已经超过一个PB，并且还在不断增长。对于客户来讲，这是非常大的问题，需要定期做扩容。使用压缩同样可以帮助客户减少扩容的频率、变更的风险。但问题是一样的，客户数据同样没有做冷热分离，是面向扩展性来设计的，比如基于用户ID号进行分片，让不同用户的负载能够平均分配给不同的数据节点。由于没有做冷热分离，如果要用压缩，能否做到压缩对于业务的影响足够低，其次才是压缩率。这也是我们看到的非常典型的OLTP压缩的场景。我们对这两个场景进行了分析，推导出三个基本的设计目标。首先，整个压缩方案必须是零侵入的，不能假设业务的已有数据分布，不能说建一个分区，数据一定能区分冷热，因为业务没有这样的条件。不能对业务的数据分布、逻辑模型有任何的假设，方案必须是零侵入的。第二，如果业务开启压缩，对业务的影响应该是极低的，我们定义至少10%，甚至5%，这是非常重要的。第三才是合理的压缩率，2：1或3：1，如果没有压缩率，做这些事情的价值就不存在了。这三个基本目标也决定了我们后面整个技术方案的设计和工程落地。关键挑战一：如何判定业务的冷热数据？确定完目标，有三个比较关键的问题需要解决。一是怎么判定业务的冷热数据，二是判定完之后怎么和现有的压缩引擎结合，对压缩后的数据有效地存储，第三点才是怎么实现有竞争力的压缩算法。我们做冷热判定，首先是确定判定的粒度。可以按照表、分区、块来判定，也可以按照行来判定。判定的粒度越细，意味着对业务的侵入越低，对业务整个数据分布没有任何假设，当然实现的挑战也越大。基于我们定义的技术目标，在做OLTP表压缩时，第一个目标就是冷热判定必须是行级别的，这样对业务的侵入是最小的。我们利用了GaussDB现有存储引擎已有的机制。GaussDB现在的存储引擎和其他引擎一样，在整个数据上除了存放用户数据之外还存放元数据，元数据里有事务信息，这个事务信息通常是用来实现事务的可见性，里面记录了最后一次修改的事务ID号。当这个事务ID号足够老，对于当前所有事务都可见，这个时候我们把事务ID号替换成物理时间戳，这个物理时间戳可以用来表达这行数据最后一次修改的时间是什么时候，如果这个时间足够早、足够老，真正达到了冷的条件，那么我们就可以对它进行压缩，用户可以用非常简单的逻辑实现冷热的判定。第二个例子是，用户可以自定义冷热条件，这个行如果长时间没有做任何修改，系统就可以把它压缩掉，否则不要碰，这是一个非常简单的策略。如果客户业务中有一些字段有非常清楚的冷热属性，比如交易的时间、交易的完成状态，那可以指定这个字段进行冷热判定。或者客户大部分的交易数据都满足3个月前的交易是冷数据，但其中某些特殊类型的交易，像担保交易，可能没有办法满足这个约束，这时候也可以自定义冷热条件。比如交易状态必须是完结的，或者交易类型不能是特定类型，通过自定义条件和最近修改时间的组合，可以灵活地定义什么样的数据应该压缩。这是第一点，怎么做冷热判定。关键挑战二：如何对压缩后的数据有效地存储？第二点，压缩后的目标数据怎么存。根据总体设计目标，我们希望做到对业务的侵入越低越好。我们选择了直接做块内的压缩：把一个块内所有满足冷热判定的行一次性压缩完，把压缩后的数据包就存放在当前数据块内。这样做从压缩率上讲并不是最优选择，但从对业务的影响上讲是一个更好的选择。因为业务即使定义了冷热判定条件，我们仍有一定的概率会访问冷数据，我们希望通过块内压缩的实现来保证访问冷数据的代价有一个确定性的上限，这是块内压缩的基本思考。关键挑战三：如何实现有竞争力的压缩算法？为什么做选择性压缩？很简单，没有任何一个压缩算法能做到数据压缩之后对业务没有影响，今天没有这样的黑科技，这是我们基本的技术判断，所以要去平衡压缩率和对业务的影响。我们首先做的是选择性压缩，业务数据分布满足典型的80-20分布政策，80%的数据占有80%的存储容量，但只消耗了20%的算力。比如银行交易，随着时间的推移，整个订单的访问频率会迅速降低，这是非常典型的满足冷热特征的业务。如果做选择性压缩，那么只压缩那些占用80%存储容量，但只消耗20%算力的冷数据，就意味着我们在节省存储成本方面达成了80%的目标；而不去压缩那些只占用20%的存储容量，但却消耗80%算力的热数据，就意味着我们在降低对用户的业务影响方面达成了80%的目标，这是非常简单的技术选择。压缩算法我们也看了一些，比如LZ4是现在性能最好的算法，我们一开始用的就是这个算法，但比较大的问题是压缩率相对较低。如果仔细去分析算法原理，LZ4是基于LZ77算法的一种实现，是把压缩的数据看成一个连续的字节流，从当前开始寻找匹配的字符串，找到字符串长度和偏移进行编码来代替被匹配的字符串，从而实现压缩的效果。LZ77算法从原理上讲非常适合于长文本，相对不太适合像结构化数据这样的，里面有大量的数值类型和短文本，这是数据库的特征。我们做了很多优化，比如对数值类型做了差值编码，所以压缩框架实际上有两层，第一层对数据做编码，第二层用LZ77算法。原生LZ77算法有很多优化是面向长文本的，包括3字节的编码，我们做了非常多的工程优化，使它更容易面向短文本，比如两字节短编码，包括内置行边界。这里我们无法给出很多细节，主要的优化背景其实就两个：一个是通用压缩算法并不特别适合于关系型数据库结构化数据的场景，二是我们所做的这些工程优化，从通用的压缩场景来讲，并不一定是最优的，但它们是特别适合关系型数据的。竞争力评估最后有一个简单的评估，是通过TPCC和TPCH测试对目前的商用数据库O*进行的压缩率评估。O*和我们的GaussDB一样，也提供了完整的冷热判定能力，但由于发展原因，它实际上先做了数据压缩，再做冷热判定，所以整个压缩算法的压缩率是比较低的；我们使用了标准的TPCH的数据，测试表明我们的压缩率相对于O*平均提高了50%，这些数据可以被直接验证。其他的一些厂商，像开源数据库，还有国内的厂商都提供了压缩的解决方案，但共同问题是没有做冷热判定，对用户来讲可以指定一个表或一个分区，里面的数据要么都被压缩，要么都不压缩。压缩意味着存储成本节省，但性能会下降，不压缩则是另外一个选择。这个看上去简单的选择对客户来讲反而是最难的，这也是为什么我们看到今天有很多压缩的解决方案，但用户却不会去用，因为谁也不知道开启压缩之后有什么后果，这是比较大的问题。这里我们也做了一个标准的TPCC的测试评估，基于GaussDB单机版本进行选择性压缩。根据TPCC的语义，所有已经配送完成的订单就不会再变更，但仍有一定的概率被访问到，这是非常贴近于真实业务场景的访问模型。所以，我们的压缩算法选择了压缩流水类数据，比如订单数据，而一些状态类的数据，比如库存、账户等没有去压缩，在流水数据里，我们也只压缩已经配送完成的订单，不压缩没有配送完成的订单。从最后的结果看，整个压缩之后对于业务的影响在1.5%左右。我们相信我们是业内第一个在150万tpmC性能峰值仍然能够开启压缩并且性能基本不下降的产品。下一步计划：语义压缩我们已经打破了数据编码和压缩算法的边界，但对压缩算法的使用本质上没有变化，即把整个数据看成是一维的字节流。但关系数据是两维的、结构化的数据，所以在数据的行与行之间、列与列之间存在非常丰富的关联。这种关联主要来自两种场景，一种是业务本身在做建模时引入的关联，比如为了消除连接，数据模型设计成扁平化或低范式化，这会引入非常常见的关联。第二种是业务服务化改造进行服务的分层，数据在不同的服务分层之间被不断传递而造成的一种关联。我们通过一些算法自动发现这种结构化数据之间的关联，发现这些关联不是用于商品推荐或者服务治理，而是希望通过消除这些关联达到压缩的目的。在很多场景里，这种基于语义的关联消除技术会比通用算法提供更好的压缩效能，这是我们后面会重点去构建竞争力的地方。小结为什么做高级压缩的特性？因为我们希望在三个领域实现业内领先。一是在性能敏感场景，在提供合理的压缩率的前提下，对业务的影响（越小越好）实现业内领先。二是在成本敏感的场景，在提供合理的压缩解压性能的前提下，压缩率（越高越好）实现业内领先。第三，大家可能注意到，冷热判定本身不仅可以做数据压缩，还可以做很多别的工作，比如多存储介质、负载的感知，我们希望对于整个冷热判定，包括模型及方法，在能够支持的业务领域的广度方面，能够做到业内领先，这是我们做高级压缩特性的一个基本目的。我的分享就到这里，谢谢大家。

8月16日，由IT168联合旗下ITPUB、ChinaUnix两大技术社区主办的第14届中国数据库技术大会（DTCC2023）在北京国际会议中心顺利举行。大会以“数智赋能 共筑未来”为主题，邀请了上百位行业专家，一起探讨新时代下各类型数据库的最新动态和应用实践，带来一场数据库领域的年度盛宴。在上午的主会场，华为云数据库服务产品部总经理苏光牛围绕“打造最可信数据库，华为云GaussDB给世界一个更优选择”做了精彩发言。软件世界，“可信”是基础苏光牛说，在软件世界里，可信是所有创新和可持续发展的基础。过去，大部分我们熟知的公司本质上都可以说是软件公司。随着云服务的兴起，大家逐步认识到，软件服务才是数字化转型的核心，未来也将从软件定义一切演进到“一切皆服务”。不管哪个时代，数据库始终是软件产业中的根技术，它上连应用，下连基础设施，有承上启下的关键作用。而如今，在中国的软件和云发展的过程中，无序的开发和不受控已经成为明显的弱点。根据第三方报告显示，全球超过四分之一的组织经历了与公共云相关的安全事件，开源软件也被无限制地广泛应用组合，其中，缺乏供应链透明度的软件极易受到恶意篡改和攻击，种种风险都在阻碍软件和云产业的高速发展。面临严苛的外部环境，还有企业数字化转型过程中的巨大不确定性，让业界都充分认识到，软件必须坚持可信优先。华为也以此作为对自身发展的要求，在2019年发布了IPD可信框架与方法，表示产品必须具备安全性（security）、可靠性、可用性、韧性、隐私性、安全性（safety）六大特征。这也驱动了华为的数据库从软件自主逐步走向软件可信。华为可信软件工程实践华为的可信框架构建起了从产品定义、系统设计、软件实现到交付运维运营等所有环节、从结果到过程的全部可信，保证产品从创新到客户落地的整个过程是完整、双向一致可追溯的。苏光牛表示，华为云GaussDB数据库就是基于这套可信软件工程打造的产品。早在2001年，华为就开始了对数据库的研发，并广泛应用到华为通信领域的各个产品中。2019年，随着华为IPD可信框架和方法的发布，GaussDB数据库也正式对外发布，不仅要解决华为集团内部业务连续性的诉求，还将承担金融、关基等更多行业对数据库全面创新的使命。这几年，大量的银行、保险、证券、能源等行业的核心业务系统都运行在了GaussDB数据库上，经过各种场景的打磨，华为云GaussDB也逐渐成熟，去满足更多场景下的客户诉求。同时，软件和应用的开发还高度依赖相关的开发工具，数据库也不例外。华为研发了一整套自主创新、完全可信的软件开发流水线，提供从项目管理、IDE、代码开发到部署端到端的全生命周期能力。华为云GaussDB数据库基于这套软件开发流水线完成了开发，还构建起6环9层33步的测试防护网，覆盖了绝大部分代码和场景，当前已经有20万测试用例消减了大部分基本问题，并通过全链路的深度交互测试平台减少低概率、复杂交互类的问题，还构建了10多个行业客户场景化的防护网，消减了场景化问题，实现真正的高质量。基于可信软件工程，打造“五高两易”全新的GaussDB“基于华为可信软件工程方法论，我们将可信理念融入到了GaussDB的每个能力中，形成了高可用、高安全、高性能、高弹性、高智能，易部署、易迁移五高两易的全面能力。”苏光牛就其中的一些关键能力做了分享。高可用：GaussDB与工行联创推出了国内首个基于存算分离的双集群强一致方案，让同城的两个数据中心完全部署两套独立的数据库软件，任何软硬件故障完全隔离，真正实现了7*24小时服务不间断；对于一些容灾等级要求不高的系统，也提供基于本地盘的单集群跨数据中心拉远的方案，更具性价比，满足客户不同容灾等级的可靠性要求。针对慢SQL导致数据库资源使用升高、执行变慢、无法继续对外提供服务的问题，GaussDB通过全局快慢车道、单类SQL精准管控实现了对慢SQL的资源管控，通过内存熔断、线程池熔断等机制让系统扛得稳、可逃生，满足了可信框架中的“韧性”要求。高性能：深入到数据库最底层对性能进行了优化，采用B-Link协议和堆表设计，避免了页面结构变化导致的性能下降问题；用逻辑时钟CSN代替事务快照，极大提升了大规模分布式下的处理性能；写日志路径采用无锁设计，足以支撑200万以上tpmC的写入性能。通过工程实践的不断打磨，GaussDB实现了真正的高性能。高安全：相比传统数据库采用单点存储加密可能会引起的管理员恶意获取密钥解密、信息泄露等风险来说，GaussDB的全密态方案让用户自己持有数据加解密密钥，加解密过程仅在客户端完成，让数据在存储、传输、查询整个生命周期过程中均以密文形态存在。因此无论数据处于何种状态，攻击者都无法获取到有效信息，从而保障了企业数据全生命周期的隐私安全。 高智能：对于DBA来说，最具挑战的问题是，当系统出现亚健康状态，如何快速感知到问题，及时识别和分析阻塞点，从而方便进一步的判断和操作。GaussDB的SQL Audit工具，在开发验证阶段就可以帮助SQL通过自动审核满足规范要求，大幅降低系统出现亚健康的情况，智能运维则提供了慢SQL根因分析、索引推荐、异常检测等多样化的运维功能，让DBA更加得心应手。 易迁移：异构数据库迁移是一项大工程，企业需要考虑如何选择合适的目标数据库、迁移的风险、工作量、如何提升迁移效率、改造后如何保证数据的准确性等一系列问题。对此，GaussDB的一站式工程化迁移解决方案，通过UGO提前评估、结构迁移、DRS在线迁移和数据对比、流量回放、灰度并行等，让原本不确定的迁移担忧变成确定、可信的迁移计划。GaussDB成为TOP客户的一致选择苏光牛提到，华为云GaussDB已经成为金融政企客户自主创新的一致选择，得到行业的广泛认可。Gartner最新报告显示，华为云是全球唯一获得云数据库管理系统“客户之选”的云厂商，客户满意和推荐度高达98%。在金融行业，国有六大行中的四家都已经上线了GaussDB数据库。工商银行上线了200多套GaussDB数据库集群，其5A级信贷系统的可靠性得到了十倍的提升；邮储银行使用GaussDB建成了全球银行最大的分布式核心系统，业务效率提升了30%以上。在关基行业，国家管网、国网陕西电力、陕西财政等越来越多的大型央国企和政务系统也纷纷选择了GaussDB作为核心系统自主创新的首选，性能都得到大幅度提升。未来，华为云GaussDB将会持续打磨更领先的技术，更多的创新，做企业核心应用云化的可信数据底座，也希望和更多客户和伙伴一起发力，繁荣数据库产业生态，共赢数字化未来。

1 问题描述集群状态显示DN实例一直处于catchup状态。2 机制说明主备DN实例为保证数据双副本和一致性原则，需要将主DN产生的事务日志及时同步给备机，备机实例接受不及时，或备实例故常重新恢复后，会重新追赶主实例的数据，来到达主备一致状态，追赶的过程就是我们在查询集群状态时看到的Catchup状态。 主备追赶分两种类型，一种是xlog追赶，一种是数据页追赶。 更深入的机制原理，有兴趣的小伙伴可以在社区留言问题或者浏览社区精品机制原理文章。3 问题分析切换omm加载环境变量，查询集群状态，其中DN实例6021主备关系如图： 登录数据库查询catchup追赶 虽然catchup是备DN实例，但catchup线程是在主DN实例，分析dn_6021日志,发现cacthup线程在反复重启，如图： 图片详细信息，直接上文字：2023-08-09 20:38:28.893 64d377f3.5009 [unknown] 281467704376880 [unknown] 0 dn_6021_6022 00000 0 [BACKEND] LOG: catchup process start to search all bcm files. 2023-08-09 20:38:29.936 64d377f3.5009 [unknown] 281467704376880 [unknown] 0 dn_6021_6022 01000 0 [BACKEND] WARNING: page verification failed, calculated checksum 42173 but expected 56380 2023-08-09 20:38:29.936 64d377f3.5009 [unknown] 281467704376880 [unknown] 0 dn_6021_6022 XX001 0 [BACKEND] WARNING: invalid page in block 16178 of relation base/16538/13642638, try to remote read 2023-08-09 20:38:29.936 64d377f3.5009 [unknown] 281467704376880 [unknown] 0 dn_6021_6022 00000 0 [REMOTE] L0G: remote read page, file base/16538/13642638 block 16178 from :25512 2023-08-09 20:38:29.937 64d377f3.5009 [unknown] 281467704376880 [unknown] 0 dn 6021 6022 58030 0 [REMOTE] ERROR: remote read failed from :25512, remote data checksum error, maybe remote data corrupted 2023-08-09 20:38:31.941 64d377f3.5009 [unknown] 281467704376880 [unknown] 0 dn 6021 6022 00000 0 TBACKEND] LOG: catchup process start to search all bcm files. 2023-08-09 20:38:32.995 64d377f3.5009 [unknown 281467704376880 [unknown] 6 dn 6021 6022 01000 0 [BACKENDJ WARNING: page verification failed, calculated checksum 42173 but expected 56380 2023-08-09 20:38:32.995 64d377f3.5009 [unknown] 281467704376880 [unknown] 0 dn 6021 6022 XXO01 0 [BACKEND1 WARNING: invalid page in block 16178 of relation base/16538/13642638, try to remote read4 问题根因主备DN有磁盘或历史磁盘故障引起；5 解决方法1、需要查询物理文件对应表是否存在； 2、备份主备DN实例报错物理文件和bcm文件； 3、此步骤属于高危操作，请联系华为工程师处理；

1. 背景GaussDB作为一款企业级分布式数据库，提供了“同城跨AZ双活、两地三中心、双集群强一致”等极致的高可用容灾能力。当某个数据库节点由于故障无法对外提供服务时，为了继续保证数据库服务的可用性，JDBC驱动会将业务后续的数据库连接请求发送到其它可用节点上。但故障发生后，已经与故障节点建立会话的连接无法自动切换到可用节点上，导致使用这些连接的业务单元发生报错。如果业务单元缺少连接重试或业务一致性校验，可能会引起应用中断，甚至业务数据不一致的问题，造成用户严重的业务损失。因此，华为云GaussDB数据库提供了一种在数据库故障情况下的客户端连接转移方案 —— ALT（Application Lossness Transparent，应用无损透明）。该方案的原理是，当数据库集群的某个节点由于故障无法对外提供服务，若此时集群内还存在其它可用节点，则将故障节点上的会话连接自动迁移到目标节点上，客户端无需再次发出连接请求，仍然可以继续执行数据库操作。整个过程中，客户端应用程序是无感知的，就像是经历了一次略有延迟的SQL请求处理，极大地提高了数据库服务的可用性。2. 技术架构我们先来看下ALT的技术架构和运行原理：图1 - ALT架构示意图从上图中可以看到，GaussDB集群引入了一个独立组件GNS（GaussDB Notification Service），用于检测获取数据库各节点的实时状态信息。当应用程序调用JDBC接口首次向集群中的任意节点建立连接时，JDBC驱动会与GNS服务建立集群状态订阅链路。当GNS检测到集群状态发生变化，会通过订阅链路将状态变化事件发送给JDBC驱动，事件处理线程收到任务后，再通过集群连接管理器中保存的引用副本对受到影响的连接进行管理和迁移。GNS组件采用的是多节点对等多活的部署方式，每个GNS服务都拥有集群的全量状态数据，JDBC驱动只需要与其中任意一个GNS建立订阅服务，就可以管理应用程序在该集群所有节点上的连接。3.关键能力在了解了ALT的整体架构和运行原理之后，我们再来看看它具备哪些关键能力，这些能力可以为客户带来什么样的业务价值。3.1 快速应用通知ALT提供了一种数据库状态变化的主动消息通知机制。JDBC驱动通过GNS服务来订阅业务所用数据库集群的状态，当集群中的节点发生状态变化时，GNS将变化事件推送给JDBC驱动，后者再根据集群的最新状态对目标数据库上的连接进行管理和迁移。同时，JDBC驱动也向应用程序提供了集群状态变化的回调函数注册接口。应用程序可以针对某些数据库连接，向JDBC驱动注册状态变化的回调函数。当集群状态发生变化时，JDBC驱动会对注册的函数进行调用，通过注册回调函数，可以很方便地在业务侧实现数据库状态变化的邮件通知、告警平台上报等运维管理操作。3.2 连接无感迁移       当检测到GaussDB数据库发生故障或即将进行停机维护时，JDBC驱动的事件处理线程分析每条受影响的连接，确定是否有满足连接要求的其它数据库节点，如果存在，则将连接迁移至可用节点，并且恢复连接的会话状态信息。在主动停机维护场景下，使用者还可以通过参数来配置等待可用节点出现的连接挂起时长，从而提高集群统一维护场景下的服务可用性。      3.3事务断点续传连接开启ALT后，JDBC驱动和GaussDB服务端都会跟踪记录当前会话的事务状态信息。如果数据库正在处理SQL请求时发生故障，当连接迁移到新节点后，ALT根据记录的事务状态信息将会话恢复至故障前，事务则从中断的位置继续执行，避免了由于数据库故障导致的业务中断和应用层的数据不一致现象。ALT特性给客户带来的价值可以总结为： （1）避免数据库故障时，无法及时获取服务端状态而导致RTO过大；（2）加速JDBC指定节点类型（targetServerType）的连接建立；（3）集群停机维护时的业务连续性保证；（4）数据库故障时的业务连续性保证；（5）集群容灾切换时的快速应用通知。4. ALT特性演示JDBC开启ALT方式样例：URL=jdbc:opengauss://host1:port1,host2:port2,host3:port3/database?enableALT=true&gns=gns_host1:gns_port1, gns_host2:gns_port2当应用程序使用JDBC驱动访问GaussDB数据库时，只需要在连接URL中添加配置项enableALT和GNS监听地址即可开启ALT服务。ALT服务的最小订阅粒度是连接级别的，JDBC驱动支持向同一集群同时建立ALT连接和普通连接。演示场景：GaussDB集中式集群进行switchover操作时，观察使用ALT连接的SQL请求执行情况。演示步骤：       应用程序与数据库主节点分别建立普通JDBC连接和启用ALT特性的连接，使用两条连接同时执行下述SQL命令，观察集群完成switchover后，数据库连接是否可以正常使用。1. 客户端发送SQL请求：查看当前访问的数据库实例信息SQL> show listen_addresses;2. 客户端发送SQL请求：创建和使用数据库对象SQL> create table alt_test_switchover(mes text);SQL> insert into alt_test_switchover values('message before switchover');<-- 集群操作：switchover -->3. 客户端发送SQL请求：使用数据库对象SQL> insert into alt_test_switchover values('message after switchover');SQL> select mes from alt_test_switchover;4. 客户端发送SQL请求：查看当前访问的数据库实例信息SQL> show listen_addresses;对比结果：（1）普通JDBC连接：集群进行switchover后，数据库连接断开，应用程序无法再使用该连接发送SQL请求。图2 – 普通JDBC连接日志（2）启用ALT特性的连接：集群进行switchover后，数据库连接自动迁移到新的主节点上，应用程序可以继续使用该连接发送SQL请求。图3 – ALT连接日志GaussDB作为一款企业级分布式数据库，具备五高两易（高可用、高安全、高性能、高弹性、高智能，易部署、易迁移）的核心优势。在满足金融核心业务的可靠性要求方面，GaussDB与工行联创推出了国内首个双集群强一致方案，实现集群级故障完全隔离RPO=0，而全新的应用无损透明方案，又做到了系统故障应用无感知，真正实现了业务7*24小时不中断，为企业带来更极致的高可用体验。