1、数据迁移

1.1 概述

数据迁移（data migration）是指选择、准备、提取和转换数据，并将数据从一个计算机存储系统永久地传输到另一个计算机存储系统的过程。此外， 验证迁移数据的完整性 和 退役原来旧的数据存储 ，也被认为是整个数据迁移过程的一部分。
数据库迁移的原因是多样的，包括服务器或存储设备更换、维护或升级，应用程序迁移，网站集成，灾难恢复和数据中心迁移。
根据不同的需求可能要采取不同的迁移方案，但总体来讲，MySQL 数据迁移方案大致可以分为 物理迁移和 逻辑迁移 两类。通常以尽可能 自动化的方式执行，从而将人力资源从繁琐的任务中解放出来。

1.2 迁移方案

  • 物理迁移

物理迁移适用于大数据量下的整体迁移。使用物理迁移方案的优点是比较快速，但需要停机迁移并且要求 MySQL 版本及配置必须和原服务器相同，也可能引起未知问题。
物理迁移包括拷贝数据文件和使用 XtraBackup 备份工具两种。
不同服务器之间可以采用物理迁移，我们可以在新的服务器上安装好同版本的数据库软件，创建好相同目录，建议配置文件也要和原数据库相同，然后从原数据库方拷贝来数据文件及日志文件，配置好文件组权限，之后在新服务器这边使用 mysqld 命令启动数据库。

  • 逻辑迁移

逻辑迁移适用范围更广，无论是 部分迁移 还是全量迁移 ，都可以使用逻辑迁移。逻辑迁移中使用最多的就是通过 mysqldump等备份工具。

1.3 迁移注意点

1、相同版本的数据库之间迁移注意点
指的是在主版本号相同的MySQL数据库之间进行数据库移动。
方式1： 因为迁移前后MySQL数据库的 主版本号相同 ，所以可以通过复制数据库目录来实现数据库迁移，但是物理迁移方式只适用于MyISAM引擎的表。对于InnoDB表，不能用直接复制文件的方式备份数据库。
方式2： 最常见和最安全的方式是使用 mysqldump命令 导出数据，然后在目标数据库服务器中使用MySQL命令导入。
举例：
#host1的机器中备份所有数据库,并将数据库迁移到名为host2的机器上
mysqldump –h host1 –uroot –p –-all-databases|
mysql –h host2 –uroot –p
在上述语句中，“|”符号表示管道，其作用是将mysqldump备份的文件给mysql命令；“—all-databases”表示要迁移所有的数据库。通过这种方式可以直接实现迁移。
2、不同版本的数据库之间迁移注意点
例如，原来很多服务器使用5.7版本的MySQL数据库，在8.0版本推出来以后，改进了5.7版本的很多缺陷，因此需要把数据库升级到8.0版本
旧版本与新版本的MySQL可能使用不同的默认字符集，例如有的旧版本中使用latin1作为默认字符集，而最新版本的MySQL默认字符集为utf8mb4。如果数据库中有中文数据，那么迁移过程中需要对 默认字符集进行修改 ，不然可能无法正常显示数据。
高版本的MySQL数据库通常都会 兼容低版本 ，因此可以从低版本的MySQL数据库迁移到高版本的MySQL数据库
3、不同数据库之间迁移注意点
不同数据库之间迁移是指从其他类型的数据库迁移到MySQL数据库，或者从MySQL数据库迁移到其他类型的数据库。这种迁移没有普适的解决方法。
迁移之前，需要了解不同数据库的架构，比较它们之间的差异 。不同数据库中定义相同类型的数据的 关键字可能会不同 。
例如，MySQL中日期字段分为DATE和TIME两种，而ORACLE日期字段只有DATE；SQLServer数据库中有ntext、Image等数据类型，MySQL数据库没有这些数据类型；MySQL支持的ENUM和SET类型，这些SQL Server数据库不支持。
另外，数据库厂商并没有完全按照SQL标准来设计数据库系统，导致不同的数据库系统的 SQL语句 有差别。例如，微软的SQL Server软件使用的是T-SQL语句，T-SQL中包含了非标准的SQL语句，不能和MySQL的SQL语句兼容。
不同类型数据库之间的差异造成了互相迁移的困难 ，这些差异其实是商业公司故意造成的技术壁垒。但是不同类型的数据库之间的迁移并 不是完全不可能 。例如，可以使用 MyODBC 实现MySQL和SQL Server之间的迁移。MySQL官方提供的工具 MySQL Migration Toolkit 也可以在不同数据之间进行数据迁移。MySQL迁移到Oracle时，需要使用mysqldump命令导出sql文件，然后， 手动更改 sql文件中的CREATE语句

