Apache Omid Idea 环境搭建
IDEA 搭建 Apache Omid 源码 DEBUG 环境Apache Omid 在 Apache HBase 之上提供了多行分布式事务的能力，支持全局 MVCC 功能。简单介绍编译过程。 1.下载 HBase2 并启动https://dlcdn.apache.org/hbase/ 配置环境变量 12export HBASE_HOME=/xxx/hbase-2.4.18export PATH=$PATH:$HBASE_HOME/bin: 2.编译代码编译1git clone https://github.com/apache/phoenix-omid 基于最新的 master af8e377affcd76b1cbde5cab3513731b23bd51fc 编译。 maven 依赖处理有几处编译报错，处理如下： 根 pom 里添加: 12345<dependency> <groupId>org.glassfish</groupId> <artifactId>javax.el</artifactId>...
MySQL 驱动 Add Batch 优化实现
MySQL 驱动 Add Batch 优化实现MySQL 驱动会在 JDBC URL 添加 rewriteBatchedStatements 参数时，对 batch 操作进行优化。本文测试各种参数组合的行为，并结合驱动代码简单分析。 batch参数组合行为useServerPrepStmts 参数123PreparedStatement psmt = connection.prepareStatement("DELETE FROM t_order WHERE `order_id` = ?");psmt.setObject(1, 1);psmt.execute(); 开启:使用服务端预编译，先发送 prepared 语句，再发送 excute 语句 不开启:mysql 驱动会将占位符填充后，明文下发sql. 比如 DELETE FROM t_order WHERE order_id = ?; 语句 MySQL 驱动会下发 DELETE FROM t_order WHERE order_id = 1; allowMultiQueries...
ShardingSphere-SQL 解析 Issue 处理流程
ShardingSphere-SQL 解析 Issue 处理流程这是之前给社区写的 SQL 解析 Issue 的处理流程，可以帮助社区用户快速参与到 ShardingSphere-SQL 解析当中。 ShardingSphere SQL 解析 issue 列表 Issue 背景说明当前 Issue 使用自定义的爬虫脚本从对应的数据库官网上抓取 SQL Cases，然后交给 ShardingSphere 的解析引擎进行解析。对于解析失败的 SQL Case，每 3~5 条 SQL 作为一个 Issue。 由于是通过爬虫抓取的，所以不保证所有 SQL 本身就是正确的，请按照如下流程处理该 PR。 有些 SQL Case 可能已经在其他 PR 里被修复，对于已经可以执行的 Case 直接留言忽略即可。 如果该 SQL Case 已经可以成功运行，没有任何代码改动，那么不需要添加对应的 Test 断言文件。 总体流程 如果你打算参与该 Issue 的修复，欢迎在 Issue 下方留言，会有社区同学分配该 Issue。 比如留言：Hi, please assign this...
ShardingSphere Narayana XA 事务不回滚问题定位
ShardingSphere Narayana XA 事务不回滚问题定位问题背景用户反馈，在使用 ShardingSphere + Narayana 执行 XA 事务时，发生报错：java.sql.SQLException: javax.transaction.RollbackException: TransactionImple.enlistResource - ARJUNA016064: The transaction is in an invalid state!。这个报错的含义简单来说就是这个事务已经在其他地方被标记成只可回滚了，不能再进行后续其他的操作。报错信息如下： 12345678910111213141516171819202122Caused by: java.sql.SQLException: javax.transaction.RollbackException: TransactionImple.enlistResource - ARJUNA016064: The transaction is in an invalid state! at...
ShardingSphere-XA事务无法恢复问题定位
ShardingSphere-XA事务无法恢复问题定位问题背景在测试 ShardingSphere-Proxy 使用达梦数据库开启 XA 事务进行压测期间，kill 掉达梦数据库，等一段时间再重启达梦数据库，最终未完成的 XA 事务无法恢复，数据产生不一致。查看达梦上的 xid 一直有残留，没有被处理。使用 ShardingSphere-Proxy 结合其他主流数据库进行测试时无该问题。 通过日志可以看到在压测期间，挂掉达梦数据库之后，有大量连接报错。节选错误日志如下：比如下面这段日志，在执行 xa end 操作时，因为达梦数据库连接不上，达梦驱动报错如下： 1234567891011121314151617181920212223242526272829[WARN ] 2024-01-29 11:11:19.867 [Connection-82-ThreadExecutor] com.arjuna.ats.jta - ARJUNA016041: prepare on < formatId=131077, gtrid_length=64, bqual_length=36,...
ShardingSphere-inline表达式线程安全问题定位
ShardingSphere inline表达式线程安全问题定位问题背景春节期间发现 ShardingSphere 事务 E2E 偶发执行失败问题，并且每次执行失败需要执行很久，直到超时。最终定位发现 inline 表达式存在线程安全问题。本文记录定位并解决 inline 表达式线程安全问题的过程。 问题原因1.GroovyInlineExpressionParser 里有成员变量，存在并发修改，不能使用单例 SPI 实现;2.执行 Groovy 表达式时，需要执行 rehydrate 方法 copy Closure,使得每个 Closure 都有独立的执行环境，避免属性赋值时产生线程安全问题。 问题定位构造测试用例尝试复现问题构造测试用例，且在测试用例中添加线程相关信息，观察执行结果。 1234567891011121314151617181920212223242526272829@Test@SneakyThrows({ExecutionException.class, InterruptedException.class})void...
Percolator 分布式事务原理
Percolator 分布式事务原理简介Percolator 提供了跨行、跨表的、基于快照隔离的 ACID 事务。 结构Percolator 为了实现分布式事务，抽象了三个列。 1234567891011121314151617181920212223242526列 Data 作用: 具体存储数据集 映射关系: {key, start_ts} => {value} key: 真实的 key start_ts: 事务开始时间戳 value: 真实的数据值 Lock 作用: 事务执行中产生的锁 事务开启时获取锁 事务提交时释放锁 映射关系: {key, start_ts} => {primary_key, lock_type,..etc} key:...
Otter环境搭建
IDEA 搭建 Otter 源码 DEBUG 环境在适配 ShardingSphere-JDBC 同步 Otter 时，本地搭建 Otter Debug 环境记录。 1.源码编译启动编译1234# 参考官方文档，安装 otter/lib 目录下的依赖。mvn install:install-file -Dfile=/otter/lib/jtester-1.1.8.jar -DgroupId=org.jtester -DartifactId=jtester -Dversion=1.1.8 -Dpackaging=jarmvn install:install-file -Dfile=/otter/lib/ojdbc6.jar -DgroupId=com.oracle -DartifactId=ojdbc6 -Dversion=11.2.0 -Dpackaging=jar 使用jdk8,按照官方文档编译即可。https://github.com/alibaba/otter manager 模块启动1.参考官方文档，初始化 otter manager mysql...
Spring 事务实现
Spring 事务实现Spring 事务使用123456789101112131415161718192021222324@Transactional注解配置项 事务传播行为 PROPAGATION_REQUIRED 当前方法必须在事务中，没有就创建，有就加入。 PROPAGATION_SUPPORTS 有事务就加入，没有就以非事务方式执行。 PROPAGATION_MANDATORY 有事务就加入，没有就抛出异常。 PROPAGATION_REQUIRES_NEW 永远创建新事务执行，之前若有事务则挂起之前的事务。 PROPAGATION_NOT_SUPPORTED 以非事务方式执行。之前若有事务则挂起之前的事务。 PROPAGATION_NEVER 以非事务方式执行。之前若有事务则抛出异常。 PROPAGATION_NESTED ...
Ubuntu Desktop 死机处理
Ubuntu Desktop 死机处理当 Ubuntu Desktop 死机时，除了长按电源键重启，还可以使用如下两种方式处理。 方式1：ctrl+alt+Fn使用 ctrl + alt + F3~F6: 切换到其他 tty 命令行。执行 top 命令查看资源占用最多的进程，然后使用 kill 命令杀死进程即可。然后使用 ctrl + alt + F1 切回到桌面。 方式2：REISUBbuiser 组合键：<Ctrl+Alt> + <Sysrq/PrtSc> + <REISUB> 操作：按住 ctrl + alt + sys rq(prt sc) 键不放，然后依次按下 R、E、I、S、U、B 按键，全部按完之后，系统自动重启。 作用：按住 Sys Rq，此时输入的一切都会直接由 Linux 内核来处理，它可以执行许多低级操作。此时 reisub 中的每一个按键都对应一个独立操作，他们分别表示：nRaw: 将键盘控制从 X Server 那里抢回来，以确保可以与内核通信。tErminate: 给所有进程发送 SIGTERM...