数据库如何实现平滑迁移

gh-ost 是 GitHub 发布的一款用于 MySQL 的无触发器在线模式迁移解决方案。它是可测试的，并提供暂停，动态控制/重新配置，审计和许多操作特权。它在整个迁移过程中，对主服务器产生的工作量很少，与已迁移表上的现有工作分离。
gh-ost与所有现有的在线模式更改工具都以类似的方式操作：它们以与原始表相似的方式创建幽灵表，将数据从原始表缓慢且增量地复制到幽灵表，同时应用正在进行的更改（INSERT，DELETE，UPDATE）到幽灵表。最后，在适当的时候，它用幽灵表替换了原始表。gh-ost使用相同的模式。但是，它与所有现有工具的不同之处在于不使用触发器。取而代之的是，gh-ost使用二进制日志流捕获表的更改，然后将其异步应用到幽灵表。
gh-ost 承担一些其他工具留给数据库执行的任务。gh-ost 可以更好地控制迁移过程；可以真正暂停它；可以真正将迁移的写入负载与主服务器的工作负载分离。此外，它还提供了许多可操作的特权，使其更安全、可信赖且易于使用。

数据库迁移
MySQL数据库迁移(数据文件直接迁移)
在今年10月下旬的时候，公司的服务器需要迁移，其中涉及到了MySQL数据库迁移。查看了一下MySQL数据文件的大小，接近60G的大小(实际数据并没用那么多)。由于服务器上业务需要，要尽量减少服务器迁移时的损失。所以迁移时间选在了晚上零点开始，而且要尽量减少迁移所用的时间。
在迁移之前有三种方案：
数据库直接导出，拷贝文件到新服务器，在新服务器上导入。
使用【MySQL GUI Tools】中的 MySQLMigrationTool。
数据文件和库表结构文件直接拷贝到新服务器，挂载到同样配置的MySQL服务下。
我在我的电脑上用虚拟机测试后，选中了占用时间最少的第三种方案。下面是三种方案的对比：

第一种方案的优点:会重建数据文件，减少数据文件的占用空间。
第一种方案的缺点:时间占用长。(导入导出都需要很长的时间，并且导出后的文件还要经过网络传输，也要占用一定的时间。)
第二种方案的优点：设置完成后传输无人值守
第二种方案的缺点：
设置繁琐。
传输中网络出现异常，不能及时的被发现，并且会一直停留在数据传输的状态不能被停止，如不仔细观察不会被发现异常。
传输相对其他fang时间长。
异常后很难从异常的位置继续传输。
第三种方案的优点：时间占用短，文件可断点传输。操作步骤少。（绝大部分时间都是在文件的网络传输）
第三种方案的缺点：可能引起未知问题，暂时未发现。
下面介绍一下第三种方案d迁移步骤：
保证Mysql版本一致，安装配置基本一致（注意：这里的数据文件和库表结构文件都指定在同一目录data下）
停止两边的Mysql服务（A服务器--迁移-->B服务器)
删除B服务器Mysql的data目录下所有文件
拷贝A服务器Mysql的data目录下除了ib_logfile和.err之外的文件到B服务器data下
启动B服务器的Mysql服务，检测是否发生异常
迁移完成后，服务启动正常，未发现其他异常问题。

备注：经测试，源mysql的安装目录及数据文件目录 可以与 目标Mysql的安装目录及数据文件目录 不一致。
此时，只需要拷贝您所需移动的dbname（如上：pa、testdb）及'mysql'和'ibdata1'，即可。