分布式数据库技术未来的发展方向是多元化的，主要涵盖以下几个方面：扩展性与自动化管理：分布式数据库系统将进一步提升其水平扩展性，这意味着系统可以根据需求动态地增加或减少节点，从而适应不断增长的数据量和访问负载。同时，自动化管理和调优将变得更加重要，包括自动数据分片、数据迁移、负载均衡和故障恢复等功能，这将大大降低管理成本并提高系统稳定性。一致性与可用性的权衡：在保证数据一致性的前提下，分布式数据库系统将致力于提高系统的可用性和性能。一些分布式数据库系统可能会采用较为宽松的一致性模型，如BASE（基本可用、软状态和最终一致性）模型，以在一致性和可用性之间找到更好的平衡点。多模型支持与多租户隔离：随着应用场景的多样化，分布式数据库系统需要支持不同的数据模型，如关系型、文档型、键值型和图形型等。同时，为了满足不同租户的需求并确保数据的安全性，多租户隔离也将成为分布式数据库技术的重要发展方向。与云环境的深度融合：随着云计算的普及，分布式数据库将更多地与云环境进行融合。这种融合不仅可以解决私有部署灵活度低、成本过高的问题，还可以利用公有云资源实现低成本的容灾和算力扩展。此外，多云支持也将成为分布式数据库的一个重要特性，它具备快速部署、快速销毁、前期投入低等特点。高可用能力的提升：分布式数据库将采取更好的方案来提升其高可用能力，包括容灾能力建设和可靠性建设。这将有助于确保在故障发生时，系统能够迅速恢复并继续提供服务，从而实现7×24小时的服务不中断和数据零丢失。智能化与AI集成：随着人工智能技术的快速发展，分布式数据库技术有望与AI技术进一步融合。这种集成将使数据库系统能够自动学习并优化查询性能，预测未来的数据需求，甚至主动进行故障预测和修复。AI的引入将大大提高分布式数据库的智能化水平，使其能够更高效地处理和分析海量数据。安全与隐私保护：随着数据泄露和隐私侵犯事件的频发，数据安全和隐私保护成为了分布式数据库技术发展的重要方向。未来的分布式数据库系统将更加注重数据加密、访问控制、审计追踪等方面的安全设计，以确保数据的安全性和隐私性。实时处理与分析：随着物联网、边缘计算等技术的普及，实时数据处理和分析成为了重要的需求。分布式数据库需要支持实时数据的快速采集、存储和分析，以满足对实时性要求较高的应用场景，如金融交易、物流追踪等。跨平台与标准化：随着技术的不断发展和市场的不断变化，分布式数据库系统需要更好地支持跨平台部署和标准化操作。这将有助于降低系统的迁移成本，提高系统的互操作性和可维护性。绿色与可持续发展：在追求性能和可用性的同时，分布式数据库技术也需要关注绿色和可持续发展。通过优化资源利用、降低能耗和减少碳排放等方式，实现数据库系统的绿色化运行，为环境保护和可持续发展做出贡献。总之，分布式数据库技术的发展将继续向着智能化、安全、实时、跨平台和绿色等方向前进。随着技术的不断进步和应用场景的不断拓展，可以期待分布式数据库在未来将发挥更大的作用，为各行各业提供更加高效、安全、可靠的数据存储和处理服务。

