一、问题背景：delete语句执行慢，delete几千条数据，执行要用一分钟，不满足要求。DELETE FROM schema_css.t_call_record_attendee WHERE confuuid in ('xxx','xxx','xxx');表结构：    Column    |          Type           |             Modifiers              | Storage  | Stats target | Description --------------+-------------------------+------------------------------------+----------+--------------+------------- uuid            | character varying(64)   | not null                           | extended |              |  confuuid     | character varying(64)   | not null                           | extended |              |  orguuid      | character varying(128)  |                                    | extended |              |  logicid        | character varying(128)  |                                    | extended |              |  roletype      | character varying(16)   | default 'GUEST'::character varying | extended |              |  displayname  | nvarchar2(512)          |                                    | extended |              |  terminaltype | character varying(32)   |                                    | extended |              |  callnumber   | character varying(128)  |                                    | extended |              |  deptname     | nvarchar2(512)          |                                    | extended |              |  deptuuid      | character varying(128)  |                                    | extended |              |  useruuid      | character varying(128)  |                                    | extended |              |  attribute      | character varying(4096) |                                    | extended |              |  updatetime  | bigint                  | default 0                          | plain    |              |  createtime   | bigint                  |                                    | plain    |              |  deleted        | integer                 | default 0                          | plain    |              | Indexes:    "t_call_record_attendee_pkey" PRIMARY KEY, cbtree (uuid, confuuid) TABLESPACE pg_default    "i_t_call_record_attendee_confuuid" cbtree (confuuid) TABLESPACE pg_default    "i_t_call_record_attendee_logicid" cbtree (logicid) TABLESPACE pg_default    "i_t_call_record_attendee_useruuid" cbtree (useruuid) TABLESPACE pg_defaultHas OIDs: noDistribute By: HASH(confuuid)Location Nodes: ALL DATANODESOptions: orientation=column, enable_hstore_opt=true, enable_binlog=on, binlog_ttl=86400, bucketnums=16384, compression=middle, colversion=2.0, enable_delta=false, enable_hstore=true, enable_turbo_store=true二、问题定位1、无锁冲突，无性能瓶颈，执行的是delete的语句，无法打印执行计划；topsql中记录的是fqs，也没有计划。将delete转化为select语句执行：select * FROM schema_css.t_call_record_attendee WHERE confuuid in ('xxx','xxx','xxx');走FQS执行计划，执行很快；关闭fqs后，走了索引，依然很快，未出现慢的情况。关闭fqs后，打印delete的verbose计划，和select快的计划是一致的，未发现问题。由于FQS计划相当于直连DN执行，因此直连DN打印执行计划，发现也是走了索引的快的计划，性能很快，未能复现。2、根据等待视图，抓取语句堆栈如下：postgres=# select * from pgxc_thread_wait_status where query_id in (select query_id from pgxc_stat_activity where query like '%T_CALL_RECORD_ATTENDEE%'  and usename !='Ruby' order by query_start desc limit 1);  node_name   | db_name |      thread_name       |      query_id      |       tid       |  lwtid  | ptid | tlevel | smpid |           wait_status            | wait_event --------------+---------+------------------------+--------------------+-----------------+---------+------+--------+-------+----------------------------------+------------ dn_6003_6004 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139795727430888 | 3127403 |      |      0 |     0 | none                             |  dn_6009_6010 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 140270667850240 | 4116415 |      |      0 |     0 | none                             |  dn_6011_6012 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139655937670760 | 4116416 |      |      0 |     0 | none                             |  dn_6001_6002 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139846959760552 | 3127402 |      |      0 |     0 | none                             |  dn_6007_6008 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 140166692434008 |  370635 |      |      0 |     0 | none                             |  dn_6005_6006 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139766594408728 |  370634 |      |      0 |     0 | none                             |  cn_5002      | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139761117827248 | 2735702 |      |      0 |     0 | wait node(total 6): dn_6011_6012 | 3、dn抓堆栈postgres=# SELECT * FROM gs_stack('dn_6001_6002',139846959760552);       tid       |  lwtid  |                                                                            stack                                                                             -----------------+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------- 139846959760552 | 3127402 | texteq(FunctionCallInfoData*) + 0x2                                                                                                                                          |         | ExecEvalScalarArrayOp(ScalarArrayOpExprState*, ExprContext*, bool*, ExprDoneCond*) + 0x41c                                                                                   |         | ExecQual(List*, ExprContext*, bool) + 0x98                                                                                                                                   |         | ExecResult(ResultState*) + 0x7a                                                                                                                                              |         | TupleTableSlot* ExecProcNodeT<false, false, false, false, (NodeTag)201>(PlanState*) + 0x8c                                                                                   |         | ExecRowToVecTupleMode(RowToVecState*) + 0x51                                                                                                                                 |         | VectorEngine(PlanState*) + 0x14a                                                                                                                                             |         | FetchRows(VecModifyTableState*, EState*, CmdType&, PlanState*, PlanState*, JunkFilter*, RelationData*, void*, tagVecModifyTableFuncSet const*, bool) + 0x245                 |         | ExecVecModifyTable(VecModifyTableState*) + 0x1ed                                                                                                                             |         | VectorEngine(PlanState*) + 0x14a                                                                                                                                             |         | ExecVecToRow(VecToRowState*) + 0xda                                                                                                                                          |         | TupleTableSlot* ExecProcNodeT<false, false, false, false, (NodeTag)2000>(PlanState*) + 0x8c                                                                                  |         | standard_ExecutorRun(QueryDesc*, ScanDirection, long) + 0x649                                                                                                                |         | ExecutorRun(QueryDesc*, ScanDirection, long) + 0x375                                                                                                                         |         | ProcessQuery(PlannedStmt*, char const*, ParamListInfoData*, _DestReceiver*, char*) + 0xc9                                                                                    |         | PortalRunMulti(PortalData*, bool, _DestReceiver*, _DestReceiver*, char*) + 0x287                                                                                             |         | PortalRun(PortalData*, long, bool, _DestReceiver*, _DestReceiver*, char*, bool) + 0x583                                                                                      |         | exec_execute_message(char const*, long) + 0x342                                                                                                                              |         | PostgresMain(int, char**, char const*, char const*) + 0x15e4                                                                                                                 |         | SubPostmasterMain(tag_gs_thread_args*) + 0x1209                                                                                                                              |         | MainStarterThreadFunc(void*) + 0x3f                                                                                                                                          |         | ThreadStarterFunc(void*) + 0x40                                                                                                                                             |         | 0x7f323d8dc67a                                                                                                                                                              |         | 0x7f323d95f160                 |         | (1 row)发现堆栈和快的计划对不上，快的计划走了索引，而堆栈中走了全表扫描。4、继续对比复现语句和客户实际业务语句发下，慢的情况是PBE（Prepare-Bind-Execute 预编译）后，参数是通过变量的方式传到条件里的，而复现问题时，条件都是直接写好的。客户的业务语句是通过JDBC绑定变量的方式执行的，形如：DELETE FROM schema_css.t_call_record_attendee WHERE confuuid in ($1, $2, $3);而在复现时，将其中的$1等变量内容替换成了实际常量：DELETE FROM schema_css.t_call_record_attendee WHERE confuuid in (1234, 1235, 1236);怀疑是PBE场景导致的执行计划差异。使用PBE方式直连DN模拟PBE的FQS计划，发现执行计划和抓到的堆栈匹配，问题复现，确认和PBE有关。prepare p1(text,text) as select * FROM schema_css.t_call_record_attendee a WHERE confuuid in( $1, $2);explain verbose execute p1('SFyuC4xX3X7yQHzXqAQxv8md3MHgfoWq','MUZASKbhpDBQwK1A2faPpRzw58qRvV2Z');关闭FQS后，在CN上执行，生成了索引计划，执行性能较快，因此可将关闭FQS作为规避方案set enable_fast_query_shipping=off;prepare p1(text,text) as select * FROM schema_css.t_call_record_attendee a WHERE confuuid in( $1, $2);explain verbose execute p1('SFyuC4xX3X7yQHzXqAQxv8md3MHgfoWq','MUZASKbhpDBQwK1A2faPpRzw58qRvV2Z');5、用户级修改参数alter user xxx set enable_fast_query_shipping=off;中间有一个小插曲是，用户级修改参数后，新建连接立即生效，不需要重启，但是老连接不生效，因此需要用户新建连接测试规避方案是否有效。可以通过审计日志查看用户登入登出时间，确保在参数调整后新建连接：select * from pgxc_query_audit('2025-08-15 00:00:00','2025-08-15 06:30:00') where session_id like '%对应的pid%' and detail_info not in ('START TRANSACTION','ROLLBACK','COMMIT') and operation_type ='login_logout' order by begintime;修改参数生效后，验证问题得到解决。 三、问题根因通过PBE的方式执行，array用法在PBE场景下不支持向量化，in条件会被转化为array，直接执行时，走的FQS计划，导致走了全表扫描，再走行存过滤表达式，性能差。关闭FQS后，变量在CN上被替换，替换后支持向量化，因此可以生成索引扫描计划，性能快。规避方法：（1）通过hint关闭fqs ： /*+ set global(enable_fast_query_shipping off) */，仅影响当前语句（2）用户级关闭参数： alter user xxx set enable_fast_query_shipping=off;  仅影响当前用户，一般不会产生其他副作用 

