This is an automated email from the ASF dual-hosted git repository.
panjuan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git
The following commit(s) were added to refs/heads/master by this push:
new 6ce2654 Use readwrite-splitting instead of replica query (#13122)
6ce2654 is described below
commit 6ce26548f28fd824e37efeba8064555bcabf4a77
Author: Haoran Meng <[email protected]>
AuthorDate: Tue Oct 19 12:46:20 2021 +0800
Use readwrite-splitting instead of replica query (#13122)
---
docs/document/content/concepts/pluggable/_index.en.md | 2 +-
.../features/governance/management/registry-center.en.md | 2 +-
.../document/content/features/readwrite-splitting/_index.cn.md | 2 +-
.../document/content/features/readwrite-splitting/_index.en.md | 10 +++++-----
.../content/features/readwrite-splitting/concept.en.md | 2 +-
.../content/features/readwrite-splitting/use-norms.en.md | 6 +++---
docs/document/content/features/sharding/_index.en.md | 4 ++--
.../content/features/sharding/concept/configuration.en.md | 2 +-
.../document/content/features/sharding/principle/execute.en.md | 2 +-
.../content/features/test-engine/integration-test.en.md | 2 +-
.../content/features/test-engine/performance-test.en.md | 8 ++++----
.../user-manual/shardingsphere-jdbc/configuration/_index.en.md | 2 +-
.../shardingsphere-jdbc/configuration/yaml/_index.en.md | 2 +-
.../shardingsphere-jdbc/usage/sharding/_index.en.md | 2 +-
.../shardingsphere-proxy/configuration/_index.en.md | 2 +-
.../user-manual/shardingsphere-proxy/usage/startup.en.md | 2 +-
16 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/docs/document/content/concepts/pluggable/_index.en.md
b/docs/document/content/concepts/pluggable/_index.en.md
index c95ea73..a1f43fa 100644
--- a/docs/document/content/concepts/pluggable/_index.en.md
+++ b/docs/document/content/concepts/pluggable/_index.en.md
@@ -17,7 +17,7 @@ It needs to make each module decouple to independent and
imperceptible to each o
Design an architecture to completely isolate each function, not only can
stimulate the enthusiasm of the open source community, but also can guarantee
the quality of the project.
Apache ShardingSphere begin to focus on pluggable architecture from version
5.x, features can be embedded into project flexibility.
-Currently, the features such as data sharding, replica query, data encrypt,
shadow database,
+Currently, the features such as data sharding, readwrite-splitting, data
encrypt, shadow database,
and SQL dialects / database protocols such as MySQL, PostgreSQL, SQLServer,
Oracle supported are all weaved by plugins.
Developers can customize their own ShardingSphere just like building lego
blocks.
There are lots of SPI extensions for Apache ShardingSphere now and increase
continuously.
diff --git
a/docs/document/content/features/governance/management/registry-center.en.md
b/docs/document/content/features/governance/management/registry-center.en.md
index ebe2824..734a5f9 100644
--- a/docs/document/content/features/governance/management/registry-center.en.md
+++ b/docs/document/content/features/governance/management/registry-center.en.md
@@ -176,7 +176,7 @@ Zookeeper command is as follows:
### Disable Replica Database
-Under replica query scenarios, users can write `DISABLED` (case insensitive)
to sub-nodes of data source name to disable replica database sources. Delete
`DISABLED` or the node to enable it.
+Under readwrite-splitting scenarios, users can write `DISABLED` (case
insensitive) to sub-nodes of data source name to disable replica database
sources. Delete `DISABLED` or the node to enable it.
Zookeeper command is as follows:
diff --git a/docs/document/content/features/readwrite-splitting/_index.cn.md
b/docs/document/content/features/readwrite-splitting/_index.cn.md
index c7365d4..590ca62 100644
--- a/docs/document/content/features/readwrite-splitting/_index.cn.md
+++ b/docs/document/content/features/readwrite-splitting/_index.cn.md
@@ -30,4 +30,4 @@ chapter = true
## 目标
-**透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是ShardingSphere读写分离模块的主要设计目标。**
+**透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是 ShardingSphere 读写分离模块的主要设计目标。**
diff --git a/docs/document/content/features/readwrite-splitting/_index.en.md
b/docs/document/content/features/readwrite-splitting/_index.en.md
index 3b848c3..39ee86a 100644
--- a/docs/document/content/features/readwrite-splitting/_index.en.md
+++ b/docs/document/content/features/readwrite-splitting/_index.en.md
@@ -1,6 +1,6 @@
+++
pre = "<b>4.3. </b>"
-title = "Replica query"
+title = "Readwrite-splitting"
weight = 3
chapter = true
+++
@@ -11,18 +11,18 @@ With increasing system TPS, database capacity has faced
great bottleneck effect.
One primary database with multiple replica databases can further enhance
system processing capacity by distributing queries evenly into multiple data
replicas. Multiple primary databases with multiple replica databases can
enhance not only system throughput but also system availability. Therefore, the
system can still function normally, even though any database is down or
physical disk is destroyed.
-Different from the horizontal sharding that separates data to all nodes
according to sharding keys, replica query routes read operations and write
operations separately to the primary database and the replica database
according to SQL meaning analysis.
+Different from the horizontal sharding that separates data to all nodes
according to sharding keys, readwrite-splitting routes read operations and
write operations separately to the primary database and the replica database
according to SQL meaning analysis.
-Data in replica query split nodes is consistent, whereas that in horizontal
shards is not. The combined use of horizontal sharding and replica query will
effectively enhance the system performance.
+Data in readwrite-splitting nodes is consistent, whereas that in horizontal
shards is not. The combined use of horizontal sharding and readwrite-splitting
will effectively enhance the system performance.
## Challenges
-Though replica query can enhance system throughput and availability, it also
brings inconsistent data, including that between multiple primary databases and
between primary databases and replica databases. What's more, it also brings
the same problem as data sharding, complicating app developer and operator's
maintenance and operation. The following picture has shown the complex
topological relations between applications and database groups when sharding
table and database used together [...]
+Though readwrite-splitting can enhance system throughput and availability, it
also brings inconsistent data, including that between multiple primary
databases and between primary databases and replica databases. What's more, it
also brings the same problem as data sharding, complicating app developer and
operator's maintenance and operation. The following picture has shown the
complex topological relations between applications and database groups when
sharding table and database used tog [...]
## Goal
-**The main design goal of the replica query modular of ShardingSphere is to
try to reduce the influence of replica query, in order to let users use replica
query database group like one database.**
\ No newline at end of file
+**The main design goal of the readwrite-splitting modular of ShardingSphere is
to try to reduce the influence of readwrite-splitting, in order to let users
use primary-replica database group like one database.**
\ No newline at end of file
diff --git a/docs/document/content/features/readwrite-splitting/concept.en.md
b/docs/document/content/features/readwrite-splitting/concept.en.md
index bd22f62..59cee54 100644
--- a/docs/document/content/features/readwrite-splitting/concept.en.md
+++ b/docs/document/content/features/readwrite-splitting/concept.en.md
@@ -15,7 +15,7 @@ It refers to the database used in data query. It supports
multiple replica datab
## Primary Replica Replication
It refers to the operation to asynchronously replicate data from the primary
database to the replica database.
-Because of replica query asynchronization, there may be short-time data
inconsistency between them.
+Because of the asynchrony of primary-replica synchronization, there may be
short-time data inconsistency between them.
## Load Balance Strategy
diff --git a/docs/document/content/features/readwrite-splitting/use-norms.en.md
b/docs/document/content/features/readwrite-splitting/use-norms.en.md
index b98ae2d..6fbc87f 100644
--- a/docs/document/content/features/readwrite-splitting/use-norms.en.md
+++ b/docs/document/content/features/readwrite-splitting/use-norms.en.md
@@ -6,8 +6,8 @@ weight = 2
## Supported Items
-* Provide the replica query configuration of one primary database with
multiple replica databases, which can be used alone or with sharding table and
database;
-* Support SQL pass-through in independent use of replica query;
+* Provide the readwrite-splitting configuration of one primary database with
multiple replica databases, which can be used alone or with sharding table and
database;
+* Support SQL pass-through in independent use of readwrite-splitting;
* Forcible primary database route based on SQL Hint;
## Unsupported Items
@@ -16,7 +16,7 @@ weight = 2
* Data inconsistency caused by replication delay between databases;
* Double or multiple primary databases to provide write operation;
* The data for transaction across primary and replica nodes are inconsistent.
-In the replica query model, the primary nodes need to be used for both reading
and writing in the transaction.
+In the readwrite-splitting model, the primary nodes need to be used for both
reading and writing in the transaction.
## Optional Items
diff --git a/docs/document/content/features/sharding/_index.en.md
b/docs/document/content/features/sharding/_index.en.md
index 12ff21b..e970728 100644
--- a/docs/document/content/features/sharding/_index.en.md
+++ b/docs/document/content/features/sharding/_index.en.md
@@ -11,13 +11,13 @@ The traditional solution that stores all the data in one
concentrated node has h
In performance, the relational database mostly uses B+ tree index. When the
data amount exceeds the threshold, deeper index will increase the disk IO
access number, and thereby, weaken the performance of query. In the same time,
high concurrency requests also make the centralized database to be the greatest
limitation of the system.
-In availability, capacity can be expanded at a relatively low cost and any
extent with stateless service, which can make all the pressure, at last, fall
on the database. But the single data node or simple replica query structure has
been harder and harder to take these pressures. Therefore, database
availability has become the key to the whole system.
+In availability, capacity can be expanded at a relatively low cost and any
extent with stateless service, which can make all the pressure, at last, fall
on the database. But the single data node or simple primary-replica structure
has been harder and harder to take these pressures. Therefore, database
availability has become the key to the whole system.
From the aspect of operation costs, when the data in a database instance has
reached above the threshold, DBA’s operation pressure will also increase. The
time cost of data backup and data recovery will be more uncontrollable with
increasing amount of data. Generally, it is a relatively reasonable range for
the data in single database case to be within 1TB.
Under the circumstance that traditional relational databases cannot satisfy
the requirement of the Internet, there are more and more attempts to store the
data in native distributed NoSQL. But its incompatibility with SQL and
imperfection in ecosystem block it from defeating the relational database in
the competition, so the relational database still holds an unshakable position.
-Sharding refers to splitting the data in one database and storing them in
multiple tables and databases according to some certain standard, so that the
performance and availability can be improved. Both methods can effectively
avoid the query limitation caused by data exceeding affordable threshold.
What’s more, database sharding can also effectively disperse TPS. Table
sharding, though cannot ease the database pressure, can provide possibilities
to transfer distributed transactions to l [...]
+Sharding refers to splitting the data in one database and storing them in
multiple tables and databases according to some certain standard, so that the
performance and availability can be improved. Both methods can effectively
avoid the query limitation caused by data exceeding affordable threshold.
What’s more, database sharding can also effectively disperse TPS. Table
sharding, though cannot ease the database pressure, can provide possibilities
to transfer distributed transactions to l [...]
Splitting data through database sharding and table sharding is an effective
method to deal with high TPS and mass amount data system, because it can keep
the data amount lower than the threshold and evacuate the traffic.
Sharding method can be divided into vertical sharding and horizontal sharding.
diff --git
a/docs/document/content/features/sharding/concept/configuration.en.md
b/docs/document/content/features/sharding/concept/configuration.en.md
index 906ec53..afa6929 100644
--- a/docs/document/content/features/sharding/concept/configuration.en.md
+++ b/docs/document/content/features/sharding/concept/configuration.en.md
@@ -5,7 +5,7 @@ weight = 3
## Sharding Rule
-The main entrance for Sharding rules includes the configurations of data
source, tables, binding tables and replica query.
+The main entrance for Sharding rules includes the configurations of data
source, tables, binding tables and readwrite-splitting.
## Data Sources Configuration
diff --git a/docs/document/content/features/sharding/principle/execute.en.md
b/docs/document/content/features/sharding/principle/execute.en.md
index 7ba9a8c..a7e5090 100644
--- a/docs/document/content/features/sharding/principle/execute.en.md
+++ b/docs/document/content/features/sharding/principle/execute.en.md
@@ -70,7 +70,7 @@ For example, suppose one query needs to acquire two database
connections from a
To avoid the deadlock, ShardingSphere will go through synchronous processing
when acquiring database connection. When creating execution units, it acquires
all the database connections that this SQL requires for once with atomic method
and reduces the possibility of acquiring only part of the resources. Due to the
high operation frequency, locking the connection each time when acquiring it
can decrease ShardingSphere's concurrency. Therefore, it has improved two
aspects here:
1. Avoid the setting that locking only takes one database connection each
time. Because under this kind of circumstance, two requests waiting for each
other will not happen, so there is no need for locking.
-Most OLTP operations use sharding keys to route to the only data node, which
will make the system in a totally unlocked state, thereby improve the
concurrency efficiency further. In addition to routing to a single shard,
replica query also belongs to this category.
+Most OLTP operations use sharding keys to route to the only data node, which
will make the system in a totally unlocked state, thereby improve the
concurrency efficiency further. In addition to routing to a single shard,
readwrite-splitting also belongs to this category.
2. Only aim at MEMORY_STRICTLY mode to lock resources. When using
CONNECTION_STRICTLY mode, all the query result sets will release database
connection resources after loading them to the memory, so deadlock wait will
not appear.
diff --git a/docs/document/content/features/test-engine/integration-test.en.md
b/docs/document/content/features/test-engine/integration-test.en.md
index 58c4f92..50f48c1 100644
--- a/docs/document/content/features/test-engine/integration-test.en.md
+++ b/docs/document/content/features/test-engine/integration-test.en.md
@@ -5,7 +5,7 @@ weight = 1
+++
The SQL parsing unit test covers both SQL placeholder and literal dimension.
-Integration test can be further divided into two dimensions of strategy and
JDBC; the former one includes strategies as Sharding, table Sharding, database
Sharding, and replica query while the latter one includes `Statement` and
`PreparedStatement`.
+Integration test can be further divided into two dimensions of strategy and
JDBC; the former one includes strategies as Sharding, table Sharding, database
Sharding, and readwrite-splitting while the latter one includes `Statement` and
`PreparedStatement`.
Therefore, one SQL can drive 5 kinds of database parsing * 2 kinds of
parameter transmission modes + 5 kinds of databases * 5 kinds of Sharding
strategies * 2 kinds of JDBC operation modes = 60 test cases, to enable
ShardingSphere to achieve the pursuit of high quality.
diff --git a/docs/document/content/features/test-engine/performance-test.en.md
b/docs/document/content/features/test-engine/performance-test.en.md
index df66387..68a9377 100644
--- a/docs/document/content/features/test-engine/performance-test.en.md
+++ b/docs/document/content/features/test-engine/performance-test.en.md
@@ -6,7 +6,7 @@ weight = 4
## Target
-The performance of ShardingSphere-JDBC, ShardingSphere-Proxy and MySQL would
be compared here. INSERT & UPDATE & DELETE which regarded as a set of
associated operation and SELECT which focus on sharding optimization are used
to evaluate performance for the basic scenarios (single route, replica query &
encrypt & sharding, full route). While another set of associated operation,
INSERT & SELECT & DELETE, is used to evaluate performance for replica query.
+The performance of ShardingSphere-JDBC, ShardingSphere-Proxy and MySQL would
be compared here. INSERT & UPDATE & DELETE which regarded as a set of
associated operation and SELECT which focus on sharding optimization are used
to evaluate performance for the basic scenarios (single route,
readwrite-splitting & encrypt & sharding, full route). While another set of
associated operation, INSERT & SELECT & DELETE, is used to evaluate performance
for readwrite-splitting.
To achieve the result better, these tests are performed with jmeter which
based on a certain amount of data with 20 concurrent threads for 30 minutes,
and one MySQL has been deployed on one machine, while the scenario of MySQL
used for comparison is deployed on one machine with one instance.
## Test Scenarios
@@ -16,12 +16,12 @@ To achieve the result better, these tests are performed
with jmeter which based
On the basis of one thousand data volume, four databases that are deployed on
the same machine and each contains 1024 tables with `id` used for database
sharding and `k` used for table sharding are designed for this scenario, single
route select sql statement is chosen here.
While as a comparison, MySQL runs with INSERT & UPDATE & DELETE statement and
single route select sql statement on the basis of one thousand data volume.
-### Replica Query
+### Readwrite-splitting
One primary database and one replica database, which are deployed on different
machines, are designed for this scenario based on ten thousand data volume.
While as a comparison, MySQL runs with INSERT & SELECT & DELETE sql statement
on the basis of ten thousand data volume.
-### Replica Query & Encrypt & Sharding
+### Readwrite-splitting & Encrypt & Sharding
On the basis of one thousand data volume, four databases that are deployed on
different machines and each contains 1024 tables with `id` used for database
sharding, `k` used for table sharding, `c` encrypted with aes and `pad`
encrypted with md5 are designed for this scenario, single route select sql
statement is chosen here.
While as a comparison, MySQL runs with INSERT & UPDATE & DELETE statement and
single route select sql statement on the basis of one thousand data volume.
@@ -155,7 +155,7 @@ rules:
- replica_ds_0
```
-#### Replica Query & Encrypt & Sharding Configuration
+#### Readwrite-splitting & Encrypt & Sharding Configuration
```yaml
schemaName: sharding_db
diff --git
a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md
b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md
index 27fe0bb..ad709de 100644
---
a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md
+++
b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/_index.en.md
@@ -11,7 +11,7 @@ through which developers can quickly and clearly understand
the functions provid
This chapter is a configuration manual for ShardingSphere-JDBC, which can also
be referred to as a dictionary if necessary.
ShardingSphere-JDBC has provided 4 kinds of configuration methods for
different situations.
-By configuration, application developers can flexibly use data sharding,
replica query, data encryption, shadow database or the combination of them.
+By configuration, application developers can flexibly use data sharding,
readwrite-splitting, data encryption, shadow database or the combination of
them.
Mixed rule configurations are very similar to single rule configuration,
except for the differences from single rule to multiple rules.
diff --git
a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md
b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md
index a8909fa..1b12384 100644
---
a/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md
+++
b/docs/document/content/user-manual/shardingsphere-jdbc/configuration/yaml/_index.en.md
@@ -74,7 +74,7 @@ schemaName: sharding_db
### Data Source Configuration
It is divided into single data source configuration and multi data source
configuration.
-Single data source configuration used for data encryption rules; and multi
data source configuration used for fragmentation, replica query and other rules.
+Single data source configuration used for data encryption rules; and multi
data source configuration used for fragmentation, readwrite-splitting and other
rules.
If features such as encryption and sharding are used in combination, a multi
data source configuration should be used.
#### Single Data Source Configuration
diff --git
a/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md
b/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md
index 759483f..bde5cee 100644
---
a/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md
+++
b/docs/document/content/user-manual/shardingsphere-jdbc/usage/sharding/_index.en.md
@@ -6,7 +6,7 @@ chapter = true
Data sharding is the basic capability of Apache ShardingSphere.
This section uses data sharding as an example.
-The usage of functions such as replica query, data encryption, shadow database
is completely consistent with data sharding, as long as the corresponding rules
are configured.
+The usage of functions such as readwrite-splitting, data encryption, shadow
database is completely consistent with data sharding, as long as the
corresponding rules are configured.
Multiple rules can be appended.
Please refer to [Configuration
Manual](/en/user-manual/shardingsphere-jdbc/configuration/) for more details.
diff --git
a/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md
b/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md
index eab4018..4118661 100644
---
a/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md
+++
b/docs/document/content/user-manual/shardingsphere-proxy/configuration/_index.en.md
@@ -10,6 +10,6 @@ through which developer can quickly and clearly understand
the functions provide
This chapter is a configuration manual for ShardingSphere-Proxy, which can
also be referred to as a dictionary if necessary.
ShardingSphere-Proxy only provided YAML configuration.
-By configuration, application developers can flexibly use data sharding,
replica query, data encryption, shadow database or the combination of them.
+By configuration, application developers can flexibly use data sharding,
readwrite-splitting, data encryption, shadow database or the combination of
them.
Rule configuration keeps consist with YAML configuration of
ShardingSphere-JDBC.
diff --git
a/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md
b/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md
index c262676..48066ef 100644
--- a/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md
+++ b/docs/document/content/user-manual/shardingsphere-proxy/usage/startup.en.md
@@ -7,7 +7,7 @@ weight = 1
1. Download the latest version of ShardingSphere-Proxy.
1. If users use docker, they can execute `docker pull
shardingsphere/shardingsphere-proxy` to get the image. Please refer to [Docker
Image](/en/user-manual/shardingsphere-proxy/docker/) for more details.
-1. After the decompression, revise `conf/server.yaml` and documents begin with
`config-` prefix, `conf/config-xxx.yaml` for example, to configure sharding
rules and replica query rules. Please refer to [Configuration
Manual](/en/user-manual/shardingsphere-proxy/configuration/) for the
configuration method.
+1. After the decompression, revise `conf/server.yaml` and documents begin with
`config-` prefix, `conf/config-xxx.yaml` for example, to configure sharding
rules and readwrite-splitting rules. Please refer to [Configuration
Manual](/en/user-manual/shardingsphere-proxy/configuration/) for the
configuration method.
1. Please run `bin/start.sh` for Linux operating system; run `bin/start.bat`
for Windows operating system to start ShardingSphere-Proxy. To configure start
port and document location, please refer to [Quick
Start](/en/quick-start/shardingsphere-proxy-quick-start/).
## Using PostgreSQL
