数据迁移

这一章节主要介绍如何将数据从单实例MySQL迁移到TenDB Cluster集群,或将TenDB Cluster集群数据迁移到单实例MySQL。

从单机MySQL迁移到集群

当单机MySQL不足以承载更多的吞吐时,我们经常会通过分库分表、迁移部分库表到其他实例、优化应用SQL、升级硬件等方式来满足应用需求,但是这些方式不仅操作起来比较复杂,有些场景并不具备可行性,而且并没有从根本上解决问题,只是暂时缓解了压力。在这种情况下,我们可以评估考虑将应用迁移到集群方案,充分利用集群的可扩展性来解决单机MySQL性能瓶颈问题的问题,做到一劳永逸。

可行性检查

在迁移到集群之前,需要对当前单机数据进行一定的检查,确保满足接入集群条件,例如建表约束合法性、是否大量存在跨分片操作,大量分布式事务等。 这些特性要求,一方面是集群本身架构上的限制约束,另一方面是从性能等场景考虑。应用接入集群后,一方面是想快捷使用集群的扩缩容等特性,但根本出发点还是希望提供比单机MySQL更高的吞吐能力。 具体一些集群的限制约束参考与单实例MySQL的异同
另外我们需要考虑应用的使用特性,例如是否有使用名字服务、负载均衡,连接重连机制等,如果要求不影响服务的情况下在线迁移到集群,这些特性需要仔细评估,以防在线切换到集群时造成短暂的服务不可用。

集群搭建

参考集群部署章节

导入库表

在单机MySQL上使用mysqldump等命令备份表结构,将备份的表结构通过TSpider节点导入到整个集群

导入数据

在单机MySQL上使用mysqldump备份数据(忽略表结构),连接集群的任意TSpider节点,将数据通过TSpider导入整个集群。 一般建议给集群增加一个高配置的临时TSpider节点,磁盘空间、CPU、内存都与单机MySQL相对接近,这样能有效提高导入数据的性能。

切换服务

当数据导入完成后,就需要考虑将应用服务从单机MySQL切换到集群。根据应用需求,我们可以采用在线切换和离线切换两种方式

在线切换

在线切换是指在不影响应用请求的情况下,将服务从单机MySQL切换到集群方案
在线切换的前置要求是单机MySQL的增量数据一直实时写入到集群,这样才能保证在切换前后,数据的一致性

  • 配置主从复制

    在全备数据导入完成后,我们可以在选取导入数据的临时TSpider节点,配置MySQL主从复制的环境,从单机MySQL同步数据到TSpider节点。
    TSpider做Slave时,复制相关的配置参数与单机MySQL使用没有区别,适当修改主从复制相关参数后重启TSpider节点, 执行change mastero to语句(一致性点通过备份获取)

  • 开启主从同步

    在配置主从复制环境的TSpider节点执行start slave开启同步,TSpider从单机MySQL拉取增量数据跟进,最终达到一致性

  • 在线切换

    在TSpider节点执行show slave status, 查看同步情况,确保没有同步落后或同步错误
    连接单机MySQL节点,执行flush tables with read lock,临时阻塞整个业务的写请求,然后通过修改名字服务等方式,让应用配置能解析连接到集群的TSpider节点,在配置修改生效后,可以看到新的请求已经访问到TSpider集群 如果应用没有使用名字服务等方式,直接通过ip连接请求的,需要将应用配置的ip信息修改为TenDB Cluster集群的TSpider信息,另外需要考虑应用的重连机制,防止切换后影响服务
    应用如果有耗时较长的写入操作,flush tables with read lock可能会导致锁时间较长或失败,影响服务,在这种情况下要及时执行unlock tables释放锁,恢复应用请求;待耗时写入较长的操作完成或终止后,再尝试切换
    在切换成功后,旧的单机MySQL最好及时关闭服务,以防连接缓存等未知因素依旧请求到旧服务而数据异常

离线切换

离线切换,是指在应用停止写入请求后,将服务从单机MySQL切换到集群方案
相比在线切换,离线切换的流程则要简单很多,根据应用对停止服务时间的容忍度不同,又分为冷切换和热切换

  • 冷切换

    冷切换是指先关闭单机MySQL的写请求,然后开启备份,再将备份的全量数据通过TSpider节点导入集群,导入完成后修改应用的连接请求信息(或名字服务),开启服务

  • 热切换

    热切换与在线切换流程大致相同,也是通过配置主从切换的方式来同步数据,唯一区别是在切换时,不是通过全局读锁的方式来完成切换,而是直接停止应用的写请求,修改应用的连接配置。在TSpider的数据同步落后完成,配置生效后,再开启应用的写入服务

其他说明

不论是在线切换、还是离线切换,一定要确保数据一致性再切换。在切换前,要检查TSpider的权限,应用配置,防止切换后因为权限、配置异常导致服务异常
对于在线切换,切换时长将直接影响应用不可写的时间。除了前面提到的耗时较长操作可能影响加锁时长外,配置文件的生效时间,负载均衡、名字服务等生效时长,应用重连机制等都会影响切换时长,需要充分评估这些时间对整个切换方案带来的不确定性

从集群迁移到单机MySQL

在有些场景,我们存在将数据从集群迁移到单机MySQL的需求
从集群到单机MySQL,我们通过数据备份、导入、切换来完成

数据备份

不同于单机MySQL的数据存储,集群数据按照一定的分片规则分布在各个TenDB存储节点,而且库表结构也发生了一些变化

备份库表schema

集群上,库表结构在TSpider和TenDB节点都存在,不过有一定的差异性, 具体变化规则可以参考创表说明
了解了集群库表的创建规则后,备份schema时我们可以选择在任意TSpider节点或TenDB节点备份,备份后基于原来的规则逆操作修改因为集群引入的变化即可。
考虑到TenDB节点除了库名有变化外,表结构与单机完全相同,因此我们选择在TenDB节点备份修改schema;
使用mysqldump备份完库表结构后,此时的schema是不符合我们使用需求的,我们还需要修改库名。例如单机库名为test,那么在 分片0 上,库名会被Tdbctl重写为test_0; 在 分片1 上,库名会被重写为test_1。如果我们选择 分片0 备份,我们可以通过简单的正则替换等方式将匹配到的 _0 去掉,获取正确的库名test
集群生成库名的规则,在集群建立,TenDB分片个数(mysql.servers)确定后,是不会再发生变化的。因此我们基于分片规则来替换获取正确的库名,是可信赖的。
实际使用时,我们可以扩展mysqldump,或基于mysqldump集成一套集群的备份恢复工具,简化我们的日常操作

备份数据

由于集群数据是分布在各个TenDB存储节点,因此我们需要只能从TSpider节点导出数据,导出数据时的需要考虑的点与导入数据大致相同

服务切换

在从集群切换到MySQL时候,除了前面提到的需要考虑的名字服务、应用配置、重连机制等注意点外,我们还要确保数据的一致性。
目前我们推荐的方案是停机操作,在停止应用接入后再备份、导入数据
如果单机MySQL支持多源复制等特性,可以考虑使用单机MySQL作为Slave,各TenDB为Master的方式来同步数据增量数据,最终在接入层加读锁方式来在线切换。

results matching ""

    No results matching ""