JDBC执行SQL报错：I0 Error: Socket read timed out这个错误表明JDBC连接在尝试从数据库读取数据时超时了。以下是可能的原因和解决方案：可能原因网络问题：客户端与数据库服务器之间的网络连接不稳定或延迟过高查询执行时间过长：SQL查询过于复杂或处理大量数据，超过默认超时时间数据库服务器负载过高：服务器资源不足导致响应缓慢防火墙/安全组设置：网络中间件阻断了长时间连接的请求JDBC驱动配置不当：未正确设置超时参数解决方案1. 增加超时时间设置// 设置查询超时时间（秒） statement.setQueryTimeout(30); // 或者在JDBC URL中设置 String url = "jdbc:mysql://host:3306/db?connectTimeout=30000&socketTimeout=60000"; 2. 优化SQL查询检查并优化长时间运行的SQL语句添加适当的索引考虑分批处理大量数据3. 检查网络连接测试客户端与数据库服务器之间的网络延迟检查是否有防火墙或代理服务器中断了长时间连接4. 调整数据库服务器配置增加数据库服务器的资源（CPU、内存）检查数据库服务器的超时设置5. 使用连接池配置如果使用连接池（如HikariCP、DBCP），可以配置：// HikariCP示例配置 HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://host:3306/db"); config.setConnectionTimeout(30000); // 连接超时 config.setIdleTimeout(600000); // 空闲连接超时 config.setMaxLifetime(1800000); // 最大生命周期 config.setLeakDetectionThreshold(5000); // 泄漏检测 6. 检查JDBC驱动版本确保使用与数据库版本兼容的最新JDBC驱动。诊断步骤首先确认是偶发问题还是持续出现检查数据库服务器监控指标（CPU、内存、IO）尝试在数据库客户端直接执行相同SQL，观察执行时间使用网络抓包工具（如Wireshark）检查网络通信如果问题持续存在，可能需要联系DBA检查数据库服务器日志以获取更详细的错误信息。

