Open peilinqian opened 2 years ago
split_db=> SHOW READWRITE_SPLITTING RULES ;
name | auto_aware_data_source_name | write_data_source_query_enabled | write_data_source_name | read_data_source_names | load_balancer_type | load_balancer_props
------+-----------------------------+---------------------------------+------------------------+------------------------+-------------------------+---------------------
ds_0 | | | write_0 | read0_0 | TRANSACTION_ROUND_ROBIN |
ds_1 | | | write_1 | read1_0 | TRANSACTION_ROUND_ROBIN |
(2 rows)
rules:
- !AUTHORITY
users:
- root@%:root
- sharding@:sharding
provider:
type: ALL_PERMITTED
- !TRANSACTION
defaultType: XA
providerType: Atomikos
schemaName: split_db
dataSources:
write_0:
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 260
minPoolSize: 1
password: Test@123
url: jdbc:opengauss://10.29.180.204:15000/tpccdb?batchMode=on
username: tpccuser
read0_0:
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 260
minPoolSize: 1
password: Test@123
url: jdbc:opengauss://10.28.13.92:15000/tpccdb?batchMode=on
username: tpccuser
read0_1:
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 260
minPoolSize: 1
password: Test@123
url: jdbc:opengauss://7.212.123.28:15000/tpccdb?batchMode=on
username: tpccuser
write_1:
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 260
minPoolSize: 1
password: Test@123
url: jdbc:opengauss://10.29.180.204:16000/tpccdb?batchMode=on
username: tpccuser
read1_0:
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 260
minPoolSize: 1
password: Huawei@123
url: jdbc:opengauss://10.28.13.92:16000/tpccdb?batchMode=on
username: tpccuser
read1_1:
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 260
minPoolSize: 1
password: Test@123
url: jdbc:opengauss://7.212.123.28:16000/tpccdb?batchMode=on
username: tpccuser
rules:
- !SHARDING
tables:
t_single:
actualDataNodes: ds_0.t_single
t_single_view:
actualDataNodes: ds_0.t_single_view
t_single_view_new:
actualDataNodes: ds_0.t_single_view_new
t_ssdb_tb:
actualDataNodes: ds_${0..1}.t_ssdb_tb_${0..1}
databaseStrategy:
standard:
shardingAlgorithmName: ds_database_inline
shardingColumn: id
tableStrategy:
standard:
shardingColumn: c_id
shardingAlgorithmName: ts_t_ssdb_tb_inline
t_ssdb_tb_view:
actualDataNodes: ds_${0..1}.t_ssdb_tb_view_${0..1}
databaseStrategy:
standard:
shardingAlgorithmName: ds_database_inline
shardingColumn: id
tableStrategy:
standard:
shardingColumn: c_id
shardingAlgorithmName: ts_t_ssdb_tb_view_inline
t_ssdb:
actualDataNodes: ds_${0..1}.t_ssdb
databaseStrategy:
standard:
shardingAlgorithmName: ds_database_inline
shardingColumn: id
t_ssdb_view:
actualDataNodes: ds_${0..1}.t_ssdb_view
databaseStrategy:
standard:
shardingAlgorithmName: ds_database_inline
shardingColumn: id
t_ssdb_tbo:
actualDataNodes: ds_${0..1}.t_ssdb_tbo_${0..1}
databaseStrategy:
standard:
shardingAlgorithmName: ds_database_inline
shardingColumn: id
tableStrategy:
standard:
shardingColumn: c_id
shardingAlgorithmName: ts_t_ssdb_tbo_inline
broadcastTables:
- t_broadcast
- t_broadcast_view
bindingTables:
- t_ssdb_tb, t_ssdb_tbo, t_ssdb_tb_view
defaultTableStrategy:
none:
defaultDatabaseStrategy:
none:
shardingAlgorithms:
ds_database_inline:
type: INLINE
props:
algorithm-expression: ds_${id % 2}
allow-range-query-with-inline-sharding: true
ts_t_ssdb_tb_inline:
type: INLINE
props:
algorithm-expression: t_ssdb_tb_${c_id % 2}
allow-range-query-with-inline-sharding: true
ts_t_ssdb_tbo_inline:
type: INLINE
props:
algorithm-expression: t_ssdb_tbo_${c_id % 2}
allow-range-query-with-inline-sharding: true
ts_t_ssdb_tb_view_inline:
type: INLINE
props:
algorithm-expression: t_ssdb_tb_view_${c_id % 2}
allow-range-query-with-inline-sharding: true
- !READWRITE_SPLITTING
dataSources:
ds_0:
staticStrategy:
writeDataSourceName: write_0
readDataSourceNames:
- read0_0
- read0_1
loadBalancerName: roundRobin
ds_1:
staticStrategy:
writeDataSourceName: write_1
readDataSourceNames:
- read1_0
- read1_1
loadBalancerName: roundRobin
loadBalancers:
roundRobin:
type: TRANSACTION_ROUND_ROBIN
rules:
- !READWRITE_SPLITTING
dataSources:
readwrite_ds:
staticStrategy:
writeDataSourceName: ds_0
readDataSourceNames:
- ds_1
loadBalancerName: random
loadBalancers:
random:
type: TRANSACTION_ROUND_ROBIN
When i use loacl
mode of trancation,it act normal
I can't reproduce it locally.
sharding_db=> drop table if exists t_single;
DROP TABLE
sharding_db=> create table t_single(id int,c_id int,a int,b text);
CREATE TABLE
sharding_db=> insert into t_single values (1,1,10,'test1'),(1,2,10,'test1'),(2,2,20,'test2'),
(3,3,10,'test3'),(4,4,40,'test4'),(5,5,50,'test5');sharding_db->
INSERT 0 6
sharding_db=> create index idx_rw on t_single(id);
CREATE INDEX
sharding_db=> select * from t_single;
select * from t_single;
select * from t_single; id | c_id | a | b
----+------+----+-------
1 | 1 | 10 | test1
1 | 2 | 10 | test1
2 | 2 | 20 | test2
3 | 3 | 10 | test3
4 | 4 | 40 | test4
5 | 5 | 50 | test5
(6 rows)
sharding_db=> id | c_id | a | b
----+------+----+-------
1 | 1 | 10 | test1
1 | 2 | 10 | test1
2 | 2 | 20 | test2
3 | 3 | 10 | test3
4 | 4 | 40 | test4
5 | 5 | 50 | test5
(6 rows)
sharding_db=>
id | c_id | a | b
----+------+----+-------
1 | 1 | 10 | test1
1 | 2 | 10 | test1
2 | 2 | 20 | test2
3 | 3 | 10 | test3
4 | 4 | 40 | test4
5 | 5 | 50 | test5
(6 rows)
sharding_db=> begin;
BEGIN
sharding_db=> insert into t_single values(6,6,60,'test6');
INSERT 0 1
sharding_db=> select * from t_single;
id | c_id | a | b
----+------+----+-------
1 | 1 | 10 | test1
1 | 2 | 10 | test1
2 | 2 | 20 | test2
3 | 3 | 10 | test3
4 | 4 | 40 | test4
5 | 5 | 50 | test5
(6 rows)
sharding_db=> select * from t_single;
end; id | c_id | a | b
----+------+----+-------
1 | 1 | 10 | test1
1 | 2 | 10 | test1
2 | 2 | 20 | test2
3 | 3 | 10 | test3
4 | 4 | 40 | test4
5 | 5 | 50 | test5
(6 rows)
sharding_db=>
COMMIT
sharding_db=> SHOW TRANSACTION RULE;
default_type | provider_type | props
--------------+---------------+-------
XA | Narayana |
(1 row)
sharding_db=>
This error is suspicious: org.opengauss.xa.PGXAException: Error rolling back prepared transaction
,I think it maybe the OG's problem,I found a similar question for reference:
https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exception
This error is suspicious:
org.opengauss.xa.PGXAException: Error rolling back prepared transaction
,I think it maybe the OG's problem,I found a similar question for reference: https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exception
Thanks for your reply,after reset max_prepared_transactions
,use proxy execute above case ,i found nomatter use local
mode or xa
mode ,it act normal
This error is suspicious:
org.opengauss.xa.PGXAException: Error rolling back prepared transaction
,I think it maybe the OG's problem,I found a similar question for reference: https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exceptionThanks for your reply,after reset
max_prepared_transactions
,use proxy execute above case ,i found nomatter uselocal
mode orxa
mode ,it act normal
What is the value of max_prepared_transactions reset to?
This error is suspicious:
org.opengauss.xa.PGXAException: Error rolling back prepared transaction
,I think it maybe the OG's problem,I found a similar question for reference: https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exceptionThanks for your reply,after reset
max_prepared_transactions
,use proxy execute above case ,i found nomatter uselocal
mode orxa
mode ,it act normalWhat is the value of max_prepared_transactions reset to?
set max_prepared_transactions=5000;
Maybe it is related about variables of openGauss like synchronous_commit
& synchronous_standby_names
?
Further validation is needed.
Maybe it is related about variables of openGauss like
synchronous_commit
&synchronous_standby_names
?Further validation is needed.
@peilinqian can you provide your value of variables of openGauss like synchronous_commit & synchronous_standby_names ?
Maybe it is related about variables of openGauss like
synchronous_commit
&synchronous_standby_names
? Further validation is needed.@peilinqian can you provide your value of variables of openGauss like synchronous_commit & synchronous_standby_names ? execute this SQL in standby database; select name, setting from pg_settings order by 1,2; set guc parameter in standby database gs_guc reload -D {dn dir} -c "log_statement = all" gs_guc reload -D {dn dir} -c "log_min_duration_statement = 0 "
When configuring an XA transaction, ss executes the XA statement on each openGauss node within the transaction. But currently openGauss does not support executing XA statements on the read database, which should be a problem that openGauss needs to solve, I think.
Bug Report
For English only, other languages will not accept.
Before report a bug, make sure you have:
Please pay attention on issues you submitted, because we maybe need more details. If no response anymore and we cannot reproduce it on current information, we will close it.
Please answer these questions before submitting your issue. Thanks!
Which version of ShardingSphere did you use?
we find java version: java8, full_version=1.8.0_342, full_path=/home/peilq_sharding/bisheng-jdk1.8.0_342//bin/java ShardingSphere-5.2.1-SNAPSHOT Commit ID: dirty-4114e7ee4cbe5923c2b403a3e86d1f23355cadf3 Commit Message: Fix parse exception when execute insert statement with negative value (#21197) Branch: 4114e7ee4cbe5923c2b403a3e86d1f23355cadf3 Build time: 2022-09-27T16:37:07+0800
we find java version: java8, full_version=1.8.0_282, full_path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64/bin/java ShardingSphere-5.2.1-SNAPSHOT Commit ID: dirty-bcde6f374c4a3a025173fbc9f6d0e66ed686a042 Commit Message: Fix fetch forward all error in openGauss(#21421) (#21471) Branch: bcde6f374c4a3a025173fbc9f6d0e66ed686a042 Build time: 2022-10-11T19:13:56+0800
Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
ShardingSphere-Proxy
Expected behavior
In READWRITE_SPLITTING mode,transaction commit is normal
Actual behavior
READWRITE_SPLITTING DB
Reason analyze (If you can)
Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
Example codes for reproduce this issue (such as a github link).