menghaoranss opened a new issue, #15113:
URL: https://github.com/apache/shardingsphere/issues/15113
## background
We can use DistSQL to create/drop/alter ... data sources and rules since
5.x, and these changes are effective immediately, so ShardingSphere has to
refresh the meta data for each execution. In registry center, the
configurations persisted in single node just as follows, once modified, they
will be overwritten and there's no way to rollback.
```
namespace:
metadata:
sharding_db:
dataSources
rules
tables
```
There are some problems for batch execution scenarios of DistSQL:
1. Batch execution scenario involves frequent metadata refresh, which will
greatly affect the performance, and without the support of distributed locks,
the metadata may be incorrect
2. It is not friendly to scaling scenario. At present, modifying the
configuration directly triggers the scaling task, batch execution will trigger
scaling task frequently
3. Execution cannot be terminated
## design
Consider designing a new syntax to support delayed entry into force for
batch execution of DistSQL, the snapshot configuration will be persisted to
registry center until apply it.
1. `PREPARE DISTSQL; `
Start a new version control for DistSQL, any DistSQL executed after this
statement will not take effect immediately. If non-DistSQL is executed at this
time, an exception will be thrown directly.
2. `APPLY DISTSQL; `
Apply all executed DistSQL and refresh meta data now.
3. `DISCARD DISTSQL; `
Discard all executed DistSQL before applying.
## task list
- [ ] support `PREPARE DISTSQL; `
- [ ] support `APPLY DISTSQL; `
- [ ] support `DISCARD DISTSQL; `
- [x] provide API for above syntax, and refactor the registry center data
structure
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
[email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