目前华为云上的css中的Elasticsearch7.10.2版本的实例，是否支持jdbc方式访问？好像没有看到这方面的信息

 与某单位内部MRS集群Hive对接，从Windows电脑使用Idea导入样例程序， 连接Hive数据库； 已按说明文档中提示检查如下项：1.系统时间 ：Windows客户端环境时间比集群时间延迟小时30秒2.krb5.conf、user.keytab文件是最新的 ；程序中用户名修改：  USER_NAME = "xxx"（替换为实际用户）;    3.user.hive.jaas.conf 文件中  keyTab 修改为实际“user.keytab” 文件路径； principal="XXX@HADOOP.COM"   运行最后提示Unable to read HiveServer2 configs from Zookeeper  具体日志如下:  ServerPrincipalProvider - Got server principal from the server and it is zookeeper/hadoop.hadoop.comServerPrincipalProvider - Using server principal zookeeper/hadoop.hadoop.comLogin - TGT refresh thread startedLogin - TGT valid startig at:        XXXXXXXXXXXLogin - TGT expires:                   XXXXXXXXXXXXLogin - TGT refresh sleeping until:   XXXXXXXXXXXXClientCnxn - Opening socket connection to server  XXX.XX.XX.XX/XXX.XX.XX.XX:24002 . Will attempt to SASL-authenticate using Login Context section 'Client'ClientCnxn - Client session time out ,have not heard from server in  23221ms from connectionid 0x0ClientCnxn - EventThread shut down for connectionid:0x0ZooKeeper - Connectionid:0x0 closedJDBCExample - Create connection failed: org.apache.hive.jdbc.ZookeeperHiveClientException:Unable to read HiveServer2 configs from Zookeeper  Opening socket connection to server  XXX.XX.XX.XX/XXX.XX.XX.XX:24002    这个IP对应的端口可以telnet通    

