记住一点，就是你的数据量不是特别大的话，一台服务器也能全部的装下，除非你需要能保证你的数据的跨数据中心的数据安全，否则你不一定会选择 TiDB 的。你的业务场景需要强一致，并且需要分布式的事务，还想减轻你的运维的负担，希望数据库能够在线的进行扩展，在线的处理故障恢复和在线的进行 DDL 操作的话，数据达到一定量级，那么选择 TiDB 就是一个非常好的解决方案。

整个 TiDB 是分布式的，所以它不仅能处理在线的交易数据，还能处理一部分的业务场景。如果你不想使用 Hadoop 和 Spark 这样的数据分析的引擎，也不想通过 DDL 把数据库进行同步的话，选择 TiDB 的话也可能是一个非常好的解决方案。

怎么使用 TiDB 进行你的业务的迁移呢？这个问题对用户来说也比较重要，因为一个好的周边生态工具，对于你业务的高可用以及安全性的保证来说是非常重要的。这里主要是通过三个工具来实现的：

第一个工具叫做 Syncer，它可以伪装成一个 MySQL slave 这样一个实例。这样的好处就是可以在线的同步 MySQL 的 Binlog 数据，同步到后端的 TiDB 集群里面。

第二个工具是 TiDB-Binlog，这个工具和第一个作用正好完全相反。它的主要功能是可以把TiDB 数据同步成一个 Binlog ，然后输出到其他的存储引擎里面，包括另外一个 TiDB 的集群，或者 MySQL ，或者其他第三方的一些应用。

第三个工具是图里面提到的配套工具 Mydumper 和 Loader 。Mydumper 主要的好处是可以支持多线程。TiDB 在 Myloader 的基础上做了一些优化，主要基于两点，第一点就是让它的存储格式更好的适配 TiDB ，增加更好的并发力度，第二就是可以做故障恢复和断点续传。我们的应用场景里面 TiDB 面对的都是非常大数据量的业务，所以在导数据的时候如果不支持断点续传的话，会非常影响用户的体验。

下面举一个例子说明如何能够做从已有的 MySQL 到 TiDB 的迁移：

首先，目前用户的所有业务都是在 MySQL 的集群之上，然后通过 Mydumper 、TiDB 的loader 将 MySQL 的镜像数据导入到集群里面去。

然后 TiDB 这边通过 Syncer 把 MySQL 的增量数据实时同步到用户的集群。此时，用户的写入是在 MySQL 基础上，用户的读取可以直接通过 TiDB ，这样的好处就是 TiDB 的 OLAP （联机分析处理）能力可以直接给用户带来直观的价值，对于复杂场景有了一个非常高效的查询引擎。还有一个问题，就是如果这个时候，用户发现 TiDB 集群有问题的时候，他可以直接下线到 TiDB 的集群，对整个线上的业务是没有感知的，把读的流量切回到 MySQL 集群就可以了。

第三步把读写流量全部迁移到 TiDB 集群，通过 TiDB 的 binglog 反向的去把TiDB 的数据同步到 MySQL 的集群，同样 TiDB 有问题的话，还可以切回到之前的 MySQL 集群。不会有任何的数据一致的问题。

第四步把 MySQL 集群完全下线掉，直接用 TiDB 集群提供在线的服务。在整个帮助用户去上线 TiDB 的问题上，我们花了大量的精力来提供周边的工具。

最后提一下 Cloud ，TiDB 的特点已经非常适合 Cloud 的环境了。首先，TiDB 是可以弹性扩容的，这一点就和 Cloud非常的匹配；另外一点就是 TiDB 本身适用于大数据量的场景，那么对于 Cloud 来说，你可以在底层只部署一套或者有限的几套集群，就可以在上面提供非常多的用户的访问需求，这样整个云厂商可以将服务器的资源利用得更好，用户对于这些没有太大的感知，在技术实现上是通过Kubernetes来实现的。