这些年大家都在谈分布式数据库，各大企业也纷纷开始做数据库的分布式改造。那么，所谓的分布式数据库到底是什么？采用什么架构？优势在哪？为什么越来越多企业选择它？分布式数据库技术会向什么方向发展？带着这些疑问，一探究竟吧！参与文末的话题互动，更有机会赢取精美奖品~分布式数据库的架构演进随着数据量的爆发增长，传统集中式数据库面临极大的挑战：性能瓶颈：数据规模爆发增长，传统集中式数据库难以维持数据量大时的性能，而分布式数据库的性能可以水平扩展；缺失混合负载能力：数据量爆发增长带来对数据分析（OLAP）需求的增长。企业需要使用两套系统分别支撑事务交易（OLTP）和数据分析（OLAP），不仅造成了大量的数据冗余，同时增加了系统的复杂度和运维难度。而分布式数据库的混合负载能力可大幅度提升分析的时效性，减少数据冗余，并大大提高灵活性；高昂成本：集中式数据库水平扩展难，可靠性需要付出高昂的成本。而分布式数据库的架构支持灵活扩展，实现高可用方案的成本较低。分布式数据库与单机数据库的不同在于其可以将核心功能扩展到多台节点，甚至多个地域，包括事务管理、数据存储和数据查询等。从实现方式上看，分布式数据库主要有3种不同的技术路线：1. 分布式中间件 + 单机数据库。这条路线本质上是分布式系统由两部分组成：a) 上层是分布式中间件：维护一套统一的分片规则，提供SQL 解析，请求转发和结果合并的能力。b) 底层单机数据库：开源MySQL或PG单机数据库，提供数据存储和执行能力。这种方式主要使用比较成熟的内核来解决扩展性的问题，所以生态友好、成本较低，也比较容易实现。不过，缺点也显而易见。比如功能降级、在全局事务能力和高可用等方面存在短板，需要有针对性增强，导致整个方案的复杂度高、机器冗余多。最重要的是，因为使用的是开源产品的内核，数据库会始终受制于开源代码修改、专利、发行方式等很多方面的风险，这种形式显然无法满足当前国内金融、政企客户的需求。2. 基于分布式存储的分布式数据库。这种形态基于分布式存储，再叠加数据库能力。大部分公有云数据库采用这条技术路线。华为云GaussDB(for MySQL)就是这种形态的典型代表。这条路线有限地解决了扩展性问题，数据一致性主要依赖分布式存储引擎。上层的计算节点无状态，共享存储提供跨节点读写。这种架构充分利用分布式存储提供的高级特性，更容易形成技术竞争力。但是这种架构的扩展性有限，尤其是写节点。另外，这种架构对底座（分布式存储）有比较重的依赖，线下实现的成本高。3. 原生分布式数据库。这种形态是基于分布式数据库理论实现的分布式数据库。这条路线是根据分布式一致性协议做底层设计。原生分布式数据库将分布式存储、事务和计算结合在一起，数据由系统自动打散并存储多个副本，通过一致性协议保证多个副本和事务的一致性。这种形态更容易在数据库本身所擅长的领域发挥优势，比如说性能、复杂SQL处理能力、企业级能力。集群的扩展和收缩对应用透明，按需扩展，支持大规模部署限制；数据一致性由事务层一致性协议保护，安全性更高；灵活部署，多活架构，对硬件的依赖低，可以通过普通服务器实现集群和高可用。因为金融政企客户在使用分布式技术之前，往往已经有分库分表、使用分布式中间件产品的经验，所以对原生分布式架构的认可度更高，学习成本也相对较低，因此，这种形态也是国内当前被采用较多的一种。华为云GaussDB分布式数据库就是这种形态的典型代表。GaussDB基于华为在数据库领域20多年的战略投入，已经在金融行业积累了非常丰富的实践经验，是企业数字化转型、核心数据上云、分布式改造的信赖之选。原生分布式数据库的挑战和关键技术原生分布式数据库基于分布式数据库理论，是一款对于用户应用透明的分布式数据库。不过，实现分布式关系数据库有几个关键挑战：第一，安全可信。分布式、云化环境的复杂性增加了安全风险，比如数据泄露和丢失的风险增加，身份认证和访问控制以及数据传输、存储安全的控制难度提升。第二，事务系统的正确性及性能。分布式数据库中经常有一次操作涉及多台数据库的场景，需要一种方案来维护整个数据库集群事务的ACID特性，避免出现部分成功部分失败等无法接受的情况。另外，在大并发场景下事务管理器容易成为性能的单点瓶颈，比如获取事务唯一标识、全局快照、频繁交互导致大量的网络通信和锁等待等。第三，分布式查询能力。在分布式系统中，需要在最短时间内获取准确的查询结果，提升查询性能。第四，高可用能力。分布式数据库需要确保异常场景下（如：节点硬件故障或者Bug宕机等）数据库系统的连续可用。分布式数据库的挑战和关键技术GaussDB分布式数据库研发了一系列高性能、高可用、安全特性迎接上述四大挑战，下面挑选几个有代表性的特性加以说明。全密态传统的加密方式在服务端加密，密钥管理员是可以获取的。而全密态数据库的密钥掌握在用户自己手上，数据库管理员无法获取，加解密过程仅在客户侧完成，数据在存储、传输、查询整个生命周期过程中均以密文形态存在，避免管理员恶意获取密钥解密数据。全密态数据库分布式事务GTM-Lite如下图所示，GaussDB没有采用传统的事务列表的管理方式，而是提供了一个CSN（提交系列号），通过对比CSN的大小来实现事务可见性判断。GTM-Lite技术示意当事务开始时，根据事务隔离级别的不同，从GTM-Lite获取一个CSN值，作为这个事务的查询快照点（如果是可重复读，只需要在事务开始时获取一次CSN值，如果是读已提交，每次SELECT时都需要重新取一次CSN值）。当事务提交时，向GTM-Lite申请一个新的CSN值，作为这个事务提交CSN值，并记录到事务提交记录中。GTM-Lite技术通过CSN提交序列号进行可见性判断，无需耗费大量计算资源来遍历列表；无锁化原子操作提供CSN序列号，无需锁等待；节点间事务交互仅需要一个CSN，网络开销跟事务规模无关。在保证事务全局强一致的同时，提供高性能的事务处理能力，避免了单GTM的性能瓶颈。分布式查询优化1. 分布式执行GaussDB是如何处理分布式数据库集群中的业务应用SQL的呢？1）业务应用的SQL会下发给CN节点；2）CN利用数据库的优化器生成分布式的执行计划，每个DN会按照执行计划的要求处理数据；3）数据基于一致性Hash算法分布在每个DN，因此DN在处理数据的过程中，可能需要从其他DN获取数据，GaussDB提供三种stream流（广播流broadcast、聚合流gather和重分布流redistribute）实现数据在DN间的流动；4）DN将结果集返回给CN进行汇总；5）CN将汇总的结果返回给业务应用。分布式查询示意让我们展开看一下节点间的数据交换。比如某条SQL的执行逻辑如下图所示：SQL执行逻辑以两个DN为例， 在执行过程中，DN会按照redistribute键将数据发送到对应的节点。Redistribute算子接收到C/D两表join的数据之后，根据重分布键计算将数据发给DN1还是DN2，Redistribute Collector收集到重分布之后的数据之后发给上层的Join算子再做Join计算。CN、DN间的数据流动另外，GaussDB的优化器会根据统计信息选取针对当前SQL性能最优的Stream流算子完成CN、DN间的数据流动。2. 全并行架构GaussDB采用全并行架构，从MPP节点并行、SMP线程并行、到SIMD指令并行，到LLVM CodeGen技术，全面挖掘系统计算资源的潜力，提升查询性能。高可用1. GaussDB重做日志重做日志在如下场景可以发挥作用，提升系统的可用性1）当数据库发生故障，如宕机，可以通过重做日志文件恢复数据。2）HA架构下，主备通过重做日志文件进行数据同步。3）备份恢复时，通过归档重做日志文件实现PITR。GaussDB使用WAL (Write Ahead Log) 机制实现重做日志，在提升可用性的同时兼顾性能，即在数据修改时遵循 no-force-at-commit 策略，在提交时并不强制写。为了保证数据在数据库发生故障时可以恢复，通过Redo 机制，用连续的、顺序的日志条目的写出将随机的、分散的数据块的写出推延，这个推延使得数据的写出可以获得批量效应的性能提升。2. 分布式部署GaussDB支持多种高可用部署形态，保证系统的稳定性和可靠性。下面我们看两个典型案例。1）两地三中心。同城有两个双活数据中心，两个数据中心同时承载业务，异地一个容灾数据中心；同城可实现节点级、AZ级、数据中心级等故障高可用，同时提供跨城的异地容灾能力。GaussDB两地三中心高可用部署2）同城3AZ高可用+异地容灾。同城采用逻辑3AZ、3副本部署，异地采用单AZ、3副本部署，提供了同城抵御节点级故障和AZ级故障的能力，跨城的Region级容灾的能力。GaussDB同城3AZ高可用+异地容灾分布式数据库技术的发展方向基于新需求、新场景、以及全池化架构、新网络和大模型等新技术的出现，我们认为分布式数据库技术主要向以下六个方向发展。分布式数据库技术的发展方向高可用能力的持续提升高可用是目前大多数金融政企客户首要关注的问题，特别是对于多地、多中心容灾有要求的客户。针对这样的客户，华为云GaussDB已经提供了多种解决方案，如支持同城双活、异地容灾、两地三中心的解决方案，支持同城双活强同步的解决方案，支持异步数据复制、多地多活的高可用解决方案。面向未来，分布式数据库将具备真正全球部署能力的多活架构。软硬件深度协同硬件和软件两者之间相辅相成，互相促进。利用新型硬件（GPU、FPGA、高速网络）和华为在芯片、服务器、存储、网络、操作系统、数据库的全栈软硬件能力，提升性能和高可用能力。首先，数据库的持久化逻辑，深度整合到了计算与存储分离的技术底座中，分布式数据库可以获得在容量、弹性、扩展性方面的巨大提升，同时能提供给客户一致的体验。其次，从计算节点卸载下推到存储中，特别是对一些复杂的查询处理，同时叠加并行处理能力，使得这些计算逻辑能充分利用下面整个存储池的能力，同时最关键的是能做到对业务透明。最后，就是高性能。高性能的实现除了I/O聚合之外，单条交易的本质就是网络的时延和处理的时延。所以，网络对于分布式数据库的时延（性能）影响是巨大的。总而言之，软硬协同带给我们的不仅仅是性能扩展方面的优势，更是可以通过软硬协同打造真正企业级的可靠性。企业级混合负载 （HTAP）近年来企业级混合负载（HTAP）的兴起，旨在打破事务处理（TP）和分析（AP）之间的壁垒。分布式数据库都应具备混合负载能力，即在支持高并发、事务性请求的同时，对分析型的复杂查询提供了良好的支持，从而大幅度降低成本，同时提高企业决策的效率。HTAP架构的核心技术：第一，透明路由。通过自动选择行存引擎、列存引擎以及行列组合，提供查询的准确性和实时性，增加客户的易用性，提升HTAP产品的商用价值。第二，性能提升。TP要求的是低时延、高吞吐，而AP要求的是复杂查询的能力。常规执行优化技术包括并行执行、编译执行、向量化执行等，在这些技术的基础上进一步加速复杂查询，支撑企业级混合负载。第三，数据新鲜度。保证数据高新鲜度、高性能，保证HTAP架构能够具备更多应对用户的能力。第四，资源隔离。用户对TP性能要求比较高，在引入实时AP的同时，不能影响TP的能力和性能，需要在资源隔离、数据新鲜度以及性能的提升方面做好权衡。云原生多主单一架构其实并不能解决今天行业碰到的所有问题，但云原生多主架构可以帮助解决两类问题：第一个，是高可用的问题，希望能基于多主架构，解决切换时业务中断的问题。第二个，是扩展性的问题，基于多主架构，融合软硬协同的进展，真正能在计算节点以下，持续提升产品的性能和弹性。数据安全可信当今世界，每个国家、组织和个人都在关注安全、合规和隐私的问题，几年前数据无保护随意获取并使用的便利不再，这也促进了技术的进步和落地。未来，全行业都会面临越来越严格的对于可信安全方面的要求。全密态是华为云数据库为了提升隐私保护能力研制的一项关键技术，全密态支持数据在整个计算过程中同样是以密文形式存在，实现了让整个敏感数据在全生命周期当中都得到保护。因此，无论数据处于何种状态，攻击者都无法获取到有效信息，从而保障了企业数据全生命周期的隐私安全。AI-Native机器学习已被广泛用于优化数据管理问题，如数据清理、数据分析、查询重写、数据库诊断等。然而，传统的机器学习算法无法解决泛化和推理问题。幸运的是，大模型（LLM）可以帮助解决这些限制，为智能化数据管理提供了很好的机会。借助AI/LLM，未来分布式数据库将朝着全流程、全链路、高效易用的智能化数据库的方向发展，在数据库咨询、开发、运维等关键阶段，构建相应的自动化能力：第一，咨询阶段，提供专家式辅助，制定精细化方案。HLD助手，结合专家经验，自动生成数据库HLD；DB知识库，通过积累运维工单、答疑、文档手册等，形成数据库行业知识库；问答助手，通过提供ChatBot，实现交互式运维。第二，开发阶段，提供开发辅助，提升SQL开发效率。通过构建NL2SQL转换能力，让自然语言转换为SQL语句；同时，增强的SQL转换能力提升异构数据库间的SQL语句转换自动化率。第三，运维阶段，实现预测性维护，提升系统可靠性。智能巡检，可以构筑Schema/SQL、中间件/告警等全链路可观测可跟踪能力；智能故障处理，通过全链路感知编排，提供精准分析，快速定位故障并给出建议；SQL质量提升能力，可以快速找出问题SQL，诊断根因，提供全局分析。综上，分布式数据库性能卓越，凭借高可用、高可扩展性、高性价比等优势，已经被对数据库要求最严苛的金融行业所认可，并逐渐被应用在更广阔的领域。不过，从总体发展状态来看，目前还处于早期，但发展方向明朗，上升空间很大。参与有奖GaussTech技术专栏第一期话题讨论：对于分布式数据库的未来发展，你怎么看？1.你认为分布式是数据库未来的发展趋势吗？2.哪种架构会得到更多企业的青睐？3.分布式数据库技术又会向什么方向发展？点击链接，即可参与“GaussTech技术专栏第一期”话题讨论，就有机会获得HUAWEI mini蓝牙音箱 _绮境森林、《华为数据之道》书籍、新贵族系列中性笔、平装套芯笔记本、GaussDB字母笔、炫彩马卡龙指甲刀等好礼，快来参与吧！

