尊敬的各位委员： 在 2025 年 2 月 25 日，我们于北京成功举办了第一次联合例会。会议筹备期间，我们广泛收集用户需求，共梳理出 25 条需求信息。会议过程中，大家积极交流探讨，又新增了 12 条需求。经过全体与会人员的共同研讨与审慎评估，最终明确其中 11 条为高优先级需求，并针对每条高优先级需求分别指定了跟踪责任人，以确保相关工作的有效推进。 现将全量需求列表予以公布。后续，我们将每月定期发布需求进展报告，并在理事会上对需求处理情况进行跟踪回顾，保证各项工作透明、有序开展。 在此，衷心感谢各位委员对 openGauss 社区的大力支持！正因为有各位的积极参与和倾心付出，社区才得以蓬勃发展。期待未来我们继续携手共进，推动 openGauss 社区迈向新的高度 。 openGauss 社区 需求类别 需求内容 需求场景 优先级 社区情况反馈 跟踪责任人 资源池化 资源池化方案支持 需要资源池化的方案说明材料支撑 高 资源池化的使用材料可见社区官网；技术讲解材料可会后提供 陈栋 资源池化: 1. 稳定性（研发故障计划ing) 2. 文档 3. GaussDB似乎不同方案，对一下开源4. 用户遇到稳定性问题 (6.0上特性更稳定） 高 6.0.0资源池化商用版本发布，涵盖189种故障模式库，97%手动可恢复，80%可自动恢复，RAC多写方案在下次UC明确技术路径： 1.云原生开源路径探索 2.基于社区开源的参天实现多写往前演进 熊小军 高可用 对于CM软件在高可用方面进一步提升，在各种异常场景下都能恢复，比如5个节点内，本中心已经丢失2节点，结合同步策略，建议从同城中心选主。 多数据中心（AZ）场景下的容灾架构，当前AZ三个DN。当两个DN故障时，仍能优先从本AZ中选取主 高 当前支持AZ级优先级选主，需设置选主优先级 熊小军 CM丢失3节点后，如何快速从剩余2节点中找到主节点，提高用户的灾备响应能力。 多数据中心（AZ）场景下的容灾架构，当前AZ三个DN。当三个DN全部故障时，如何容灾切换到其他的AZ选取 高 如果是5节点，挂了3个，剩下2个不满足多数派，无法自动选主，需手动强起； 熊小军 双活方案支持 大概率是双集群容灾方案支持 低 社区支持通过发布订阅的方式实现异地双活；也支持双集群实现异地容灾 - 优化CM，能够支持单独切换、启停功能 高可用场景下DN级别的灵活维护能力 低 当前支持CM暂停集群管理功能，也支持对单个DN的启停切换 - 两地三中心，支持双写场景（目前社区说两地写有问题，数据一致性需要根据实际处理） 采用两地部署，两地写（逻辑复制）时能够保证数据一致性 低 当前通过发布订阅实现异地双活，提供用户自定义的冲突解决机制：当订阅端同步数据时遇到主键或唯一键冲突时，数据库通过参数配置进行报错、保留本地或者应用远端。 - 版本升级 针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。 跨大版本升级的易用性、平顺性 高 社区支持跨大版本升级，如3.0.0->6.0.0，当前社区文档版本升级路径显示不支持从3.0->6.0的升级，需要刷新 熊小军 对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。 数据库完全不停机情况下的小补丁升级 高 社区今年规划了热补丁升级能力 朱芳芳 针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。 跨大版本升级的易用性、平顺性 低 社区支持跨大版本升级，如3.0.0->6.0.0 - 对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。 数据库完全不停机情况下的小补丁升级 低 社区今年规划了热补丁升级能力 - 向量数据库 有向量化引擎要求，目前引入了Rust编写的面向向量的搜索引擎Qdrant，openGauss需要在7.0版本下DataVec能使用 大概率是openGauss的datavec对客户当前已使用的Qdrant相关功能的兼容或替换 高 当前社区7.0DataVec版本具备Qdrant完整对标/替换能力，后续单独与国能对接。 阙鸣健 内核 高并发（10k甚至2-3k）：物理机资源高（cpu等），抖动。业务使用随便. 高 大概率是issue，结合移动现网后续跟进解决 李居隆 行存压缩 民生、广州汇智 高 25年明确商用交付，当前方案开发完成，协同海量版本测试中，同时与民生对接后续落地计划 李标 WAL回放性能 高 25年已规划 阙鸣健 日志和数据库状态都只能omm用户看，我们想普通用户也能查? 不能hardcode omm 高 熊小军 兼容性 增加informix的兼容性 客户从informix迁移到openGauss，希望有更好的兼容性 低 Informix迁移社区暂无规划，目前可通过恩墨的mtk工具完成迁移 - 信创改造要求，需逐步替换国外开源数据库MySQL和PGSQL，有Oracle迁移需求，暂无实际的项目计划； 通用性国外数据库兼容性场景 低 对MySQL已支持常用语法100%兼容；Oracle通过使能伙伴完成全量语法50%兼容，今年会进一步增加兼容度；PG语法的兼容性今年暂无规划，后续通过DBV、高校合作项目补齐。 - 针对其他数据库迁移到oG，比如PG，提供语法兼容和迁移方面的规划和工具。 从pg迁移到og的兼容性、迁移工具的支持 低 PG的迁移工具已在实现中，预计630交付 - 工具 异构数据库迁移工具，目前能支持MySQL数据迁移和PGSQL迁移，其他商用数据库支持，比如达梦，Oracle等； 在企业进行数据库系统迁移或整合时，支持将数据从原有的业务数据库如MySQL、PostgreSQL、达梦或Oracle迁移至openGauss，以确保业务的连续性和数据的完整性。 低 社区已支持mysql迁移，已规划对pg的迁移；对oracle的迁移已在24年年初由南大贡献；对其他国产数据库如达梦的迁移，建议DBV伙伴来实现 - 数据库监控平台工具，目前主从监控待引入datakit工具，短信和邮箱报警正在开发，需要监控看板页面，支持运行中的sql语句级别的审计功能。 datakit工具能力 低 当前datakit不支持审计，后续规划实现 - 短信或邮件报警 ，看板监控（社区datakit这些功能已实现，待今年落地国能） 社区datakit工具在国能短信、邮件报警，看板监控场景使用 低 Datakit已支持短信和邮件通知，已提供配置服务的入口 - openGauss GCC编译工具需适配操作系统自带的GCC和依赖工具，不再独立一套编译工具 企业服务器和操作系统种类多，希望减少所需适配内容 低 不同OS的gcc版本可能不一致，待分析是否完全采用OS的 - 希望社区在AI for DB的领域，对DBmind进一步开源和推广，促进数据库更加智能化。 DBmind重点发展和推广 低 需要高斯回答 - 适配 基于信创桌面系统的数据库和客户端链接工具，需要兼容UOS； 操作系统适配 低 当前社区无规划适配UOS桌面系统 - 版本升级 针对内核升级路径，能否提供跨大版本升级，目前写的需要逐级升级，这样客户升级成本较高。 跨大版本升级的易用性、平顺性 低 社区支持跨大版本升级，如3.0.0->6.0.0 - 对于小补丁的升级，建议要支持热生效能力，减少用户的业务影响。 数据库完全不停机情况下的小补丁升级 低 社区今年规划了热补丁升级能力 - 驱动 1. 支持基于C# ADO.NET框架的数据库驱动程序实现 需要支持.Net开发语言开发项目 低 社区支持.NET，后续需要催熟、官网正式发布 - 2. 支持基于EntityFramework Core ORM框架的数据库提供程序实现 低 - PHP语言下实现连接池代理，在单个连接查询下延迟大； PHP语言下的连接池代理 低 是需要PHP驱动支持连接池代理？目前可采用PgBouncer - 分布式 需要构建分布式事务能力 能够支持分布式节点 低 目前社区暂无分布式数据库规划，可采用南大通用的分布式方案 - 其他 社区上数据库内核及周边工具较多，掌握不容易，有条件的话可以赋能 国产数据库资料相对较少，上手门槛高 低 资料优化；内核和工具直播赋能 - 优化官方手册中描述（有些GaussDB描述或特性，在openGauss中并没有，但是文档和实际环境中还是存在） 修正openGauss中不支持的特性，避免误导用户 低 资料优化 - 文档结构还需要进一步清晰，建议尽量合并成一个整体的文档（大的方面可以分为运维和开发类），通过合适的导航和搜索以及链接方式，精确定位到用户关心的问题。当前文档多而散的模式，使用上反倒不方便。 文档结构、导航希望更加合理 低 资料优化 - 进一步提高官方文档的质量，文档内容较多，部分信息冗余，部分文档解释模糊，甚至解释不准确，用户无法完全理解，上生产操作前需要反复验证。 文档内容质量提升，包括信息冗余、解释模糊、解释不准确、用户可读性差的问题。上生产操作前需要反复验证。 低 资料优化，同时建议用户遇到问题可先直接提issue反馈 - 监控：社区再完善一点. 低 视图/监控部分规划：轻量级锁跟踪、全链路跟踪、视图可视化等25年陆续交付。 - AI4DB: 移动已经在用，还挺不错（From DBA）, 训练问题：数据安全 低 DBMind使用情况和问题后续单独组织会议对齐-沈金伟 - 分区表：索引问题？不确定具体问题，线下讨论。 低 分区表性能优化（3000+分区场景，TPCC性能损耗小于30%） -