前提说明
优先明确一点:数据迁移必须使用DistSQL操作。
ShardingSphere提供的数据迁移方案为:使用全新的数据库集群作为迁移目标。因此,需要冗余的服务器资源支持,并且在数据迁移过程中,所有的数据都会发生移动。
实战内容:将192.168.49.110:3306/user中的t_user表,迁移到192.168.49.119:3306/user中并且进行数据分片。将源端t_user表的数据以user_id为分片键,分布在10张表中。
数据迁移阶段划分
-
准备阶段;
-
存量数据迁移阶段;
-
增量数据同步阶段,提供数据一致性校验;
-
流量切换阶段;
从存量迁移到增量迁移阶段,Proxy组件会自动帮助我们完成过渡。在增量数据迁移阶段,Proxy会不断读取源端写入的最新数据,保持目标端数据和源端数据的基本一致。而数据想要从基本一致过渡到完全一致,需要源端将服务暂时改为只读,之后proxy继续读取源端信息,进而使数据完全同步(有内置的校验规则)。之后,完成线上流量的切换。
1.迁移前准备
-
校验MySQL账号的权限
-
源端账号是否开启binlog、是否拥有replication权限和查询权限。
-
目标端账号是否拥有赋予增删改查、创建索引权限。【不能是ALL PRIVILEGE,要给具体的权限,不然会报错】
-
-
以集群模式启动proxy,并配置Proxy的分片规则
a. 账号权限检查
-- 检查源端是否开启binlog,以及源端账户是否具有replication和Select权限
show variables like 'log_bin'; -- 需要是ON
show variables like 'binlog_format'; -- 需要是ROW
show variables like 'binlog_row_image'; -- 需要是FULL
SHOW GRANTS FOR 'chatbot';
-- 缺少那个权限执行下面那一条命令
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON `chatbot`.* TO 'chatbot'@'%';
GRANT SELECT ON `chatbot`.* TO 'chatbot'@'%';
-- 检查目标端账户的权限,需要DML和索引权限
SHOW GRANTS FOR 'chatbot_shard'@'%';
GRANT CREATE, DROP, INDEX, SELECT, INSERT, UPDATE, DELETE ON 'chatbot_shard'.* TO 'chatbot_shard'@'%';
b. Proxy 配置
启动Proxy
采用zk集群模式进行数据
基于ShardingSphere的数据迁移实战

最低0.47元/天 解锁文章
1960

被折叠的 条评论
为什么被折叠?



