RaigorJiang opened a new issue, #24338:
URL: https://github.com/apache/shardingsphere/issues/24338
## Feature Request
### Is your feature request related to a problem?
No.
### Describe the feature you would like.
Hi community,
I would like to propose a feature about `backup and restore`.
Now, when users use ShardingSphere to manage distributed databases, they can
back up configuration and data in the following ways:
1. EXPORT DATABASE CONFIGURATION (export logical database configuration,
YAML format)
2. Back up the physical databases separately
However, the above operations also faces the following problems:
1. When users manage multiple database clusters, how do they know which
database instances should be affected by a backup? (Different Proxy/different
logical databases correspond to different physical databases)
2. The export of configuration is much faster than data backup. When
physical databases are being backed up or restored, the configuration of
ShardingSphere may be modified by other users, resulting in a mismatch between
metadata and physical databases (such as UNREGISTER STORAGE UNIT)
3. When the physical databases are being restored, SQL cannot be processed.
At this time, ShardingSphere cannot route SQL statements, can it only throw
exceptions?
In order to improve the above situation, we need to consider the backup and
recovery strategy of the cluster, which may eventually achieve a function
similar to PITR (Point-in-Time Recovery).
As a start, I think we can now provide some help to users in DistSQL:
- [ ] Lock cluster
- [ ] Write lock: Write requests are not executed during backup, and
users can back up the physical databases to a unified level
- [ ] Read-write lock: During recovery, read-write requests are not
routed because the physical database needs to be restarted
- [ ] Unlock cluster
- [ ] Export metadata: more complete than `EXPORT DATABASE CONFIGURATION`,
not only the configuration of one logic database
- [ ] Import metadata: restore metadata, including logic database
configuration and global rules and props etc.
In this way, it should ease the pressure on users to backup and restore.
### References
- MySQL: https://dev.mysql.com/doc/refman/8.0/en/backup-and-recovery.html
- PostgreSQL: https://www.postgresql.org/docs/15/backup.html
- openGauss:
https://docs.opengauss.org/en/docs/3.1.1/docs/Administratorguide/backup-and-restoration.html
--
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]