欢迎来到华为云GaussTech的世界！GaussTech技术专栏是华为云GaussDB技术的集装箱，汇聚GaussDB数据库最前沿、最热门技术干货，包括技术文章、视频、直播等形式，为开发者们提供经验交流的生态圈。在这里，不管你是技术大佬，还是可爱萌新，只要踊跃互动，发表你的观点，就有机会赢礼品！快来参与吧！活动时间：3月26日~4月12日活动内容：第一期：基于《分布式数据库技术的演进和发展方向》技术文章，探讨：你认为分布式是数据库未来的发展趋势吗？哪种架构会得到更多企业的青睐？分布式数据库技术又会向什么方向发展？参与方式：方式一：在本帖下方互动评论回帖；方式二：带话题“GaussTech技术专栏”自发帖。参与流程具体操作如下：第①步：注册华为云账号 + 实名认证，点击这里。已注册并实名可跳过。第②步：设置论坛昵称，即华为云社区昵称，点我设置。已设置可跳过。第③步：开动你的小脑筋，如果是在本帖下方互动评论，请挥舞键盘吧！如果是带话题自发帖，请点我直接论坛发帖。自发帖请务必在发布文章标题前缀带上【GaussTech技术专栏】即默认参与，发帖分类选择【GaussTech】，标签要用【云数据库GaussDB】。评奖方式：1）在本帖下方互动回帖，高质量评论数量最多的前3名2）在“GaussTech技术专栏“分类里面自发帖，评论数量最多的前3名获奖名次奖品数量第一名HUAWEI mini蓝牙音箱 _绮境森林/《华为数据之道》书籍2第二名新贵族系列中性笔/平装套芯笔记本2第三名GaussDB字母笔/炫彩马卡龙指甲刀2活动规则：1. 回帖/发帖内容需要围绕本期技术文章话题，灌水、与技术无关凑数等相关的回复不计入评论数量。2. 由华为云专家评审团根据本帖/带话题自发帖下方的互动评论数量、质量等综合评选。奖品发放规则：奖项公示：4月12日左右获奖信息收集：4月15~19日奖品发放：4月25日~30日，顺丰包邮PS：如有需要，可以添加小助手微信18209232786，可以进行咨询哦！（避免错过活动公告和获奖公告等重要通知）特别说明：活动期间，作者如果有用脚本刷阅读量、注册僵尸号刷赞等严重违反社区规范的行为，直接取消所有获奖资格。礼包类礼品均为实物礼品。如某项奖品库存不足，运营同学将根据实际库存更换为同等价值的其他奖品，或者通知部分同学延期发货。获奖者不同意此规则视为放弃奖品。如您不认同以上规则，请谨慎参与本次活动，活动最终解释权归华为云数据库所有。

小项目部署服务器所在的地方，偶尔会有电路检修导致的断点，因此需要关机。当然也会碰到异常断点等导致系统重启的场景。系统重启后总是要手动去执行OpenGauss的服务，殊为不便，一直想着能在系统开机的时候，也同时启动opengauss的服务。奈何自己没有在openEuler系统配置自启动任务的经验，所以一直拖着，直到看到“霸王龙的日常”公众号的文章，和我诉求严丝合缝的匹配，于是照本宣科，依样画葫芦，唯一的差别是我的opengauss版本是5.0.0 LTS。下面是配置过程的记录，以备后查，也供朋友们参考。首先中的首先，感谢霸王龙的日常的分享，原文链接在此： 1. 在系统服务目录中创建服务脚本文件，系统服务目录的路径为：/etc/systemd/system/，命令为：vi /usr/lib/systemd/system/opengauss.service。   文件内容如下图所示，其中用户，用户组以及OpenGauss的安装路径要根据实际值修改，图中是我做实验的用户信息及相关路径，附件中是实验机器添加的服务脚本文件，配置时需参考cluster_config文件，注意不要配置错了：2. 重新加载systemd以识别新增加的服务：   systemctl daemon-reload3. 启用服务：  systemctl enable opengauss.service4. 启动服务以在启动时运行:  systemctl start opengauss.service5. 查看服务状态：  systemctl status opengauss.service6. 重启系统：reboot7. 重启后检查状态：实践证明：重启系统后OpenGauss自动启动起来了，开机自启动功能已配置好了。

 OpenGauss支持通过代价估算进行执行计划的调优，代价分为IO 代价和CPU代价，这两个代价都和处理的元组数量正相关；IO代价SeqScan：IO代价为：表数据页总数x seq_page_cost(或者default_ seq_page_cost)IndexScan:IO代价为P* random_page_cost(default_ random_page_cost);其中P是满足数据的页数量，常常通过R(表元组总数x选择率)估算，其中选择率=满足约束的记录数/总记录数，选择率可以通过前面提到的统计信息完成估算CPU代价元组处理代价：将一条磁盘数据转换为元组形式的代价；通过cpu_tuple_cost和cpu_index_tuple_cost表示对普通数据和索引数据的代价数据操作代价：对元组进行投影，或者根据约束表达式判断元组是否满足条件的代价；通过cpu_operator_cost表征。