1.4 迁移小结

如何删库跑路 - 图1

2、删库了不敢跑，能干点啥？

传统得高可用架构是不能预防误删数据的，因为主库的一个drop table命令，会通过binlog传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。
为了解决误删数据的更高效的办法，我们需要先对和Mysql相关的误删数据，做以下分类：
1、使用delete语句误删数据行
2、使用drop table或者truncate table语句误删数据表
3、使用drop database 语句误删数据库
4、使用rm命令误删整个Mysql实例。

2.1 delete：误删行

处理措施1：数据恢复
使用Flashback工具恢复数据。
原理：修改Binlog内容，拿回原库重放。如果误删数据涉及到了多个事务的话，需要将事务的顺序调过来再执行。
使用前提：binlog_format = row 和 binlog_row_image=FULL。
处理措施2：预防

  • 代码上线前，必须SQL审查、审计

  • 建议可以打开安全模式，把sql_safe_updates参数设置为on。强制要求加where条件而且where后需要是索引字段，否则必须使用limit，否则就会报错。

    如果确定要把一个小表的数据全部删掉，在设置了sql_safe_updates=on情况下，可以
    在delete语句中加上where条件，比如where id>=0。

    2.2 truncate/drop ：误删库/表

    背景：
    delete全表是很慢的，需要生成回滚日志，写redo、写binlog。所以，从性能角度考虑，优先考虑使用truncate table或者drop table命令。
    使用delete命令删除的数据，你还可以用Flashback来恢复。而使用truncate/drop table和drop database 命令删除的数据，就没办法通过Fashback来恢复了。因为，即使我们配置了binlog_format=row，执行这三个命令时，记录的binlog还是statement格式。binlog里面就只有一个truncate/drop语句，这些信息是恢复不出数据的。
    方案：
    这种情况下，要想恢复数据，就需要使用 全量备份 ，加 增量日志的方式了。这个方案要求线上有定期的全量备份，并且实时备份binlog
    在这两个条件都具备的情况下，假如有人中午12点误删了一个库，恢复数据的流程如下
    1、取最近一次 全量备份 ，假设这个库是一天一备，上次备份是当天 凌晨2点；
    2、用备份恢复出一个 临时库 ；
    3、从日志备份里面，取出凌晨2点之后的日志；
    4、把这些日志，除了误删除数据的语句外，全部应用到临时库
    5、最后恢复到主库

    2.3 预防使用truuncate/drop 误删库/表

    上面我们说了使用truncate/drop语句误删库/表的恢复方案，在生产环境中可以通过下面建议的方案来尽量避免类似的误操作。
    1、权限分离

  • 限制账户权限，核心数据库，一般都不能随便分配写权限，想要获取写权限需要审批。比如只给业务开发人员DML权限，不给truncate/drop权限。即使是DBA团队成员，日常也都规定只使用只读账号，必要的时候才使用有更新权限的账号。

  • 不同的账号，不同的数据之间要进行权限分离，避免一个账户可以删除所有库

2、制定操作规范
比如在删除数据表之前，必须先对表做改名操作(比如加_to_be_deleted)。然后，观察一段时间，确保对业务无影响后再删除这张表。
3、设置延迟复制备库
简单说延迟复制就是设置一个固定的延迟时间，比如1小时，让从库落后主库一个小时，出现误操作1小时内，到这个备库上执行stop slave，再通过之间介绍的方法，跳过误操作命令，就可以恢复出需要的数据。
这里通过change master to master_delay = N命令，可以指定这个备库持续保持跟主库有N秒的延迟。比如把N设置为36000，即代表1个小时。
延迟复制还可以用来解决以下问题：

  • 用来做延迟测试，比如做好数据读写分离，把从库作为读库，那么想知道数据产生延迟的时候到底会发生什么，就可以使用这个特性模拟延迟。
  • 用于老数据的查询等需求，比如你经常需要 查看某天前的一个表或字段的数值，你可能需要把备份恢复后进行查看，如果有延迟从库，比如延迟一周，那么就可以解决这样类似的需求。

    2.4 rm：误删Mysql实例

    对于一个有高可用机制的MySQL集群来说，不用担心 rm删除数据 了。只是删掉了其中某一个节点的数据的话，HA系统就会开始工作，选出一个新的主库，从而保证整个集群的正常工作。我们要做的就是在这个节点上把数据恢复回来，再接入整个集群。
    但是如果是恶意的把整个集群删除，那就需要考虑跨机房备份，跨城市备份。