pg_hba.conf 设置openEuler22.03 openGauss5.0.3 单节点目前本机连接没问题 服务啥的也没问题 防火墙关了 我不知道还有没有需要改的地方 有经验的请说一下 谢谢

官方的容灾场景的架构配置为:A集群生产3节点 , B集群容灾3节点.如果B集群容灾为单节点JDBC在配置连接串时应如何进行配置  , 假设 node4 为容灾单节点为只读官方的介绍为 : jdbc:gaussdb://node1,node2,node3,node4/database?autoBalance=shuffle如果写成 : jdbc:gaussdb://node1,node2,node3,node4/database?autoBalance=true&priorityServers=3  需求为 : 在JDBC有连接池的情况下 ,优先连接主集群3节点 , 在发生主备切换后自动连接容灾单节点 , 等主集群修复后进行二次切换 , 通过 JDBC 连接串自动连接主集群3节点.

开发是用windows开发的，发版是Linux环境，Windows环境发版没有问题【主库】Next recovery time: 2024/1/15 17:50:50 (ERROR [01000] [unixODBC][Driver Manager]Can't open lib '/usr/lib64/psqlodbcw.so' : file not found)【主库】Next recovery time: 2024/1/15 17:41:38 (ERROR [01000] [unixODBC][Driver Manager]Can't open lib 'PostgreSQL Unicode' : file not found)

水平分表 把一个表的数据分到一个数据库的多张表中，每个表只有这个表的部分数据 核心是把一个大表，分割N个小表，每个表的结构是一样的，数据不一样，全部表的数据合起来就是全部数据 针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去 但是这些表还是在同一个库中，所以单数据库操作还是有IO瓶颈，主要是解决单表数据量过大的问题 减少锁表时间，没分表前，如果是DDL(create/alter/add等)语句，当需要添加一列的时候mysql会锁表，期间所有的读写操作只能等待 水平分表的适用场景 当一张表的数据达到几千万时，查询一次所花的时间长，需要进行优化，缩短查询时间 微博发送记录、微信消息记录、日志记录。以id增长或时间划分 网站签到等活动流水数据。以时间划分 依赖引入  <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>sharding-jdbc-spring-boot-starter</artifactId> <version>4.1.1</version> </dependency>application# 数据源 ds0 第一个数据库 --- 版本：mysql8 shardingsphere: datasource: ds0: connectionTimeoutMilliseconds: 30000 driver-class-name: com.mysql.cj.jdbc.Driver idleTimeoutMilliseconds: 60000 jdbc-url: jdbc:mysql://[ip]:3306/[数据库]?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true maintenanceIntervalMilliseconds: 30000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 50 password: [密码] type: com.zaxxer.hikari.HikariDataSource username: [用户名] names: ds0 props: # 打印执行的数据库以及语句 sql: show: true sharding: tables: [表名]: # 指定表的数据分布情况，配置数据节点,行表达式标识符使用 ${...} 或 $->{...}，但前者与 Spring 本身的文件占位符冲突，所以在 Spring 环境中建议使用 $->{...} actual-data-nodes: ds0.[表名_]$->{0..1} # 水平分表策略+行表达式分片 table-strategy: inline: algorithm-expression: [表名_]$->{[取模字段] % 2} sharding-column: [取模字段] #id生成策略 key-generator: column: id props: worker: id: 0 #id生成策略 type: SNOWFLAKE 测试 @Test public void testSaveTraffic(){ Random random = new Random(); for(int i=0;i<10;i++){ TrafficDO trafficDO = new TrafficDO(); // 设置取模字段的值 Int trafficDO.setAccountNo(Long.valueOf(random.nextInt(1000))); trafficMapper.insert(trafficDO); } } 结果分析 取模字段accountNo为偶数的对象，存储到traffic_0表 取模字段accountNo为奇数的对象，存储到traffic_1表 实现水平分表 转载自https://www.cnblogs.com/xietingwei/p/17571979.html