使用mybatis-plus service.saveBatch方法调用异常，提示 Caused by: org.postgresql.util.PSQLException: [10.49.104.175:65143/10.50.191.27:30100] ERROR: bind message supplies 16 parameters, but prepared statement "" requires 32mybatis-plus版本: 3.4.3.4有没有大佬帮忙看下

华为GaussDB 200 安装Manager失败，提示shmmax值太小

datastudio版本：DataStudio_V1R3C20-linux.gtk.x86_64操作系统：麒麟操作系统当我以A用户登陆操作系统时，在终端工具中启动 DataStudio时，软件会在A用户的家目录下自动创建一个workspace文件夹，这是正常操作。在我的这个环境，我仍然使用A用户，我使用一个软件B，调用DataStudio并可以正常启动，但是在A用户的家目录下并没有创建workspace文件夹，而是在软件B的某个目录（/XXX/XXX/bin）下创建的。这样存在一个问题，当用户C登陆操作系统，也使用软件B，调用DataStudio，还是在软件B的某个目录下创建workspace文件夹，这样就造成了某些文件冲突，于是提示不能打开两个DataStudio窗口。问题1：DataStudio创建workspace文件夹时，是如何确定在哪个目录下创建的？有没有办法解决不同用户创建workspace的目录不同。问题2：目前主要的问题是在使用软件B调用DataStudio时，不同的用户也不能打开打二个DataStudio窗口，有没有办法解除DataStudio打开窗口数量的限制。

在麒麟操作系统是运行报错，用使用具有root权限的账号是可以运行的，但是创建的普通账号就是报错，请问普通账号是需要什么权限呢?datastudio版本：DataStudio_V1R3C20-linux.gtk.x86_64日志文件

GaussDB数据库的索引管理目录一、引言二、GaussDB数据库中的索引基本概念2.1 什么是GaussDB索引？2.2 GaussDB索引的作用三、GaussDB支持的索引类型3.1 B-Tree索引3.2 GIN索引3.3 GiST索引3.4 SP-GiST索引四、创建和管理GaussDB索引4.1 创建索引4.2 删除索引4.3 索引的优化和性能考虑五、GaussDB索引的使用注意事项5.1 维护成本5.2 索引选择和优化六、GaussDB索引最佳实践一、引言GaussDB数据库是华为公司倾力打造的自研企业级分布式关系型数据库，索引的设计和管理对于提高查询性能至关重要。下面将通过实际例子深入研究GaussDB数据库的索引管理。二、GaussDB数据库中的索引基本概念2.1 什么是GaussDB索引？GaussDB索引是一种数据结构，用于加速对表中数据的检索和查询。比如，在一个巨大的客户订单表中，可以通过对订单号列创建索引，加速根据订单号查询订单信息的速度。2.2 GaussDB索引的作用GaussDB索引的主要作用是优化查询性能，减少数据检索的开销。通过使用不同类型的索引，GaussDB能够在各种查询场景下提供高效的数据定位和访问。三、GaussDB支持的索引类型3.1 B-Tree索引B-Tree索引是一种平衡树,由根节点、内部节点和叶子节点组成。根节点和内部节点存储键值和指向子节点的指针,叶子节点存储实际的数据。适用场景： 适用于单一值的列，例如整数、字符串等。结构： B-Tree（平衡树）是一种有序树，每个节点包含多个键，并且子节点的键值范围是确定的。优势： 高效支持范围查询、等值查询和排序操作。示例： 在用户表中，通过用户ID列创建B-Tree索引，可以加速按用户ID查询的速度。3.2 GIN索引GIN索引是一种倒排索引,适用于存储和查找由多个键值组成的复合值的数据。它由一个元数据根节点、一个初始条目列表(entry list)和多个从属数据区(pending data pages)组成适用场景： 适用于包含多个数值或文本值的列，例如标签、数组等。结构： Generalized Inverted Index（广义反向索引），可用于加速包含多个项的列的查询。优势： 高效支持包含和排除多个值的查询。示例： 在文章表中，通过对标签列创建GIN索引，可以加速检索包含特定标签的文章。3.3 GiST索引GiST索引是一种平衡树索引,类似于B-Tree索引,但它支持各种各样的数据类型和查询方式。GiST索引由根节点、内部节点和叶子节点组成。每个节点包含一个或多个条目,每个条目由一个键和一些属性组成。适用场景： 适用于各种数据类型，尤其是用于高维数据和非标量数据类型的查询。结构： Generalized Search Tree（广义搜索树），适用于支持多种查询操作。优势： 高效支持范围查询、相似度查询和一些特殊数据类型的查询。示例： 在地理信息系统中，通过GiST索引加速空间数据的查询，例如查询地理位置范围内的数据。3.4 SP-GiST索引SP-GiST索引是GiST索引的一个变体,增加了"空间分区"的特性。SP-GiST索引同样由根节点、内部节点和叶子节点组成。每个内部节点都包含子节点范围的元组描述,叶节点存储实际数据。SP-GiST适用于二维空间数据等。适用场景： 专门用于处理空间数据，提供对复杂空间数据的高效查询支持。结构： Space-Partitioned Generalized Search Tree（空间划分广义搜索树）。优势： 高效支持空间数据的范围查询、相交查询等。示例： 在包含城市坐标的表中，通过创建SP-GiST索引可以加速根据地理位置范围查询城市的速度。四、创建和管理GaussDB索引4.1 创建索引在GaussDB中，可以使用以下SQL语句创建索引：-- 创建B-Tree索引CREATE INDEX btree_index ON user_table USING btree(user_id);-- 创建GIN索引CREATE INDEX gin_index ON article_table USING GIN(tags);-- 创建GiST索引CREATE INDEX gist_index ON spatial_data_table USING GiST(geometry_column);-- 创建SP-GiST索引CREATE INDEX sp_gist_index ON city_table USING SP-GiST(geo_location);4.2 删除索引通过以下SQL语句可以在GaussDB中删除索引：-- 删除索引DROP INDEX btree_index;4.3 索引的优化和性能考虑在创建索引时，需要考虑查询的模式、数据分布和表的大小。例如，对于一个日志表，可能只在时间戳列上创建定期维护的B-Tree索引，以加速按时间范围查询的性能。示例：场景描述假设有一个订单管理系统，其中有一个庞大的订单表（order_table），记录了每个订单的详细信息，包括订单号、客户ID、商品ID、订单金额等。在这个场景下，我们希望优化订单表的查询性能，特别是按照客户ID查询该客户的所有订单记录。创建初始索引首先，我们为订单表的客户ID列创建一个初始的B-Tree索引：-- 创建初始B-Tree索引CREATE INDEX idx_customer_id ON order_table USING btree(customer_id);查询性能分析通过常规查询分析，我们发现在按照客户ID查询订单时，查询性能不如预期。这可能是因为订单表的数据分布较广，B-Tree索引在这种情况下的性能有限。优化索引为了优化索引性能，我们决定尝试使用GIN索引，以适应多值的情况。我们将客户ID列的值转化为数组，然后使用GIN索引：-- 创建GIN索引CREATE INDEX idx_customer_id_gin ON order_table USING GIN(ARRAY[customer_id]);再次查询性能分析通过再次进行客户ID查询，我们发现使用GIN索引后的性能有了明显提升。GIN索引更适用于包含多个客户ID的情况，通过将值存储在数组中，可以更有效地支持这种查询模式。优化结果通过优化索引，我们成功提高了按照客户ID查询订单的性能。然而，需要注意的是，索引的优化是一个动态过程，需要根据实际查询模式和数据分布进行调整。定期监测和评估索引的性能是数据库维护的一部分，以确保系统保持高性能状态。五、GaussDB索引的使用注意事项5.1 维护成本在GaussDB中，索引的维护成本是需要考虑的因素之一。频繁的插入、更新和删除操作可能导致索引的重新构建，影响系统性能。5.2 索引选择和优化过多或不必要的索引可能导致性能下降，因此在设计数据库时，需要仔细选择哪些列需要索引，并根据查询需求进行优化。六、GaussDB索引实践在实际应用中，理解业务需求、数据分布和查询模式是制定索引最佳实践的关键。通过合理配置索引，可以在GaussDB数据库中实现高效、稳定的查询性能。总体而言，深入理解GaussDB数据库索引的原理和使用方法，结合实际业务需求进行灵活配置，将有助于建立高性能、可维护的数据库系统。作者：hhh1218

