sharding-proxy + sharding-scaling实现不停服分库分表数据迁移
sharding-proxy + sharding-scaling实现不停服数据迁移
sharding-proxy 的相关理论&使用文档参考官网（https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/sharding-proxy/）
sharding-scaling 的相关理论&使用文档参考官网（https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/sharding-scaling/）
sharding-proxy可以类比于mycat，作为实际数据源的代理，部署为服务，向客户端提供透明的数据库访问。可以结合sharding-scaling来发起数据迁移任务。
准备部署
sharding-proxy
参考官网下载解压，我使用4.1.0
wget https://linux-soft-ware.oss-cn-shenzhen.aliyuncs.com/sharding-proxy-4.1.0.tar.gz
要确认的是
需要先确认数据库MySQL 需要开启binlog，binlog format为Row模式，且迁移时所使用用户需要赋予Replication相关权限(REPLICATION SLAVE, REPLICATION CLIENT)。
在mysql的my.cnf文件中配置
log-bin=mysql-bin
binlog_format=ROW
还需要注意的是，因为是采用主从同步binlog形式来实现增量数据的同步，所以还需要配置mysql服务的server-id（1到2^32–1之间的一个正整数值）
在sharding-proxy服务的conf文件夹下
server.yaml是代理服务的配置文件，通过配置authentication属性，可以设定代理服务的访问账号/密码，以及对应账号的数据库访问权限
eg:
这个配置表示配置了两个账号root和sharding，root没有设置数据库权限限制，代表能访问所有库，而sharding账号，则只能访问order库。至于这里的库Schemas，就代表的是proxy对外提供的逻辑库，并不是实际代理的物理库的信息。
config-开头的配置文件，就是对应的规则下的逻辑库和是实际数据源以及规则的配置文件了，注意的是，一个配置文件，配置一个逻辑库。
eg: config-shading2.yaml文件
schemaName: 逻辑库的名称，用于提供给外部客户端访问的库
dataSources: 该逻辑库实际上对应的数据源配置
shardingRule: 分片规则
tables：表信息
mysharding：逻辑表名
actualDataNodes：实际数据节点的配置，图中用行表达式来来配置，映射本逻辑表名和实际表的关系
databaseStrategy: 分库配置
line: 采用行表达式
shardingColumn： 分库字段
algorithmExpression：按照分库字段，数据映射到的实际库的规则
tableStrategy: 分表配置
line: 采用行表达式
shardingColumn： 分表字段
algorithmExpression：按照分表字段，数据映射到的实际表的规则
keyGennerator: 分布式主键配置
type: 雪花算法
column：主键列
以上便是分库分表的配置，代表着，数据将会按照对应规则被分散到实际的数据节点中去。这里只是数据的去向
启动sharding-proxy服务之前，需要注意的是，dataSources的库表，一定要先创建好。
启动后，使用mysql客户端访问，可以看到
逻辑库已经存在，且逻辑表也有，只是目前还没有数据。
开始迁移
sharding-scaling
参考官网，下载解压后直接启动即可。
wget https://linux-soft-ware.oss-cn-shenzhen.aliyuncs.com/sharding-scaling-4.1.0.tar.gz
sharding-scaling作为迁移任务的发起端，对外提供了http接口
这里直接调用迁移任务的接口：
curl -X POST --url http://127.0.0.1:8888/shardingscaling/job/start \
--header 'content-type: application/json' \
--data '{
"ruleConfiguration": {
"sourceDatasource": "ds_0: !!org.apache.shardingsphere.orchestration.core.configuration.YamlDataSourceConfiguration\n dataSourceClassName: com.zaxxer.hikari.HikariDataSource\n properties:\n jdbcUrl: jdbc:mysql://127.0.0.1:3306/h_db?serverTimezone=UTC&useSSL=false&zeroDateTimeBehavior=convertToNull&characterEncoding=UTF-8\n driverClassName: com.mysql.jdbc.Driver\n username: root\n password: 123456\n connectionTimeout: 30000\n idleTimeout: 60000\n maxLifetime: 180000\n maxPoolSize: 2\n minPoolSize: 1\n maintenanceIntervalMilliseconds: 30000\n readOnly: false\n",
"sourceRule": "tables:\n my_sharding:\n actualDataNodes: ds_0.t_order\n keyGenerator:\n column: order_id\n type: SNOWFLAKE",
"destinationDataSources": {
"name": "dt_1",
"password": "123456",
"url": "jdbc:mysql://127.0.0.1:8080/my_sharding?serverTimezone=UTC&useSSL=false&characterEncoding=UTF-8",
"username": "root"
}
},
"jobConfiguration": {
"concurrency": 1
}
}'
这样看可能不清晰，格式化一下请求的body：
sourceDatasource：配置迁移发起数据库 别名和参数
sourceRule：配置迁移发起库的逻辑映射关系：
tables：逻辑表和逻辑表对应的需要被迁移的表数据节点，以及主键列和迁移的主键生成算法等配置
destinationDataSources：配置任务要迁移到的数据源信息，这里就是指代理服务sharding-proxy
发送请求后就开始了迁移数据。
在任务执行期间，原来的数据库对那个表的增删改查，也会被同步。
这里要注意：发送请求后，返回{"success":true,"errorCode":0,"errorMsg":null,"model":null}只代表请求发送成功，并不代表迁移任务成功，应当调用查询接口查看
curl -X GET \ http://localhost:8888/shardingscaling/job/progress/{jobId}
同时可以通过连接代理数据库来查看或者统计迁移数据的情况，完成后可以stop迁移任务
这里要注意：停止迁移任务后，原来库表的binlog就不会被同步了，所以最好是在分库分表的业务服务上线替换完成后，再进行停止操作。
至此，迁移任务完成。
基于sharding-jdbc分库分表整合seata实现分布式事务：https://blog.csdn.net/HTslide/article/details/108337372