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 + sharding-scaling实现不停服分库分表数据迁移_第1张图片

 

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文件夹下

sharding-proxy + sharding-scaling实现不停服分库分表数据迁移_第2张图片

server.yaml是代理服务的配置文件,通过配置authentication属性,可以设定代理服务的访问账号/密码,以及对应账号的数据库访问权限

eg:

sharding-proxy + sharding-scaling实现不停服分库分表数据迁移_第3张图片  这个配置表示配置了两个账号root和sharding,root没有设置数据库权限限制,代表能访问所有库,而sharding账号,则只能访问order库。至于这里的库Schemas,就代表的是proxy对外提供的逻辑库,并不是实际代理的物理库的信息。

config-开头的配置文件,就是对应的规则下的逻辑库和是实际数据源以及规则的配置文件了,注意的是,一个配置文件,配置一个逻辑库。

eg: config-shading2.yaml文件

sharding-proxy + sharding-scaling实现不停服分库分表数据迁移_第4张图片

schemaName: 逻辑库的名称,用于提供给外部客户端访问的库

dataSources: 该逻辑库实际上对应的数据源配置

shardingRule: 分片规则

    tables:表信息

        mysharding:逻辑表名

            actualDataNodes:实际数据节点的配置,图中用行表达式来来配置,映射本逻辑表名和实际表的关系

            databaseStrategy: 分库配置

                line: 采用行表达式

                    shardingColumn: 分库字段

                    algorithmExpression:按照分库字段,数据映射到的实际库的规则

            tableStrategy: 分表配置

                line: 采用行表达式

                    shardingColumn: 分表字段

                    algorithmExpression:按照分表字段,数据映射到的实际表的规则

            keyGennerator: 分布式主键配置

                type: 雪花算法

                column:主键列

以上便是分库分表的配置,代表着,数据将会按照对应规则被分散到实际的数据节点中去。这里只是数据的去向

启动sharding-proxy服务之前,需要注意的是,dataSources的库表,一定要先创建好。

启动后,使用mysql客户端访问,可以看到

sharding-proxy + sharding-scaling实现不停服分库分表数据迁移_第5张图片

逻辑库已经存在,且逻辑表也有,只是目前还没有数据。

开始迁移

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:

sharding-proxy + sharding-scaling实现不停服分库分表数据迁移_第6张图片

 

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

你可能感兴趣的:(笔记,mysql)