GaussDB 分布式版可以使用postgis插件吗 目前支持的版本是什么？还是对于地理数据有其他的支持方式？

作者：酷哥一、前言GaussDB是一款高性能、高可用的分布式数据库，广泛应用于各类行业和场景。在GaussDB中，锁是实现并发控制的关键机制之一，用于协调多个事务之间的数据访问，确保数据的一致性和完整性。本文将围绕GaussDB数据库的LOCK TABLE 做一简单介绍。二、GaussDB数据库的锁GaussDB提供了多种锁模式用于控制对表中数据的并发访问。这些模式可以用在MVCC（多版本并发控制）无法给出期望行为的场合。同样，大多数GaussDB命令自动施加恰当的锁，以保证被引用的表在命令的执行过程中不会以一种不兼容的方式被删除或者修改。比如，在存在其他并发操作的时候，ALTER TABLE是不能在同一个表上执行的。1、GaussDB中的LOCK TABLELOCK TABLE获取表级锁。如果需要保持数据库数据的一致性，可以使用LOCK TABLE来阻止其他用户修改表。例如，一个应用需要保证表中的数据在事务的运行过程中不被修改。为实现这个目的，则可以对表进行锁定，这样将防止数据不被并发修改。LOCK TABLE只在一个事务块的内部有用，在事务结束时就会被释放。1）语法格式LOCK [ TABLE ] name IN {ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE} MODE2）参数说明1）name：要锁定的表的名称。2）锁的模式：ACCESS SHARE：只读取表而不修改。所有对表进行读取而不修改的SQL语句都会自动请求这种锁。ROW SHARE：允许对表进行并发读取，禁止对表进行其他操作。SELECT FOR UPDATE和SELECT FOR SHARE命令会自动在目标表上请求ROW SHARE锁（且所有被引用但不是FOR SHARE/FOR UPDATE的其他表上，还会自动加上ACCESS SHARE锁）。对于分区表，SELECT FOR SHARE操作还会在DN上获取partition对象的ROW EXCLUSIVE锁进行并发控制。ROW EXCLUSIVE：与ROW SHARE锁相同，ROW EXCLUSIVE允许并发读取表，但是禁止修改表中数据。UPDATE，DELETE，INSERT命令会自动在目标表上请求这个锁（且所有被引用的其他表上还会自动加上的ACCESS SHARE锁）。通常情况下，所有会修改表数据的命令都会请求表的ROW EXCLUSIVE锁。SHARE UPDATE EXCLUSIVE：保护一个表的模式不被并发修改，以及禁止在目标表上执行垃圾回收命令（VACUUM）。VACUUM（不带FULL选项）、ANALYZE、CREATE INDEX CONCURRENTLY命令会自动请求这样的锁。SHARE：允许并发的查询，但是禁止对表进行修改。CREATE INDEX（不带CONCURRENTLY）语句会自动请求这种锁。EXCLUSIVE:允许对目标表进行并发查询，但是禁止任何其他操作。这个模式只允许并发加ACCESS SHARE锁，也就是说，只有对表的读动作可以和持有这个锁模式的事务并发执行。任何SQL语句都不会在用户表上自动请求这个锁模式。然而在某些操作的时候，会在某些系统表上请求它。SHARE ROW EXCLUSIVE:禁止对表进行任何的并发修改，而且是独占锁，因此一个会话中只能获取一次。任何SQL语句都不会自动请求这个锁模式。ACCESS EXCLUSIVE:保证其所有者（事务）是可以访问该表的唯一事务。ALTER TABLE，DROP TABLE，TRUNCATE，REINDEX，CLUSTER，VACUUM FULL命令会自动请求这种锁。在LOCK TABLE命令没有明确声明需要的锁模式时，它是缺省锁模式。2、示例一：ACCESS EXCLUSIVE 模式--创建测试表DROP TABLE IF EXISTS omm2.company;CREATE TABLE omm2.company(id int4 PRIMARY key NOT NULL,name varchar(10) NOT NULL,age int4 NOT NULL,address varchar(20) NOT NULL,salary float4 NOT NULL);--初始化数据INSERT INTO omm2.company VALUES (1, 'Paul', 32, 'California', 20000);INSERT INTO omm2.company VALUES (2, 'Allen', 25, 'Texas', 15000);INSERT INTO omm2.company VALUES (3, 'Teddy', 23, 'Norway', 20000);INSERT INTO omm2.company VALUES (4, 'ZhangSan', 30, 'BeiJing', 30000);--启动一个事务START TRANSACTION;LOCK TABLE omm2.company IN ACCESS EXCLUSIVE MODE;DELETE FROM omm2.company WHERE name ='Allen';COMMIT;解析：“START TRANSACTION;”：启动一个新的事务。在数据库中，事务是一组一起执行的SQL语句，要么全部成功，要么全部失败。这确保了数据的一致性。“LOCK TABLE omm2.company IN ACCESS EXCLUSIVE MODE;”：对omm2.company表进行了排他性锁定。在此模式下，其他会话不能对表进行读写操作，直到这个事务结束。这样可以防止在删除操作过程中其他事务对表产生干扰。“DELETE FROM omm2.company WHERE name ='Allen'; ”：从omm2.company表中删除了所有名为'Allen'的记录。“COMMIT;”：这行代码提交了前面的事务。在事务中执行的任何更改（在本例中是删除操作）在提交后才会永久保存在数据库中。总的来说，这段代码删除了名为'Allen'的所有记录，并确保这个操作在提交之前不会被其他事务干扰。3、示例二：SHARE ROW EXCLUSIVE 模式--复用示例一的测试表CREATE TABLE omm2.company1 AS TABLE omm2.company;--启动一个事务START TRANSACTION;LOCK TABLE omm2.company1 IN SHARE ROW EXCLUSIVE MODE;DELETE FROM omm2.company1 WHERE name ='Allen';COMMIT;解析：“CREATE TABLE omm2.company1 AS TABLE omm2.company;”：创建了一个新的表omm2.company1，其结构复制自已有的表omm2.company。这种操作通常用于创建表的副本，或者为某个操作创建一个临时的、与原表结构相同的新表。“START TRANSACTION; ”：启动一个新的事务。在数据库中，事务是一组一起执行的SQL语句，要么全部成功，要么全部失败，这可以确保数据的一致性。“LOCK TABLE omm2.company1 IN SHARE ROW EXCLUSIVE MODE; ”：对表omm2.company1进行了排他性锁定。在这种模式下，其他会话不能对表进行读写操作，直到这个事务结束，这样可以防止在删除操作过程中其他事务对表产生干扰。“DELETE FROM omm2.company1 WHERE name ='Allen';”：从表omm1.company1中删除了所有名为'Allen'的记录。“COMMIT;”:提交前面的事务。在事务中执行的任何更改（在本例中是删除操作）在提交后才会永久保存在数据库中。三、小结GaussDB数据库的锁机制是其重要的组成部分，用于支持并发控制和事务隔离。GaussDB实现了不同级别的事务隔离和并发控制，满足了不同场景下的需求。当然了，使用GaussDB数据库时也需要注意一些问题，如锁的管理和数据库的规划等。合理的锁管理和数据库规划能够提高系统的性能和可用性，反之则可能导致数据一致性问题或者系统故障。——结束