常见的分库分表中间件包括ShardingSphere、MyCAT、Vitess和TDDL。以下是它们的优缺点： ShardingSphere： 优点： 功能全面：提供了完整的分库分表解决方案，支持多种数据库和丰富的功能，如读写分离、分布式事务等。 社区活跃：由Apache孵化，具有庞大的开源社区支持，更新迭代速度快。 易于集成：提供了丰富的文档和示例，易于使用和集成到现有项目中。 缺点： 配置复杂：相对其他中间件而言，配置和部署可能较为繁琐，需要一定的学习成本。 MyCAT： 优点： 简单易用：相对较简单的配置和部署，容易上手和使用。 支持MySQL协议：兼容MySQL协议，应用程序无需修改即可访问分片和分表数据。 缺点： 社区活跃度较低：相比其他几个中间件，MyCAT的社区活跃度较低，更新和维护可能相对滞后。 功能相对较少：相对于一些更全面的中间件，MyCAT的功能相对有限，可能不适用于更复杂的场景。 Vitess： 优点： 高度可扩展：通过分片实现数据的水平扩展，能够轻松应对大规模数据和高并发访问。 负载均衡和故障恢复：提供了自动负载均衡和故障恢复功能，提高了系统的可靠性和可用性。 缺点： 学习曲线较陡峭：配置和使用Vitess需要一定的学习成本，上手和部署可能相对复杂。 对MySQL兼容性有限：由于Vitess是为MySQL设计的，与其他数据库的兼容性相对较差。 TDDL： 优点： 阿里巴巴支持：由阿里巴巴集团开发和维护，具有较强的技术实力和稳定性。 动态数据切换：支持动态数据切换，方便在运行时进行数据分片和迁移。 缺点： 社区支持相对较少：与一些更受欢迎的开源中间件相比，TDDL的社区支持相对较少。 选择适合的分库分表中间件需要根据具体的需求和场景来评估。您需要考虑到中间件的功能覆盖、易用性、社区支持、稳定性和对应数据库的兼容性等因素，并结合自身团队的技术实力和偏好进行选择。 

请教个问题，通过jdbc提交mrs作业到yarn上，mrs是否接口可以返回yarn上执行的作业占用的资源(cpu/memory)的情况

