MySQL数据库托管的一点感悟

MySQL数据库托管的一点感悟

开始之前，聊一点题外话，最近好像股市和基金都大跌，我自己买的股票和基金也都跌了。我本身没有这方面的经验，也是小白一个，但是感觉遇到了这种下跌，很容易让人崩溃。之前也有朋友买了很多，那天开玩笑对我说：中午跌的时候，他差点都跳楼了。😄 虽然是句玩笑话，但是从中能够感受到，大家还是很在意亏损的。

有调查显示，亏钱带来的厌恶是赚钱带来的快乐的2倍。举个例子就是：亏损1w块钱对你的影响需要你赚2w块钱才能抵消。我觉得普通人，如果不靠股市发财，就要做到对短期波动置之不理，要做到置之不理，我觉得很重要的就是你的投资比重不能太大。假如你有100块钱，丢了1块钱，我想你可能不会担心，毕竟还有99，假如丢了10块、20块呢？这个时候可能就有点担心了。

所以，还是那句话，用闲钱去投资，这样才能坚持下去，人心是很容易被外界干扰的，如果你做不到对波动置之不理，就按照真实收入，给自己列一个计划，严格按照计划执行投资。这样长期坚持，才有可能获得收益。

以上是来自一颗老韭菜的一点心得。

言归正传，上周五给某个业务方做了一个数据库的托管需求，在整个过程中，不是特别顺畅，这里大概记录下。

01

背景

背景介绍：

业务同学在业务初期，自己维护了一个MySQL数据库，是单实例的。一开始只有几个G数据量，随着业务上量，后面堆积到了2个T数据。

需求：

需要将这2个T的数据库托管到DBA平台的MySQL数据库，并将业务应用切换到新的实例上

方案分析：

这个需求本身操作起来比较简单，分成下面几个步骤：

1、先搭建一套主从复制集群

2、将主库和业务的MySQL实例做主从复制

3、将业务切换到新的MySQL主库上

4、停止业务库和线上MySQL的主从复制即可

如下：

02

操作过程的关键步骤

1、数据备份，查找正确的偏移量

由于业务同学只需要导出部分必要的库表到线上环境，所以我们数据备份的时候，有以下几个点需要注意：

a、库表名单校准。需要指定database参数；

b、存储过程、自定义函数等备份

c、系统表备份。如果是mysqldump等逻辑备份，需要备份mysql表，从而获取账户和权限数据，或者利用pt-show-grants导出账号权限信息；如果是xtrabackup等物理备份，需要备份mysql表和performance_schema等元数据信息。

d、偏移量位置备份。如果使用mysqldump来进行备份，需要使用--master-data参数来保存当前的一致性备份偏移量。

2、主从复制，复制过滤器的配置

由于我们备份了部分数据，所以必然在复制的时候，要配置复制过滤器，复制过滤器需要考虑是否能够支持跨库操作。线上实际选用了replica_wild_ignore_table来将不需要同步的表过滤掉。

3、账号连通性、权限校验

由于我们换了MySQL实例，所以原来能够连接的账号，在新实例上不一定能够连通，例如防火墙权限，网段之间是否互通。

4、业务切换后的双写问题

在业务切换的过程中，可能会出现一种中间状态，就是切换了一半的业务过来，另外一半还在原来的服务上，这样有可能出现双写，从而产生主键冲突问题。此时需要对应的调整每个数据库的自增主键偏移量和自增主键值

5、整个迁移过程中服务的可用性

其实这个问题，更多的是源端可用性问题，因为源端毕竟是单实例的，业务同学能够托管，一定是遇到了某种不可解决的问题，此时源端本身就比较脆弱，需要在迁移过程中重点对待。

03

我们踩的坑

1、业务账号权限问题

原来的账号，业务同学都配置的all privileges

而新的账号按照线上标准，只有增删改查的权限，没有存储过程的执行权限，测试过程中发现线上账号无法查看和调用存储过程。其实这就是账号连通性、权限校验不严格导致的问题。

最终经过排查，授予execute权限之后解决。

2、源端数据库磁盘被写满

本次迁移其实一共操作了2次才成功，第一次操作的时候，迁移过程中，源端MySQL服务器的磁盘满了，业务同学顺手清理了大量的binlog，导致主从复制断开了，重新搭建了一次主从复制，造成了返工现象。

很多需求都是这样，每个操作其实都不是很难，难在这些流程的梳理，步骤的规范，尤其是重大变更中，这一点尤其重要。所以，一种好的办法，就是提前在纸上列好checklist，这样在操作过程中，一项一项对照，才能做到有的放矢，忙中有序。