作者：白鳝的洞穴D-SMART高斯专版已经开发了几个月了，目前主要技术问题都已经解决，也能够初步看到大概的面貌了。有朋友问我，Gaussdb不已经有了TPOPS了，为什么你们还要开发D-SMART高斯专版呢？实际上TPOPS和D-SMART虽然都可以用于Gaussdb的运维监控，不过其分工还是十分明显的。TPOPS是华为GaussDB自带的运维工具，从数据库部署开始就一直可以使用。TPOPS+DBMind也具有一定的运维分析能力，不过这些功能都是基于传统的运维管理理念的。D-SMART是一个运维知识自动化系统，其目的是实现更加数字化的运维监控、故障预警、根因分析（RCA）、自动化巡检等，今后还会依托D-SMART的数据构建线上的SAAS生态。D-SMART是一个十分强大的知识自动化平台，可以不断沉淀用户自己的运维知识，包括各种健康模型、故障模型和诊断工具。这些都是TPOPS不具备的功能，因此D-SMART可以作为TPOPS的有效补充。另外一方面，D-SMART高斯专版会支持所有的高斯生态产品，包含华为GaussDB集中式/分布式，openGauss、南大通用GBASE 8C、海量Vastbase、神通数据库、磐维、MogDB等。D-SMART是从运维视角来看待GaussDB的。从入口上，D-SMART与TPOPS的视角就完全不同。使用过D-SMART的用户送GaussDB专版没有任何学习成本，可以很轻松的通过工具去对GaussDB集群进行分析。配套的D-SMART V2.6版本提供了一个图形化的集群拓扑。让习惯于图形界面的DBA看起来更加舒适。    在集群拓扑上可以点击CN/DN节点进行下钻。在D-SMART中，每个有分布式CN/DN节点和集中式DN节点三种子类型，目前我们把它们作为PG兼容子类来看待。因为GaussDB和openGauss都有大量的监控视图与PG兼容，可以复用部分PG的工具，因此我们没有给openGauss/GaussDB节点独立的数据库类别。虽然如此，GaussDB、openGauss和PostgreSQL三种数据库子类在可观测性视图方面已经有了很多差异。作为可观测性能力而言，GaussDB>openGauss >PostgreSQL。更强的可观测性意味着更为强大的自动化/智能化分析能力。故障模型告警和诊断工具依然沿用D-SMART传统的模式，目前工具的开发还在持续进行中，不过基于运维知识图谱的通用分析工具已经是可用的了。智能指标分析与告警时序分析、等待事件智能分析等工具已经可以使用了。基于GaussDB强大的可观测能力，目前故障模型的梳理工作也进展顺利，和一些其他的国产数据库不同的是，我们明显感到能够梳理出来的故障模型数量太多了，刚刚发布的时候可能就会有上百个故障模型，比我们2018年发布Oracle版本时的故障模式数量还要多出不少。    故障模型是对数据库运维经验的一种总结，能够构建其丰富的故障模型对于承载大型关键应用系统十分关键。而故障模型的构建依赖于强大的可观测能力，以及将数据库状态指标化的能力，再辅以专家的经验才能完成。这种能力可以让一些原本需要专家才能发现的问题实现自动化发现与自动化预警。目前我们针对GaussDB的故障模型涉及组件健康状态、容量、高可用、并发、负载、性能、资源、实例健康、任务等维度。实际上这是针对GaussDB集群的故障模型，针对每个组件，比如CN/DN，以及承载CN/DN的服务器也都会设计故障模型。这样才能保证整个数据库运行环境出现问题，都能够被提前发现。分布式数据库的运维工具开发起来比较麻烦，在前面的开发过程中我们也遇到了很多问题，比如DN节点的切换后，系统能否立即无缝跟踪到这个变化，如果复制组中存在硬件配置上的不同，可能会影响模型的评估，如何能够在每隔2-3分钟的评估中避开数据错误，这些都在不断的完善中。这个月底希望有一个评估版本可以完成，届时也希望生产环境中有GaussDB的朋友能一起合作来验证工具。有兴趣的朋友可以关注“DBAIOPS社区”公众号给我们留言。

GaussDB for mysql支不支持国产化适配，支不支持信创改造