SpringBoot使用Sharding-JDBC实现读写分离在大数据时代，数据库的性能问题越来越受到关注。为了提高系统的性能，我们可以通过读写分离的方式来优化数据库的访问。本文将介绍如何在SpringBoot和MyBatis项目中使用Sharding-JDBC实现读写分离。一、环境准备安装Java开发环境(JDK 1.8或更高版本)。安装Maven构建工具。安装MySQL数据库。下载并安装Sharding-JDBC。二、配置SpringBoot在pom.xml文件中添加Sharding-JDBC依赖：<dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>sharding-jdbc-spring-boot-starter</artifactId> <version>4.1.1</version> </dependency>在application.yml文件中配置数据源和分片规则：spring: shardingsphere: datasource: names: ds0,ds1 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/ds0?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8 username: root password: 123456 ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/ds1?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8 username: root password: 123456 sharding: default-database-strategy: inline: sharding-column: id algorithm-expression: ds${id % 2} tables: t_order: actual-data-nodes: ds${0..1}.t_order${0..1} table-strategy: standard: sharding-column: order_id sharding-algorithm-name: inline在src/main/resources目录下创建sql文件夹，并在其中创建两个t_order_${0..1}.sql文件，分别用于模拟ds0和ds1的数据表结构。例如，ds0的数据表结构如下：CREATE TABLE `t_order` ( `id` int(11) NOT NULL, `order_id` int(11) NOT NULL, `create_time` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;在Service类中注入DataSource,并使用@Autowired注解。例如，在一个Service类中：import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.util.List; import java.util.Map; import java.util.stream.Collectors; import com.baomidou.mybatisplus.core.conditions.query.QueryWrapper; import com.baomidou.mybatisplus.extension.service.impl.ServiceImpl; import com.zaxxer.hikari.HikariDataSource; import org.springframework.transaction.annotation.Transactional; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.jdbc.core.namedparam JdbcTemplate; // import语句错误，请自行解决 @Service public class OrderService extends ServiceImpl<OrderMapper, Order> { @Autowired private HikariDataSource ds0; @Autowired private HikariDataSource ds1; @Transactional(rollbackFor = Exception.class) public void createOrder(Order order) { // 根据order的id判断应该使用哪个数据源进行插入操作 if (order.getId() % 2 == 0) { jdbcTemplate(ds0).insert(order); } else { jdbcTemplate(ds1).insert(order); } } }四、总结通过本文的介绍，我们了解了如何在SpringBoot和MyBatis项目中使用Sharding-JDBC实现读写分离。具体来说，我们需要完成以下几个步骤：在pom.xml文件中添加Sharding-JDBC依赖。在application.yml文件中配置数据源和分片规则。在Service类中注入DataSource,并使用@Autowired注解。根据order的id判断应该使用哪个数据源进行插入操作。通过以上步骤，我们就可以实现在SpringBoot和MyBatis项目中使用Sharding-JDBC进行读写分离。需要注意的是，在使用Sharding-JDBC时，我们需要根据具体的业务需求来选择合适的分片策略和数据源。同时，我们也需要对数据库进行合理的优化，以提高系统的性能。

jar包获取以下提供的都是各个数据库较为官方的jar包获取方式1、Mysqlcid:link_5 tar.gz为Linux系统的压缩包，zip为Windows系统的压缩包 在下载好的zip压缩包中包含有jar包文件，解压出来使用即可2、MariaDBcid:link_4 点击 Download MariaDB Connector/J 按钮跳转 选择Connectors，Connector version选择MariaDB Connector/J 3.1.0，镜像地址可以切换，选择一个能下载的即可3、Oraclecid:link_1 根据Oracle服务器的版本选择对应的驱动版本下载即可4、PostgreSQLcid:link_7 选择合适的版本点击下载即可5、MongoDBcid:link_3选择合适的jar包驱动版本 选择jar格式的下载包6、SQL Servercid:link_0 tar.gz格式的压缩包适合在Linux系统解压，zip格式的压缩包适合在Windows系统解压，下载此驱动程序时，有多个 JAR 文件。 JAR 文件名表示它支持的 Java 版本，选择合适的版本使用详细操作可以参考本论坛的这个帖子 cid:link_27、SQLitecid:link_6 选择合适的版本点击Downloads按钮 在Assets项下选择jar格式的文件点击下载管理中心白名单处理如果项目中包含jar包文件，在管理中心上传脚本时会触发文件类型的白名单检查，如果未配置jar包中的相关文件类型，那么就无法通过白名单检查，从而管理中心上传脚本失败。jar包文件本质上是一个压缩包，白名单检查会校验压缩包中所有文件的类型，所以我们需要将压缩包中所有的文件类型填写到白名单中。使用解压缩软件就可以解压查看jar包中的文件类型信息了，这里以7-Zip软件示例。 jar包中包含的文件可能比较多，要查找所有的文件类型信息比较耗时，我这里总结了前面数据库的jar包中包含文件的类型，各个类型通过分号(;)分割，这也是管理中心白名单配置的格式。jar;class;MF;LIST;Driver;properties;xml;AuthenticationPlugin;Codec;CredentialPlugin;TlsSocketPlugin;RSA;SF;txt;json;glb;so;zentus;dll;jnilib;以上整理的jar包中的文件类型可能随版本变动而变动，或者你拥有的jar包没在这个整理范围，所以建议你自己解压jar包统计一下相关的文件类型。如果觉得文件类型过多，难以统计，可以选择在文件类型的白名单中添加星号(*)来达到允许所有文件类型的设置，但是这样就放开了文件类型的风险管控，需要自己评估相关操作的风险系数，建议谨慎操作。

如图，想问下要怎么解决。选择的jar包是：gsjdbc4.jar而且很奇怪的是，没有设置enable_ce=1时，就能成功连接，设置后才会出现报错。

【问题现象】jdbc copy报错connection failed when canceling copy operation【问题原因】copy过程中出现错误导致copy失败【排查过程】1. 首先测试jdbc客户端到DWS网络是否正常，jdbc是否能建立稳定连接2. 排查DWS CN日志，是否有copy相关报错3. 本例中，是由于copy的目标表上有not null约束，但导入的数据包含null值，导致copy报错，由于使用的开源驱动，错误未直接在客户端显示【解决方法】根据CN日志报错内容，去除目标表的not null约束

测试环境 客户端系统： Windows 10 客户端软件： eclipse 2020-09 Server操作系统：openEuler 20.03 64bit with ARM Database版本： openGauss 2.0.0 作者：酷哥1.客户端安装配置JDK11 DOS窗口输入“java -version”，查看JDK版本，确认为JDK11版本。如果未安装JDK，请 从官方网站下载安装包并安装。 根据如下步骤配置系统环境变量： a. 右键单击“我的电脑“，选择“属性“。 b. 在“系统“页面左侧导航栏单击“高级系统设置“。 c. 在“系统属性“页面，“高级“页签上单击“环境变量“。 d. 在“环境变量“页面上，“系统变量“区域单击“新建“或“编辑“配置系统变量。变量说明请参 见表。2.下载JDBC驱动并解压 下载地址：https://opengauss.obs.cn-south-1.myhuaweicloud.com/2.0.0/x86/openGauss-2.0.0-JDBC.tar.gz 3.启动eclipse，新建工程并添加JDBC驱动 Create a java projectProject name: openGauss-JDBC; JRE: JavaSE-11不需要创建“Don’t Create”创建一个lib目录在openGauss-JDBC项目下把jdbc驱动拷贝到lib下边加载jdbc驱动“Add JARs”在“Libraries”下，选中需要的postgresql.jar文件，然后“Apply and Close”Jdbc jar已经被正确加载，在“Referenced Libraries”下创建“Java Class”拷贝准备的代码到java类中运行java类“Run as --》java application”Tips: 此次使用eclipse 2020-09 创建JAVA Class/*测试代码*/ package gaussjdbc; //ogtest.java //演示基于JDBC开发的主要步骤，会涉及创建数据库、创建表、插入数据等。 import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; import java.sql.SQLException; import java.sql.Statement; import java.sql.CallableStatement; public class Gaussjdbc { //创建数据库连接。 public static Connection GetConnection(String username, String passwd) { String driver = "org.postgresql.Driver"; String sourceURL = "jdbc:postgresql://122.9.34.186:26000/db_tpcc"; Connection conn = null; try { //加载数据库驱动。 Class.forName(driver).newInstance(); } catch (Exception e) { e.printStackTrace(); return null; } try { //创建数据库连接。 conn = DriverManager.getConnection(sourceURL, username, passwd); System.out.println("Connection succeed!"); } catch (Exception e) { e.printStackTrace(); return null; } return conn; }; //执行普通SQL语句，创建customer_t1表。 public static void CreateTable(Connection conn) { Statement stmt = null; try { stmt = conn.createStatement(); //执行普通SQL语句。 int rc = stmt .executeUpdate("CREATE TABLE customer_t1(c_customer_sk INTEGER, c_customer_name VARCHAR(32));"); stmt.close(); } catch (SQLException e) { if (stmt != null) { try { stmt.close(); } catch (SQLException e1) { e1.printStackTrace(); } } e.printStackTrace(); } } //执行预处理语句，批量插入数据。 public static void BatchInsertData(Connection conn) { PreparedStatement pst = null; try { //生成预处理语句。 pst = conn.prepareStatement("INSERT INTO customer_t1 VALUES (?,?)"); for (int i = 0; i < 3; i++) { //添加参数。 pst.setInt(1, i); pst.setString(2, "data " + i); pst.addBatch(); } //执行批处理。 pst.executeBatch(); pst.close(); } catch (SQLException e) { if (pst != null) { try { pst.close(); } catch (SQLException e1) { e1.printStackTrace(); } } e.printStackTrace(); } } //执行预编译语句，更新数据。 public static void ExecPreparedSQL(Connection conn) { PreparedStatement pstmt = null; try { pstmt = conn .prepareStatement("UPDATE customer_t1 SET c_customer_name = ? WHERE c_customer_sk = 1"); pstmt.setString(1, "new Data"); int rowcount = pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) { if (pstmt != null) { try { pstmt.close(); } catch (SQLException e1) { e1.printStackTrace(); } } e.printStackTrace(); } } /** * 主程序，逐步调用各静态方法。 * @param args */ public static void main(String[] args) { //创建数据库连接。 Connection conn = GetConnection("joe", "Bigdata@123"); //创建表。 CreateTable(conn); //批插数据。 BatchInsertData(conn); //执行预编译语句，更新数据。 ExecPreparedSQL(conn); //关闭数据库连接。 try { conn.close(); } catch (SQLException e) { e.printStackTrace(); } } }4.测试示例代码5.检查运行结果 -- 检查客户端运行结果 --检查数据库数据变化 代码成功运行，且数据库数据变更正常，即连接环境配置完毕。