本文很长，里面包含了部署云管平台、安装Gaussdb 260版本遇到的一些问题以及解决的方法，建议先收藏再阅读。部署Gaussdb 260版本需要先部署云管工具，和部署200版本需要安装TPOPS类似，260也需提前安装好管理平台。之前介绍过通过TPOPS安装guassdb，后面有位朋友提醒TPOPS已经被华为弃用了。后来从华为工程师那里得知确实如此，本文就重新介绍通过云数据库GaussDB管理平台来部署GaussDB，官方有部署文档也比较详细，但是有些细节没有说得很清楚，导致部署的时候很是艰难。一、介绍(来自官方手册)云数据库GaussDB管理平台是基于HCS DBS(Database Service)服务孵化的一款可即开即用、稳定可靠、按需扩展、便捷管理的数据库运维管理平台。云数据库GaussDB管理平台不依赖华为云Stack云底座，与华为云Stack标准云部署形成场景互补，可获得与华为云Stack云上一致的用户体验。云数据库GaussDB管理平台当前仅支持HA模式部署，即在三个节点上安装云数据库GaussDB管理平台。HA模式具有高可靠模式；支持跨机房、跨地域部署；可有效避免微服务单点故障、单机故障、单机房故障等异常情况，保证业务稳定运行。注：通过查看安装脚本，管理平台是支持单节点部署二、要求通信X86我简单尝试后放弃了，还是用了Kylin。实验环境[root@test181 ~]# uname -aLinux test181 4.19.90-23.8.v2101.ky10.x86_64 #1 SMP Mon May 17 17:08:34 CST 2021 x86_64 x86_64 x86_64 GNU/Linux三、准备工具、安装包• 安装包准备需要和华为申请安装包和license，乱七八糟加起来有30G。• 操作系统自己想办法四、安装前准备工作1、java环境官方并没有对java版本有要求，建议使用1.8[root@test181 ~]#  java -versionopenjdk version "1.8.0_342"OpenJDK Runtime Environment BiSheng (build 1.8.0_342-b11)OpenJDK 64-Bit Server VM BiSheng (build 25.342-b11, mixed mode)2、expect也没有版本要求，直接yum安装即可yum install expect [root@test181 ~]# expect -versionexpect version 5.45.43、openssl默认都有，一般不用单独安装，如果没有通过操作系统镜像安装即可4、tar默认都有，一般不用单独安装[root@test181 ~]# tar --versiontar (GNU tar) 1.30Copyright (C) 2017 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.Written by John Gilmore and Jay Fenlason.5、dos2unix默认都有，一般不用单独安装，否则通过yum install tar -y安装即可。[root@test181 ~]# dos2unix -Vdos2unix 7.4.0 (2017-10-10)With Unicode UTF-16 support.With native language support.With support to preserve the user and group ownership of files.LOCALEDIR: /usr/share/localehttp://waterlan.home.xs4all.nl/dos2unix.htm6、libcgroup默认都有，一般不用单独安装，否则通过yum install libcgroup -y安装即可。[root@test181 ~]# rpm -qa | grep libcgrouplibcgroup-0.41-23.ky10.x86_647、字符集是en_US.UTF-8如果不是，可通过/etc/locale.conf修改[root@test181 ~]# cat /etc/locale.conf LANG="en_US.UTF-8"[root@test181 ~]# source /etc/locale.conf 8、ifconfig默认都有，一般不用单独安装，否则通过yum install ifconfig -y安装即可。9、关闭GSSAPI认证a. 使用vi打开/etc/ssh/sshd_config。vi etc/ssh/sshd_configb. 修改GSSAPIAuthentication的值为no。GSSAPIAuthentication noc. 执行**:wq**保存并退出。d. 重启sshd服务systemctl restart sshd10、python版本必须要是3.7.4或者3.7.9，Kylin V10默认就是3.7.9，所以不需要单独安装Python。[root@test181 ~]# python3 -VPython 3.7.911、关闭防火墙systemctl stop firwalldsystemctl disable firwalld12、关闭selinux1. 使用vim打开config文件。 vim etc/selinux/config1. 修改“SELINUX”的值“permissive”，执行**:wq!**保存并退出修改。 SELINUX=permissive3.重启系统生效reboot注：确保所有节点的所有条件都满足，再进行下一步。否则出现错误，不好排查。五、正式开始所有准备工作就绪，就可以开始了。不管是单节点部署，还是多节点，只需要在其中一个节点操作。1、创建目录/data[root@test181 ~]# mkdir /data2、上传软件包并解压将 DBS-docker-service_2.23.07.260.2023122720369783_all.tar.gz 上传到目录/datatar zxvf DBS-docker-service_2.23.07.260.2023122720369783_all.tar.gz3、上传其他所需安装包到/data/docker-service/pkgs目录下差不多二十来个吧，就问你怕不怕。[root@test181 ~]# ll /data/docker-service/pkgs/total 19806060-rw-r--r-- 1 root root  168679104 Feb 19 15:17 DBS-auth_2.23.07.260.20231221153212.70313242_all.tar.gz-rw-r--r-- 1 root root  234169918 Feb 19 15:18 DBS-common-service_2.23.07.260.202312261914.70760277_all.tar.gz-rw-r--r-- 1 root root  126033339 Feb 19 15:18 DBS-DBMind-Manual_2.23.07.210.202310251420.tar.gz-rw-r--r-- 1 root root   36403487 Feb 19 15:19 DBS-GaussDB-agent_2.23.07.260.70848390_all.tar.gz-rw-r--r-- 1 root root  238567896 Feb 19 15:22 DBS-GaussDB-backupmanager_2.23.07.260.20231223170622_all.tar.gz-rw-r--r-- 1 root root   60700834 Feb 19 15:22 DBS-gaussdb-console_2.23.07.260.70429885_all.tar.gz-rw-r--r-- 1 root root  148811695 Feb 19 15:22 DBS-GaussDBConsole-Server_2.23.07.260.20231226225243.70778480.tar.gz-rw-r--r-- 1 root root  579171792 Feb 19 15:22 DBS-GaussDB-driver.tar.gz-rw-r--r-- 1 root root     165402 Feb 19 15:31 DBS-GaussDB-feature-data_2.23.07.260.20231211141333.69332951_all.tar.gz-rw-r--r-- 1 root root  249134570 Feb 19 15:31 DBS-GaussDB-instancemanager_2.23.07.260.20231226234230_all.tar.gz-rw-r--r-- 1 root root 2156775557 Feb 19 15:31 DBS-GaussDB-Kernel_2.23.07.260.796044464831616.tar.gz-rw-r--r-- 1 root root 1546448988 Feb 19 15:33 DBS-GaussDB-Kylin-Kernel_2.23.07.260.796044464831616.tar.gz-rw-r--r-- 1 root root 6313764593 Feb 19 16:03 DBS-GaussDB-Manual_2.23.07.260.796048944315456.tar.gz-rw-r--r-- 1 root root  212023674 Feb 19 16:12 DBS-GaussDB-open-api_2.23.07.260.20231226232138.70780102_all.tar.gz-rw-r--r-- 1 root root  737048524 Feb 19 16:58 DBS-GaussDB-Server_2.23.07.260.20231228180356.70962999.tar.gz-rw-r--r-- 1 root root 1260229698 Feb 19 17:05 DBS_GaussDB_X86_2R10_BMS_2.23.01.200-20230331112613.tar.gz-rw-r--r-- 1 root root 1204521424 Feb 19 17:05 DBS_GaussDB_X86_2R10_ECS_2.23.01.200-20230116162315.tar.gz-rw-r--r-- 1 root root 1902708824 Feb 19 16:06 DBS_GaussDB_X86_HCE_ECS_2.23.07.200-20230914195612.tar.gz-rw-r--r-- 1 root root  200690701 Feb 19 16:12 DBS-luban_2.23.07.260.20231226220440.70776246_all.tar.gz-rw-r--r-- 1 root root 1175543251 Feb 19 17:01 DBS-MetaDB_Kylin_Centralized_503.1.0.SPC1700.B003.tar.gz-rw-r--r-- 1 root root  229973638 Feb 19 16:11 DBS-monitor-service_2.23.07.260.202312211511.70310489_all.tar.gz-rw-r--r-- 1 root root  256829824 Feb 19 16:39 DBS-OM-Agent-Manual_2.23.07.260.796048944315456.tar.gz-rw-r--r-- 1 root root  184162486 Feb 19 16:11 DBS-ots_2.23.07.260.20231222133123.70415568_all.tar.gz-rw-r--r-- 1 root root    3433930 Feb 19 16:12 DBS-platform-data_2.23.07.260.20231228220057.70981727_all.tar.gz-rw-r--r-- 1 root root  214016922 Feb 19 16:11 DBS-rds-ha-admin_2.23.07.260.202312112053.69373866_all.tar.gz-rw-r--r-- 1 root root  196126792 Feb 19 16:12 DBS-resource-manager_2.23.07.260.202311271720.68102008_all.tar.gz-rw-r--r-- 1 root root       7257 Feb 19 17:08 DBS-tools_2.23.07.200_all.tar.gz-rw-r--r-- 1 root root  170949800 Feb 19 16:11 DBS-workflow_2.23.07.200.202309092109.61758876_all.tar.gz-rw-r--r-- 1 root root  263046780 Feb 19 16:11 GaussDB_image_patch_2.23.07.200.tar.gz-rw-r--r-- 1 root root  211207619 Feb 19 15:16 GaussDB_OS_PATCH_2.23.07.260.20231226095856.zip注：需要保证包的唯一，同一个微服务或组件的包只能上传一个4、修改配置文件修改配置文件/data/docker-service/config/user_edit_file.conf ，单节点配置如下：[root@test181 ~]# cat /data/docker-service/config/user_edit_file.conf [user_edit]ssh_port = 22gauss_path = /opt/gaussdbnode1_ip = 60.60.60.181node2_ip = node3_ip = influxdb_install_ip1 = 60.60.60.181influxdb_install_ip2 = sftp_install_ip1 = 60.60.60.181sftp_install_ip2 = main_path = /opt/cloudnode1_ip2 = 60.60.60.181node2_ip2 = node3_ip2 = log_path = /opt/cloud/logssftp_path = /opt/sftphomeinflux_path = /opt/cloud/influxdbdocker_path = /opt/dockerbackup_path = /opt/backupservice_group_id = 1010service_user_id = 1010uninstall_all = nouse_cgroup = no如果是多节点，则配置好其他几个IP参数即可。配置文件参数说明[user_edit] ssh_port = 22    # 节点之间登录的ssh端口号 gauss_path = /opt/gaussdb    # 元数据库安装目录 node1_ip = 192.168.0.1    # 节点1本机IP地址（执行节点IP地址） node2_ip = 192.168.0.2    # 节点2本机IP地址  node3_ip = 192.168.0.3    # 节点3本机IP地址 influxdb_install_ip1 = 192.168.0.1    # influxdb安装节点1 influxdb_install_ip2 = 192.168.0.2    # influxdb安装节点2 sftp_install_ip1 = 192.168.0.1    # sftp安装节点1 sftp_install_ip2 = 192.168.0.2    # sftp安装节点2 main_path = /opt/cloud    # 微服务运行目录， 目录可自定义，仅支持自定义第一级目录，二级目录cloud不允许修改  node1_ip2 = 100.95.0.1    # 节点1可以和GaussDB实例地址通信的IP地址（执行节点可以和GaussDB实例通信的IP地址，要求可以和GaussDB实例ssh通以及ping通） node2_ip2 = 100.95.0.2    # 节点2可以和GaussDB实例地址通信的IP地址（要求可以和GaussDB实例ssh通以及ping通） node3_ip2 = 100.95.0.3    # 节点3可以和GaussDB实例通信的IP地址（要求可以和GaussDB实例ssh通以及ping通） log_path = /opt/cloud/logs    # 日志目录， 目录可自定义，仅支持自定义第一级目录，二级目录cloud及之后目录不允许修改 sftp_path = /opt/sftphome    # sftp数据目录， 目录可自定义，仅支持自定义第一级目录，二级目录sftphome不允许修改 influx_path = /opt/cloud/influxdb    # influxdb数据目录，需要保证influxDB_install_ip1以及influxDB_install_ip2节点influxd的父目录都有influxdb用户的可执行权限(如遍历父目录，对目录执行chmod a+x /directory_1/directory_2)，目录可自定义，仅支持自定义第一级目录，二级目录cloud及之后目录不允许修改 docker_path = /opt/docker    # docker数据目录， 目录可自定义，仅支持自定义第一级目录，二级目录cloud不允许修改，如果用户环境已安装docker，则以用户配置为准，该项配置不生效。 backup_path = /opt/backup    # 备份数据目录， 目录可自定义，仅支持自定义第一级目录，二级目录cloud不允许修改 service_group_id = 1010    # service用户id（需未被使用） service_user_id = 1010    # service用户组id（需未被使用） uninstall_all = no    #  卸载时需将参数值配置成yes,默认为no5、创建目录通过脚本自动创建[root@test181 ~]# sh /data/docker-service/action/mainAction/create_install_dir.sh 'root密码'6、开始安装管理平台登录管理平台https://60.60.60.181:8443/gaussdb/#/login管理平台的默认用户名、密码：admin/Gauss_234[root@test181 ~]# cd /data/docker-service[root@test181 docker-service]# sh appctl.sh install请输入root用户密码:start check host: 60.60.60.181 root passwordcheck host: 60.60.60.181 root password success[WARNING]The non-standard single-node deployment mode does not support the high reliability mode and has the risk of single point failure. Are you sure you want to continue the installation? (y/n):y    --单节点部署，提示高可用风险。输入y确认。。。漫长等待，看机器性能，基本上1小时打底。======== 60.60.60.181: gaussdb_service ========   auth                    |  complete          gaussdb-console         |  complete          luban                   |  complete          ots                     |  complete          GaussDB-open-api        |  complete          GaussDB-instancemanager |  complete          GaussDB-backupmanager   |  complete         install successful  Upload sftp packages successful for 60.60.60.181请登录云数据库GaussDB管理平台查看安装包上传任务状态出现以上提示信息，就表示安装成功了。根据我的经验，第一次就安装成功的几率不大。六、申请license点击《平台管理》中的《License管理》，许可容量，点击申请试用，输入confirm确认即可。七、接入主机在部署GuassDB之前，需要将目标主机接入到管理平台中。主机硬件要求最低：8C 64G，低于这个没法安装。1、目标主机要求1.1、expect也没有版本要求，直接yum安装即可yum install expect [root@test181 ~]# expect -versionexpect version 5.45.41.2 设置时区和时间确保主机的时区和时间一模一样，否则初始化主机会报错。cp /usr/share/zoneinfo/Asia/Shanghai  /etc/localtimedate -s "2024/02/20 10:13:50"1.3 [可选]关闭swap交换内存cat /etc/fstab# /dev/mapper/klas-swap   none                    swap    defaults        0 0reboot1.4、字符集是en_US.UTF-8如果不是，可通过/etc/locale.conf修改[root@test181 ~]# cat /etc/locale.conf LANG="en_US.UTF-8"[root@test181 ~]# source /etc/locale.conf 1.5、关闭GSSAPI认证a. 使用vi打开/etc/ssh/sshd_config。vi etc/ssh/sshd_configb. 修改GSSAPIAuthentication的值为no。GSSAPIAuthentication noc. 执行**:wq**保存并退出。d. 重启sshd服务systemctl restart sshd1.6、python版本必须要是3.7.4或者3.7.9，Kylin V10默认就是3.7.9，所以不需要单独安装Python。[root@test181 ~]# python3 -VPython 3.7.91.7、关闭防火墙systemctl stop firwalldsystemctl disable firwalld1.8、关闭selinux1. 使用vim打开config文件。 vim etc/selinux/config1. 修改“SELINUX”的值“permissive”，执行**:wq!**保存并退出修改。 SELINUX=permissive3.重启系统生效reboot1.9 设置MTU建议设置为1500，默认就是1500.1.10、umask小于等于0022l 以root用户登录待添加的主机节点，执行umask命令。若回显小于等于0022，可直接添加主机；若回显大于0022，请执行以下步骤修改umask的值。a. 执行以下命令，进入bashrc文件。 vi etc/bashrcb. 在最下方增加一行，使umask的值等于0022。 umask 0022c. 单击键盘Esc，再执行**:wq!**命令保存并退出。d. 执行以下命令，使修改生效。 source etc/bashrce. 再次执行umask命令，回显等于0022表示修改成功。1.11 允许root相关操作• 主机允许root用户登录。• 主机允许ssh跳转进行scp命令拷贝安装包。• 主机允许expect命令处理ssh交互过程。步骤 2 单击需要查询主机所在的“机房别名/ID”。单击“添加主机”2、准备一块不小于300G的磁盘安装实例由程序自动组盘，除系统盘外所有磁盘作为数据盘使用，并挂载在/var/chroot子目录下。不需要对磁盘做操作，只要准备一块就可以了。并确保/var/chroot目录是不存在的，因为初始化会清空该目录。推荐使用SSD，普通磁盘也可以安装3、添加主机步骤 1 登录云数据库GaussDB管理平台。步骤 1 单击“平台管理 > 数据中心管理”，进入“数据中心管理”页面。确定后，开始执行相关初始化操作。可通过任务中心查看执行情况，如果失败可查看详细报错信息(看了也白看，基本上只能求助官方)。如果问题，初始化成功后，就可以安装数据库实例了。相关参数解释：如果添加主机报错，参考附录部分。如果解决不了，可能需要求助官方了。八、安装实例步骤 1 登录云数据库GaussDB管理平台。步骤 2 单击“安装实例”，进入“安装实例”界面。下一步单击“立即申请”，进入信息确认页，确认实例信息。创建过程比较漫长~~~实例创建成功后，用户可以在“实例管理”页面对其进行查看和管理至此，GaussDB部署已经完成！下一篇将会为大家介绍部署过程中的问题~